Sistemas Distribuídos: Conceitos e Projeto

.• 1

-

.

• r

-

e.

quarta , edição

SISTEMAS DISTRIBUIDOS CONCEITOS E PROJETO George Coulouris Jean Dollimore Tim Kindberg r I

Oboa orogonalment.: publicada sob o título Omrilmtt'tl Sy.Hems - ConCt'piS tmd De>ign. 4th Etlition

JSB:X 03212635-15

€> Addison Wcslcy Publishers Limitcd 1988. 1994. Pcarson Education Limited 2001. 2()()5. This 1r:onsla1ion of Dis1ribu1cd Systcms - ConccpH. :ond Dcsign 04 Edition is publi~hcd by arrnngcmen1 with Pearson Euu~mion Limi1ed. Pm1ugucsc languagc 1ranslmion © 2007 by Bookmun Companhia Editora Ltda .. u divi sion of Anmcd Editora SA. Ali righl> rc,crvcd. Todos os direitos rc~rvado~.

Capa: Gll>tao•tJ Denwrcloi. imc sobre capa origonal Lcttura final: Rachi!l Garcia \'a/de: S upcrvisBo editorial: Denise Weber Nowac:yk f'.diloraç~o clctrônica:

Laser H ouse

Os rn>grnmas deste livro fomm incluído' por 'cu valor instiwcional. A editora nilo oferece garnntias, não possui qualquer representação e não tem responsabi li dades no que diz respeito aos programas.

Too:" o' marcas registradas usadas neste livro ,fio propriedade de seus respecli vo> dono,, O '"o delas por pane do autor ou da edilora não lhes confere qualquer direito de propriedade, nem impl ica cm qualquer tipo d.: afiliação ou cndo'", por tai' propriedades.

Rc,crvados IOd(lS O$ direitOs de publicaç~o. con língua ponugucsa, à Alrf'M oD• EDITORA S.A. (BOOKMAN"' COMPANHIA EDITORA é uma divisão dn ARTMED• ED ITORA S.A. l Av. Jcrônimo de Onnclas. 670 - Santana 90040-:140 - Porto Alegre- RS l'one: (5 1) 3027-7000 Fax: (51 ) 3027-7070 ~ 1>roib1dn a duplic:~ção ou reprodução dc!.te 'olume. no todo ou em pane. sob qunt'i(Juer form:l\ ou por quaisquer meios (eletrônico. mecânico. gravação. fotocópia. distributçào na Web c outnh). 'cm permissão expressa da Editora.

SÃO PAULO Av. Angé lit·n. 1.09 1 - Higicnópolis 01 227- 100 - São Paulo - SP Fone: (li) 3665-1 100 Fax: ( li) 3667- 1333

SAC 0800 703-3444 IMrReSSO NO BRAS IL PR INTEl) lN 8RA7JL

t

Sumário

1 Caracterização de sistemas distribuídos 1.1 lntrodu~ão 1.2 ExemQios de sistemas distribuidos 1.3 ComQartilhamento de recursos e a web

17

1.5 Resumo

36

2 Modelos de sistema 2.1

lntrodu~âo

2.2 Modelos de arguitetura de sistemas distribuídos 2.3 Modelos fundamentais 2.4 Resumo

3 Redes de com~utadores e interligação em rede 3.1 3.2 3.3 34 3.5 3.6

4

15

Introdução Tipos de rede Conceitos básicos de redes Protoçolos Internet Estudos de caso: Ethernet, Wifi, Bluetooth e ATM Resumo

Comunicação entre processos 4.1 4.2 4.3 4.4 4.5

Introdução A APIpara protocolos Internet ReQresenta!:;ãO externa de dados e emQacotamento Comunicação cliente-servidor Comunicação em gruQO

16 21

38 39 40 54 67

70 71 74 77

91 110

123

125 126 127 136

146 153

10

SUMÁRIO

4.6 Estudo de caso: comunicação entre processos no UNIX

157

47 Resumo

159

5 Objetos distribuídos e invocação remota 51 52 53 5.4 5.5 5.6

Introdução Comumcação entre objetos di~nbuídos Chamada de procedimento remoto Eventos e notifiCações Estudo de caso. RMI Java Resumo

6 Sistema operacional 6.1 6.2 63 6.4 6.5 6.6

Introdução A camada do sistema operacional Proteç~o

Processos e threads Comunicação e invocação Arquiteturasde sistemas operaoonais 67 Resumo

7 Segurança 71 7.2 7.3 7.4 7.5 7.6 7.7

8

lntroducão V1são geral das técnicas de segurança Algoritmos de cnptografia Assinaturas d1g1ta•s Cr:ptograf1a na prátiCa Estudos de caso: Needham-Schroeder, Kerberos. TLS, 802.11 W1Fi Resumo

Sistemas de arquivos distribuídos 8.1 82 8.3 8.4 8.5 8.6

Introdução Arqu•tetura do serviço de arquivos Estudo de caso: Sun Network File System Estudo de caso: Andrew File System Apnmoramentos e ou tros desenvolvimentos Resumo

9 Serviços de nomes 9.1 Introdução 9.2 Serviços de nomes e o Domain Name System 9.3 Serviços de diretório 9.4 Estudo de caso: Global Name Serv1ce

1.63 Ui4 161 l.BO 183 189 195

199 200 201 203 205 220 229 fill

236 231

243 253 261 267 269 282

284 285 292 297 307 315 320

323 324 327 339 340

•

SuMARIO

9.5 Estudo de caso: X.SOO Diredory Service 9.6 Resumo

343 346

10 Sistemas peer-to-peer 10.1 10.2 10.3 10.4 10.5 10.6 10.7

349

Introdução Napster e seu legado Middleware para peer-to-peer Sobreposição de rateamento Estudos de caso: Pastry, Tapestry Estudos de caso: Squirrel, OceanStore, lvy Resumo

15.0. 353 355 357 360 368 376

11 Tempo e estados globais 11.1 11.2 11.3 11 .4 11 .5 11.6 11.7

379

Introdução Relógios, eventos e estados de processo Sincronizando relógios ffsicos Tempo lógico e relógios lógicos Estados globais Depuração distribuída Resumo

380 381 383 389 392 399 404

12 Coordenação e acordo 12. 1 12 2 12.3 12.4 12.5 12.6

407

Introdução Exclusão mutua distribuída Eleições Comunicação multicast Consenso e problemas relacionados Resumo

408 411 418 421 434 443

13 Transações e controle de concorrência 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8

11

445

Introdução Transações Transações aninhadas Travas e bloqueio Controle de concorrência otimista Ordenação da indicação de tempo Comparação dos métodos de controle de concorrência Resumo

446 449 458 460 472 476 482 483

14 Transações distribuídas

488

14.1 Introdução 14.2 Transações distribuldas planas e aninhadas

489 489

M'll mie

dr

1uo

1

12

SUMÁRIO

14.3 14.4 14.5 14.6 14 7

Protocolos de efet1vação atómica Controle de concorrência em transaçOes distribuldas Impasses dismbuidos Recuperação de transações Resumo

15 Replicação 15.1 15.2 15.3 15 4 15.5 15 6

Introdução Modelo de sistema e comun1cação em grupo Serviços tolerantes a falhas Estudos de caso de serv~ços de alta d1spon1bil1dade: Gossip, Bayou e Coda TransaçOes com replicação de dados Resumo

16 Computação móvel e ubíqua 16.1 16.2 16.3 16.4 16.5 16 6 16.7 16.8

Introdução Associação lnteroperabilidade PercepçAo e reconhecimento de contexto Segurança e privacidade Adaptabilidade Estudo de caso: Cooltown Resumo

17 Sistemas multimídia distribuídos 17 1 17 2 17.3 17.4 17.5 17.6 17 7

18

Características de dados mult1mídia GerenCiamento da qualidade de serviço Gerenoamento de recursos Adaptação de fluxo Estudo de caso: o servidor de arqu1vos de vídeo Tiger Resumo

Memória compartilhada distribuída 18 1 18 2 18.3 18.4 18.5 18.6

11

lntroduç~o

Introdução Problemas de projeto e de implementação Consistência seqüencial e estudo de caso (lvy) Consistência relaxada e estudo de caso (Munin) Outros modelos de consistência Resumo

492 499 502 508 516

520 521 523 530 536 552 562

566 567 574 582 588 599 607 611 617

620 621 625 626 635 636 638 642

644 645 649 657 663 668 689

SuMARIO

19

Serviços web 19.1 Introdução

19.2 19.3 19.4 195 19.6 19.7 19.8

Serviços web Descrições de serviço e IDl para serviços web Um serviço de diretório para uso com serviços web Aspectos de segurança da XMl Coordenação de serviços web Estudo de caso: a Grade Resumo

20 Estudo de caso: CORSA 20.1 20.2 20.3 20.4

Introdução CORBA RMI ServiçosCORBA Resumo

13

672 673 674 687 691 693 697 699 707

710 711 711 726 733

Referências

737

Índice

769

Caracterização de Sistemas Distribuídos 1.1 1.2 1.3 1.4 1.5

Introdução Exemplos de sistemas distribuídos Compartilhamento de recursos e a web Desafios Resumo

m sistema distribuído é aquele no qual os componentes localizados em computadores interligados em rede se comunicam e coordenam suas ações apenas. passando mensagens. Essa definição leva às seguintes características dos sistemas distribuídos: concorrência de componentes, falta de um relógio global e falhas de componentes independentes. Daremos três exemplos de sistemas distribuídos: • a Internet; • uma intranet. que é uma parte da Internet gerenciada por uma organização; • computação móvel e ubíqua (ou peNasiva). O compartilhamento de recu rsos é um forte motivo para a construção de sistemas distribuídos. Os recursos podem ser gerenciados por servidores e acessados por clientes, ou podem ser encapsulados como objetos e acessados por outros objetos clientes. A web será d1scutida como um exemplo de compartilhamento de recursos e serão apresentadas suas principais características. Os desafios advindos da construção de sistemas distribuídos são a heterogeneidade de seus componentes, ser um sistema aberto. o que permite que componentes sejam adicionados ou substituídos, a segurança, a escalabilidade - a capacidade de funcionar bem quando o número de usuários aumenta- o tratamento de falhas. a concorrência de componentes e a transparência.

U

16

SiSTEMAS DISlRIBUIDOS, (ONCEilOS E PROIElO

1.1 Introdução As redes de computadores estão por toda parte. A Internet é uma delas. assim como as muitaS redes das quais ela é composta. Redes de telefones móveis, redes corporativas, redes de fábrica, redes em campus, redes domésticas, redes dentro de veícu los, todas elas, tanto separadamente como em conjunto. comparti lham as características básicas que as tornam assuntos relevantes para estudo sob o título sisrenws disrribuíâos. Neste livro. queremos explicar as características dos computadores interligados em rede que afetam os projetistas e desenvolvedores de sistema e apresentar os principais concei tos c técnicas que foram criadas para ajudar nas tarefas de projeto c implementação de sistemas que os têm por base. Definimos um sistema distribuído como sendo aquele no qual os componentes de hardware ou software, localizados em computadores interligados em rede, se comunicam e coordenam suas ações apenas enviando mensagens entre si. Essa definição si mpl es abrange toda a gama de sistemas nos quais computadores i nterligados em rede podem ser distribuídos de maneira útil. Os computadores conectados por meio de uma rede podetn estar separados por qualquer distância. Eles podem estar cm continentes separados, no mesmo prédio ou na mesma sala. Nossa definição de sistem~s distribuídos tem as segui ntes conseqüências importantes: Concorrência: cm uma rede de computadores, a execução concorrente de programas é a nor-

ma. Posso fazer meu trabalho em meu computador, enquanto você faz o seu cm sua máquina, comparti lhando recursos como páginas wcb ou arquivos, quando necessário. A capacidade do sistema de manipular recursos comparti lhados pode ser ampliada pela adição de mais recursos (por exem plo. compu tadores) na rede. Vamos descrever como essa capacidade extra pode ser distribuída em muitOS pontos de maneira útil. A coordenação de programas ern execução concorrente c que comparti lham recursos também é um assunto importante e recorrente. lnexisrência de relógio global: quando os programas precisam cooperar, eles coordenam suas ações trocando mensagens. A coordenação freqUentemente depende de uma noção compartilhada do tempo em que as ações dos programas ocorrem . Entr~tanto, verifica-se que existem limites para a precisão com a qu al os computadores podem si ncron izar seus relôgios cm uma rede - não existe uma noç.ão gloool única do tempo correto. Essa é uma con seqüência di reta do fato de que a única com unicação se dá por meio do envio de mensagens cm uma rede. Exemplos de-~ses problemas de sincronização e suas soluções serão descri tos no Capítulo I I. Falhas independentes: todos os sistemas de computador podem falhar e é responsabilidade dos projetistas de sistema 1>ensar nas conseqUências das possíveis falhas. Nos sistemas distrihuídos. as falhas são diferentes. Falhas na rede resu ltam no isolamento dos computadores que estão co· nectados a ela, mas isso não significa que eles param de funcionar. Na verdade, os programas neles existentes talvez não consigam detectar se a rede falhou ou se tornou demasiadamente lenta. Analogamente, a falha de um computador ou o término inesperado de um programa em algum lugar no sistema (u m colapso no sisrema) não é imediatamente percebida pelos outros componen· tes com os quais ele se comunica. Cada componente do sistema pode falhar independentemente, deixando os outros ainda em funcionamento. A s conseqüências dessa característica dos sistemas distribuídos serão um tema recorrente por todo o livro.

A motivação para constnJir e usar sistema~ distribuídos é proveniente do desejo de companilhar recursos. O termo " recurso" é bastante abstrato. mas caracteriza bem o conjunto de coisas que podem ser compartilhadas de maneira útil cm um sistema de computadores interligados cm rede. Ele abrange desde componentes de hardw;tre, como discos c impressoras, até entidades definidas pelo software, como arquivos. bancos de dados e objetos de dados de todos os tipos. fsso inclui o f1uxo de quadros de vídeo proven iente de uma dhncra de vídeo digital ou :~ conexão de áud io que urna chnmilda de telefone móvel representa. O objetivo deste ca pítulo é transmitir uma visão clara da natureza dos sistemas di stribuídos e dos desafios que devem ser enfrentados para garantir que eles sejam bem-sucedidos. A Scção 1.2 fornece alguns exemplos importantes de sistemas distribuídos, os componentes a partir dos quai s eles são constntídos c seus objeti vos. A Seção 1.3 explora o projeto de sistemas com comparti lhamento de

'li mi c

d

torq s

CAPITULO 1 • (ARACTERIZACAO OE StSlEMAS DISTRIBUIOOS

17

recursos no contexto da World W ide Web. A Seção 1.4 descreve os principais desafios enfrentados pclos projetistas de sistemas distribuídos: heterogeneidade, sistemas abertos, segurança, escalabilidadc, tratamento de falhas. concorrência e a necessidade de transparência.

1.2 Exemplos de sistemas distribuídos Nossos exemplos são baseados cm redes de computadores que nos são familiares c amplamente di-

fundidas; a Internet, intranets e a emergente tec nologia das redes l>aseadns em dispositivos móveis, Eles foram planejados de modo a exemplificar a ampla gama de ser viços c apl icações suportadas pelas redes de computadores c para iniciar a discussão sobre os problcnKIS técnicos que fundamcmam a sua implementação.

1.2.1

A Internet

A Internet é um conjunto de redes de computadores, de muitos tipos diferentes, interligadas. A Figura 1.1 ilustra uma pane típica da Internet. Os programas que estão em execução nos computadores conectados a ela interagem enviando mensagens através de um meio de comun icação comum . O projeto e a construção dos :mecanismos de comunicação da Internet (os protocolos Internet) são uma realização técnica importante, permitindo que um programa em execução em qualquer lugar envie mensagens para programas cm qualquer outro lugar. A lmernet é um sistem a distribuído muito grande. Ela permite que os usuários. onde quer que estej am, façam uso de serv iços como a World Wide Wcb, e-mai l c transferência de arquivos. Na verdade. às vezes, a web é confundida como sendo a Internet. O conjunto de serviços da Internet é aberto -ele pode ser ampliado pe l:t adição de computadores ser vidores e novos tipos de serviços. A Figura 1. 1 mostra um conjunto de intm nets- sub-redes operadas por ellllpresas e outras organizações. Os provedores de ser viços de Internet (ISPs, do inglês lnrem et Service Pmviders) são empresas que fornecem , através de modem de l inha discada ou omros tipos de conexões, o acesso a usuários i ndividuais. ou organizações, à Irntcm et. Esse acesso permite que os usuários utilizem os diferentes serviços disponibi lizados pela I nternet. Os provedores fornecem ainda alguns serviços locais. com o e-mail e hospedagem de páginas web. A s i mr:mets são interligadas por meio de backbones. Um backbone é um

.

lntrarn!t

• •

•

Computador de mesa: ~ Servidor: a Enlace de rede: Figura 1.1

Uma parte típica da Internet.

'li

li!

r to 'lUtO

S

18

SISTEMAS DISTRIBUIDOS, CONCEITOS E PROJETO

en lace de rede com uma alta capacidade de transmissão, empregando conexões via satélite, cabos de .fibm óptica ou outros meios ffsicos de transm issão que possuam uma grande largura de banda. Uma série de serviços de mul!imfdia estão disponíveis na internei, perm itindo aos usuários acessarcm dados de áudio e vídeo, o que inclui música, rádio, canais de TV c a manter conferências via telefone e vídeo. Atualmente, a capacidade da Internet para tratar os requ isitos especiais da comunicação de dados mullimídia é bastante limi tada, pois ela não fornece os recursos necessários para reservar capac idade de rede para que fluxos de dados individuai s sejam enviados e recebidos de forma adequada a dar uma boa qualidade de serviço. O Capítulo 17 discute as necessidades dos sistemas mullimídia distribuídos. A implementação da Internet e dos serviços que ela suporta tem acarretado o desenvolvimento de soluções práticas para muitos problemas dos sistemas distribuídos (inclui ndo a maior pa11e daqueles definidos na Scção 1.4). Vamos destacar essas soluções por todo o livro, apontando sua abrangência e suas l imitações, onde for apropriado.

1.2.2 lntranets Uma intranet é uma parte da Internet admi nistrada separadamente, cujo l imite pode ser configurado para impor planos de segurança locais. A Figura 1.2 mostra uma intranct típica. Ela é composta de várias redes locais (Loc(l/ Area Networks - LANs) interligadas por conexões de backbone. A configuração de rede de uma i ntranct cm particular é de responsabil idade da organ ização que a administra e pode variar muitO- desde uma LAN em um único site até um conjunto de LANs interconectadas pertencentes às fil iais de uma empresa ou outra organização, cm diferentes países. Urna intranet é conectada à I nternet por i ntermédio de um roteaclor, o qual permite aos usuários de dentro dessa i ntranet utilizarem serviços que são providos em outro lugar, como acesso a servidores ·.veb ou de correio eletrônico. Ela também permite que os usuários de outras intranets acessem os scr, iços que fornece. Muitas organizações precisam proteger seus próprios serviços contra uso não autorizado, possivel mente por usuários externos mal-intencionados. Por exemplo. uma empresa não deseja que informações sigi losas estejam acessfveis para usuários de organizações concorrentes. c um hospital não deseja que dados sigilosos dos pacientes sejam revelados. As empresas também querem se proteger de programas prejudiciais. como os vírus que entram e atacam os computadores que estão na intranet, possivelmente. destruindo dados valiosos.

Servidor de e·mail

@ll@i)~

- 1 - 1 _ ,

Servidores de impressão"'-. e outros "--..

---...

Servidor web

J •

I

)

'

/

I

I •

--c;;Q]

-

---

~

---

I

I

~liQJ ·

I

Servidor de e·mail 09 Servidor de arquivos

Roteador/firewa//

~

-

Rede local

Outras porções da internei

Computadores de mesa

\

- 1

•

Impressão Outros servidores

\~~~ }[iQ]j

-

;.

- 1 Figura 1.2 Uma intranet típica.

\1trl

l"dr

'lul

(APilULQ 1 • ( ARACTERIZ.AÇÃQ DE StSTEM~ !)ISTRtBVIDOS

19

A função de umfirewa/1 é proteger uma i ntranet, impedindo a entrada ou saída de mensagens não autori zadas. Umfirewall é basicamente composto de mecanismos que rea lizam a fi ltragem de mensagens recebidas e enviadas, de acordo. por exemplo, com sua origem ou destino. Umjirewa/1 poderia. por exemplo. na intranet que protege, permitir apenas a passagem das mensagens relacionadas a correio eletrônico e ao acesso ao servidor web. A lgumas organizações nem querem conectar suas redes i nternas na Internet. Por exemplo, a polícia e ou tras agências de segurança e do poder executivo provavelmente podem ter pelo menos algumas redes internas isol adas do mundo exteri or. Algumas organi zações militares desconectam suas redes intern as da Internet em tempos de guerra. Mas, mesmo essas organizações desejam tirar proveito da enorme variedade de aplicações e de softwares que empregam protocolos de comu nicação da l mernct. A solução normalmente adotada por tais organizações é implementar uma intranet como a descri ta anteriormente, mas sem conexões com a Internet. Ta l intranet pode dispensar o uso de umfirewa/1; na real idade, dizendo de outra maneira, ela j ;í possu i urnjimml/ bastante eficaz: a au sência de qu alquer conexão física com a Internet. Os pri ncipais problemas que surgem no projeto de componentes para uso em i ntranets são: • Serviços de arqui vo são necessários para permitir que os usuários comparti lhem dados; o seu projeto será discutido no Capítulo 8.

• Osfirewalls tendem a impedir o acesso legítimo aos serviços - quando o compartilhamento de recursos entre usuários internos e externos é necess;1rio. os jirewalls devem ser complementados com o uso de outros mecanismos de segurança: isso será discutido no Capítulo 7. • O custo da i nstalação de software e supone é uma questão importante. Esses custos podem ser reduzidos com o uso de arq uitcturas de sistema, corno com putadores de rede c clientes " leves", descritos no Capítulo 2.

1.2.3 Computação móvel e ubíqua Os avanços tecnológicos na miniantrizaçào de dispositivos c i nterligaç;io em rede sem fi o têm levado cada vez mais à i ntegração de equi pamentos de com putação pequenos e portáteis com sistemas distri buídos. Esses equipamentos i ncluem: • Computadores notebook • Aparelhos portáteis, incluindo assistentes digitais pessoais (PDAs). telefones móveis. pagers. cãmeras de vídeo e digitai s • Aparelhos acoplados ao corpo, como re lógios de pulso intel igentes com funcionalidade semelhante à de um PDA • Dispositivos i ncorporados em aparelhos, como máqui nas de lavar, apare lhos de som de alta fidelidade, carros, geladeiras, etc. A portabi lidade de muitos desses dispositivos, junto com sua capacidade de se conectar convenientemente com redes em diferentes lugares. tOrnam a comfllttOÇfiO móvel possível. A computnção móvel, também chamada de computaçlio nômade [Kici nrock 1997], é a execução de tarefas de computação, enquanto o usuário está se deslocando de um lugar a out ro ou visitando lugares diferentes de seu ambiente usual. Na computação móvel, os usuários que estão longe de suas i ntraneL~ " de base" (a intranet do trabal ho ou de sua residência) podem acessar recursos por intermédio dos equipamentos que carregam consigo. Eles podem continuar a acessar a Internet, os recursos cm sua intranct de base c, cada vez mai s, exi stem condições para que os usmírios uti lizem recursos como impressoras. que estão convenientemente próximos, enquanto transi tam. Esta tíltima pt>ssibilidade também é çonheeida como computação com reconhecimento de localh:ação ou com reconhecimento de comexto. A computaçtio ubíqua [Weiser 1993]. também denominada de comp111açcio pervasiva, é a utilização de vários dispositivos computacionais pequenos e banHos. que estão presentes nos am bientes físicos dos usuários. inclui ndo suas casas, escritórios e até na ma. O termo "pervasivo" se destina a sugerir que pequenos cquipamernos de computação fi nal mente se tomarão tão entranhados nos obj etos diári os que mal serão notados. Isto é, seu comportamento computacional sení transparente c

M

111

20

SiSTEMAS DISTRIBUIDOS, CONCEITOS E PROIETO

i ntimamente vinculado à sua fu nção física. Por sua vez. o termo ''ubíquo" dá a noção que o acesso a serviços de computação estCdidos concorrentes, para reduzir o atraso global para o usuário.

ConTrole de acesso simplific ado; por padrão, qualquer usuári o com conectividade de rede para um ser vidor web pode acessar qualquer um de seus recu rsos publicados. Se for necessári o restringir o acesso a determinados recursos , isso pode ser feito configurando o ser vidor de modo a emi tir um pedido d e identificação para qualquer cliente que o sol ici te. Então, o usuário correspondente precisa provar que tem direi to de acessar o recurso, por exemplo, digit ando uma senha. Páginas din âmicas O Até aqui. descrevemos como os usuários podem publicar páginas web e outros tipos de conteúdos na web. Entretanto. grande pane du experiência dos usuários na web é a inreração com serviços. cm vez da simples recuperaçao de infonnações. Por exemplo, ao adquirir um item em uma loja on-line. o usu:íri o rreqüentemente preenche um ji:Jmwltirio paru fornecer seus detalhes pessoais ou para especificar ex ata mente o que deseja adquiri r. Um formulário web é uma pági na contendo instruç.ões para o usuário e elementos de janela para entrada de dados, como campos de texto c caixos de sdeção. Quando o usuário envia o rormu lário (normalmente, clicando sobre um botão no próprio formuhírio ou press iona ndo a tecla ret11m ). o navegador env ia urn pedido HTTP para um servidor web, COJllcndo os valores i nseridos pelo usuário. Como o resu ltado do pedido depende da entrada do usuário. o servidor precisa processar a entrada do usuário. Po11anto, o URL, ou seu componente inicial, designa um programa no servidor e não um arquivo. Se os dados de ent rada fornecidos pelo usuário forem razoavelmente cu rtos. então, normalmente eles serão enviados como o componente de consulta do URL , após um caractcre '!,caso contrário. eles serão enviados a parte. Por exemplo, um pedido contendo o URL a seguir ativa um programa chamado search no endereço www.googlc.cmn e especitica o string de consu lta kindberg:

l111p:/ln ww. google.comlsea rt h ?q =ki ndbe rg. Esse programa search produz texto em HTML na salda c o usuário verá uma listagem d:1s páginas que cont êm a palavra kindberg. (0 leitor pode inserir uma consu lta em seu mecanismo de busca predileto e observar o URL ex ibido pelo navegador, quando o resultado for retornado.) O servidor retorna o texto em HTML gerado pelo programa, exatamente como se tivesse sido recuperado de um arqu ivo. Em outras palavras, a direrença entre o conteúdo estático recuperado a partir de um arq uivo e o conteúdo gerado di nam icameme é transparente para o navegador. Um programa que os servidores web executam para gerar conteúdo para seus clientes é frcqiien ternente denominado como programa CGI (Common Ga1eway lntel:fr~Cio cliente e produzir conteúdo do tipo so licitado (normalmente. rex to HTML) . FreqUentemente, o programa consuh~trá ou atuali zará um banco de dados no processamento do pedido. Código ca rregado por download: um programa CGT é executado no servidor. Às vezes. os projetistas de serviços wcb exigem que algum código relacionado ao serv iço seja executado pelo navegador no co mputador do usu;1ri o. Por exemplo, frelJiicntemente, ju nto com um formul ário wcb, é feito o download de um cód igo escrito em Jav;1script I www.nctscape.com] para proporcionar um a i nteração de melhor qual idade com o usuário. em vez daquela su po1tada pelos elementos de janela padrão do protocolo HTML. Uma página apri morada com Javascript pode dar ao usuário retorno imediato sobre entradas i nvál idas (em vez de obrigar o usuário a verificar os va lores no servidor, o que seri a muito

'li

li!

r to 'lUtO

S

(APfTULO

1 •

(ARACTERIZflÇÃO OE SISTEMAS 0 1STRIBUfOOS

27

mais demorado}. O códi go Javascript pode. ser usado para atualizar partes do conteúdo de uma p com o usu;irio. usando recursos da linguagem Java [java.sun.corn, Flanagan 20021. Por exemplo, às vez.:s, os aplicativos de bate-papo são i mplementados como opplets executados nos navegadores dos usuários. j ulllo com um progmma servidor. Nesse caso. os applets enviam o texto de um usu;írio para o servidor. o qual, por sua vez. o redistribui para os demais applets para serem apresentados aos ou tros usuiírios. Di scmiremos os applets com mais delalhes na Seção 2.2.3. Serviços web (web services) O Até aqu i, discutimos a web do ponto de vista de um usuário operando um navegador. Mas outros programas, além dos navegadores, também podem ser cl ientes wcb; na verdade. o acesso por meio de programas aos recursos da web é muito comum. Entretanto, sozinhos, os padrões HTML e HlTP sfto insulicientcs para realizar intcraçõcs por meio de programas. Primeiramente, h5 uma necessidade cada vez maior na wcb de trocar dados de tipos estruturados, mas o protocolo HTML não possui essa capacidade, ele é li mitado a real izar a navegação cm i nformações. O protocolo HTML tem um conjunto estiitico de cstn •turas, como parágrafos. e elas são restri tas nas maneiras como os dados devem ~cr apresentados para os ustuírios. A linguagem XML (E.rrem em pági nas web, os programas de busca podem então, cm princípio, com base na corrc~pundência .semfinlita, real izar pesqu is~s nos metadados para compi lar listas de links relacionados. Colctivamcntc.

e.sse cmanmhado de recursos de metadados vinculados é o que é conhecido como " '"b .w:mântica . Como uma arqu itetu ra de sistema. a web en frenta problemas de cscalabi lidatlc. Os servidores web m;tís populares podem ter muitos acessos (hits) por segundo c, tomo resultado. a resposta para os usuários pode ser lenta. O Capítulo 2 descreverá o uso de cache en navegadores e de servidores pmxies para melhorar o tempo de resposta c H divisão da carga de proces~amcnto por um grupo de

M1t mi c

dr

'lU O

I

28

SISTEMAS OISTRIBUIDOS, CONCEITOS E PROJETO

computadores. A arquitctura cliente-servidor web implica em que ela não tem nenhum meio eficiente de manter os usuários atualizados com as versões mais recentes das páginas. Os usuários precisam expl icitamente fazer uma operação de atualizar em seus navegadores para terem certeza de que possuem as informações mais recentes. Nesse caso, os navegadores são obrigados a se comunicar com os servidores web para verificar se a cópia local que possuem de um recurso ainda é válida ou se os servidores possuem uma versão mais recente. Finalmente, uma pági na web nem sempre possu i uma interface sati sfatória com o usuário. Os elementos de janela da i nterface definidos pel a HTML são limitados c os projetistas freqUentemente incluem nas páginas web applets e/ou muitas imagens para fazê-las parecer e funcionar de modo mais aceiuível. Com isso. h(t um conseqUente aumento no tempo de download.

1.4 Desafios Os exemplos da Scção 1.2 i lustram a abrangência dos sistemas distribuídos e os problemas que surgem cm seu projeto. Embora os sistemas distribuídos sej am encontrados em toda parte, seu projeto é muito simples c ainda há muito espaço para o desenvolvimento de serviços e de aplicativos mais ambiciosos. Muitos dos desafios discutidos nesta seção já foram resolvidos, mas os futuros projetistas precisam conhecê-los c tomar o cuidado de levá-los em consideração.

1.4.1

Heterogeneidade

A Internet permite aos usuários acessarem serviços c executarem aplicativos por meio de um conjunto heterogêneo de computadores e redes. A heterogeneidade (isto é, variedade e diferença) se aplica aos segu intes aspectos: • redes • hardware de computador • sistemas operacionais •

linguagerl~

de programação

• implementações de diferentes desenvolvedores Embora a Internet seja composta de muitos tipos de rede (i lustrado na Figura 1.1 ), suas diferenças são mascaradas pelo fato de que todos os computadores ligados a elas utilizam protocolos Internet para se comunicar. Por exemplo, um computador que possui urna placa Ethernet tem uma implementação dos protOcolos Internet enquanto um computador cm um tipo diferente de rede tem uma implementaç:io dos protocolos Internet para essa rede. O Capítulo 3 explicará como os protOcolos Internet são implementados cm uma variedade de redes diferentes. Os tipos de dados. como os inteiros, podem ser representados de diversas maneiras cm diferentes tipos de hardware; por exemplo, ex istem duas alternativas para a ordem em que os bytes de valores inteiros são armazenados: uma iniciando a p redes, estão sendo desenvolvidas e isso será um assu nto do Capítulo 3.

Segura11ça de c6digo m6vel: um código móvel precisa ser manipulado com cuidado. Considere alguém que receba um programa cxecut:ível como um anexo de correio elctrônico: os possíveis efeitos da execução do programa são imprevisíveis: por exemplo, pode parecer que ele apenas ex iba uma figura interessa me. mas. na real idade. está acessando recursos locais ou. talvez. fazendo parte de um ataque de negação de serviço. Algumas medidas para tornar seguro um código móvel serão esboçada~ no Capítulo 7.

1.4.4 Escalabilidade Os sistemas distribuídos funcionam de forma efetiva e eficaz em mui1as escalas diferentes. variando desde uma pequena intranct até a Internet. Um si~te ma é descrito como escalável se permanece eficiente quando M um au mento significativo no número de recursos c no número de usuários. A Internet é um exemplo de um s.istema distribuído no qu3 l o nú mero de computadores c ser viços vem :.tu mentando substancialmente. A Figura 1.5 mostra o aumento no número de computadores na Internet dur.uue 24 anos, até 2003. e a Figura 1.6 mostra o número cada vez maior de computadores e servidores web durante os lO anos de hi stória da web (vej a [zakon.orgl). O projeto de sistemas distribuídos esca láveis apresent a os seguintes desafios:

Commiar o custo dos reorrsus físicos: à medida que a demanda por um recurso au menta, deve ser possível, a um custo razoável. ampliar o sistema para atende-la. Por exemplo. a freqliência com que os arquivos são accssados em uma intranct provavel mente vai crescer ?1 medida que o número de usuários e de computadores aumentar. Deve ser possível :1dicionar servidores de arquivos de form a a evitar o gargalo de desempenho que haveria caso um único servidor de arquivos tivesse que tratar todos os pedidos de acesso a arquivos. Em geral, pnra que um sistema com11 usuários seja escal ável, ;1 quantidade de recursos físicos exigida para suponá-los deve ser no m:íximo 0 (11) -isto é, proporcional a 11. Por exemplo. se um único servidor de ;Jrquivos pode suportar 20 usuürios, então dois servidores deverão suportar 40 usuários. Embora isso pareça um objetivo óbv io. como mostraremos no Capim lo 8. não é necessariamente fáci l de atingi-lo.

Controlo r t1 perda de desempe11ho: considere o gerencia me.nlo de um conju nto de dados. cuj o tamanho é proporcional ao número de usuários ou recursos presentes no sistema: por exemplo. a tabela de correspondência emrc os nomes de domínio dos comput~dores e seus endereços lP mantidos pelo Domai11 Name System (DNS). que é usado principalmente p:m1 pesquisar nomes, como www.amazon.com. Os algoritmos que util izam estruturas hierárquicas têm melhor escalnbi lidnde do que aqueles que u~am estruturas lineares. Mas, mesmo com as estn uuras hierárquicas. um aumento no tamanho resultará em alguma perda de desempenho: o tempo que lcvn para acessar dados hierarquicamente cstrmurados é O(log n). onde 11 é o 1amanho do conjunto de dndos. Para que um sistema seja escalável, a perda de dc;,empenho máxima não deve ;,er maior do que isso.

Data Dez. de 1979

Computadores

Sen,ll.ores web

188

()

Julho de 1989

130.000

o

Julho de 1999

56.218.000

5.560.866 35.424.956

Jan. de 2003

171.638.297

Figura 1.5 Computaoores (com endereços lP registrados) na Internet.

M1t mi c

dr

'lU

o

I

I

32

SISTEMAS DISTRIBUIDOS, CONCEITOS E PROJETO

Data Julho de 1993 Julhode 1995 Julho de 1997 Julho de I 999 Julho de 200 I Julho de 2003

Comptttadore$}1.,., Servidores web 1.776.000 130 23.500 6.642.000 19.540.000 1.203.096 56.2 1S.OOO 6598.697 125.888.197 31.299.592 42.298.371

Porcentagem ·· 0.008 0,4 6 12 25

Um servidor web pode estar hospedado em vários sites.

Figura 1.6 Computadores versus servidores web na Internet.

Impu/ir que os recursos ele sojiware se esgorem: um exemplo de falta de escalabilidade é mostrado pelos números usados como endereços lP (endereços de com pulador na lmernet). No final dos anos 70, decidiu-se usar 32 birs para esse propósiro, mas, conforme será explicado no Capítu lo 3. a quanlidade de endereços lP disponíveis está se esgotando. Por isso. uma nova versão do prmocolo. com endereços de lP em 128 bi1s. eslá sendo adorada c isso exigirá modificações em muiros componentes de so f1ware. Para sermos jus10s com os primeiros projetistas da l nlerner, não há uma solução correia para esse problema. É diffcil prever, com anos de anlecedência, a demanda que será imposla sobre um sisrema. Além disso. superesti mar o crescimenro fu ruro pode ser pior do que adaptar para uma mudança quando formos obrigados a isso- ror exemplo. endereços lP maiores ocupam espaço ex lra no armazenamento de mensagens c no computador. Evitar gargalo.,· de desempenho: em geral, os algoritmos devem ser descentralizados para evitar a existência de gargalos de desempenho. lluslramos esse ponto com referência ao predecessor do Domain Nome Sysrem, no qual a tabela de correspondência entre endereços lP c nomes era mantida cm um único arquivo central, cujo dmmload podia ser feito em qualqueo· computador que precisasse dela. Isso fu ncionava bem quando havia apenas algumas centenas de computadores na lnrerne1, mas logo se rornou um sério gargalo de desempenho e administrarivo. Com os milhares de computadores na l n1erne1, imagine o tamanho e o acesso a esse arquivo central. O Domain Name Sysrem eliminou esse gargalo pnnicionando a rabeia de correspondência de nomes entre di versos servidores localizados em roda a l nlerner e administrados de forma local - veja os Capítulos 3 e 9. Alguns recursos compartil hados são accssados com mui ta freqüéncia; ror exemplo, muitos usuários podem accssa r uma mesma página web, causa ndo uma queda no desempenho. No Capítulo 2. veremos que o uso de cache e replicação melhora o desempenho de recu rsos que são pesadamente util izados. De preferênc ia, o sof1ware de sisrema e de aplicativo não deve mudar quando a escala do sisicma aumentar, mas isso é difícil de conseguir. O problema da escala é um tema cenl ral no desenvolvimenlo de sistemas dislribuídos. As técnicas que rêm obri do sucesso serão discuridas extensivamente neste li vro. elas incluem o uso de dados replicados (Capítulo 15). a técnica associada de uso de cache (Capítul os 2 e 8) c a distribui ção de vários servidores para manipular as tarefas comumenre executadas, pcrm i1i no.Jo que várias 1arefas semelhantes sejam exccmadas concorrentemente.

1.4.5 Tra tamento de falhas Às vezes. os sisremas de computador falham. Quando ocorrem falhas no hardware ou no soflwarc, os programas podem produzir resultados incorretos ou podem parar ame.s de terem concluído a compuração prclendida. No Capítulo 2, discu1ircmos e classificaremos uma variedade de ripos de falhas possíveis. que podem oco1Ter nos processos e nas redes que compõem um sistema distribuído.

\1 tu I o

di

S

IOf'liS

(APITULO 1

• (ARAC!tRIZAÇÃO OE SISTEMAS 0 1STRIBUIOOS

33

As falhas em um sistema distribuído são parciais - isto é, alguns componentes falham. enquanto outros continuam funcionando. Portanto, o tral:lmcnto de fa lhas é part icularmente difícil. As técnicas a segu ir para tratamento de fa lhas serão disculidas por todo o livro: Detecção de falhas: algumas fal has podem ser deteclàdas. Por exemplo. somas de verificação podem ser usadas para detectar dados dani ficados cm uma mensagem ou em um arquivo. O Capítulo 2 explicará que é difícil, ou mesmo impossível, detectar algumas outras falhas, como um servidor remoto dani ficado na Internet. O desafio é como gcrenciar a ocorrência de fal has que não podem ser detectadas, mas que podem ser suspeilas. Mascaramemo de falhas: algumas falhas detectadas podem ser ocu ltas ou se tOrnar menos sérias. Dois exemplos de ocultação de fal has:

L mensagens poaem ser retransmitidas quando não chegam; 2. dados de arquivos podem ser gravados em dois discos, para que. se um estiver danificado, o outro ainda possa estar correto. Simplesmente eliminar uma mensagem danificada é um exemplo de como tornar uma 1:1lha menos séria -ela pode ser retransmitida. O leitor provavelmente perceberá que as técnicas descritas para o mascaramcnto de falhas podem não func ionar nos piores casos; por exem plo, os dados no segundo disco também podem estar danificados ou a mensagem pode não chegar em um tempo razoável e, contudo, ser retransm itida frcqlicntcmcntc.

Tolerância a falhas: a maioria dos serviços na Internet apresenta fal has- não seria prático para eles tentar detectar e mascarar tudo que possa ocorrer em uma rede grande assim. com tantos componemes. Seus cl ientes podem ser projetados de form a a tolerar fal has, o que geralmente envolve a tolerância também por parte dos usuürios. Por exemplo, quando um navegador não consegue contatar um servidor web, ele não faz o usmírio esperar i ndefi nidamente. enquanto continua tentando - ele i nforma o usuário sobre o problema. deixando-o livre para tentar novamente. Os serv iços que toleram falhas serão discutidos no parágrafo sobre redundfmcia. a seguir. Recuperaçüo de falhas: a recuperação envol ve proj etar softwlre de modo que o estado dos dados permanentes pQSsa ser recuperado ou retrocedido. após a fal ha de um servidor. Em geral, as computações real izadas por alguns programas ficarão i ncompletas quando ocorrer uma fal ha e os dados permanentes que eles atualizam (arquivos em disco) podem não estar em um estado consistente. A recuperação de falhas será estudada no Capítulo 14. Redundância : os serviços podem se tornar tolerantes a falhas com o uso de componentes redundantes. Considert~ nSt de origem A para umlwsl de destino B. O estabelecimento de um circuito virrual envolve a definição de umn rota emre a origem c o destino, possível-

\1 I r I

S

I r'!tS

84

SISTEMAS DISTRIBUIDOS, CONCEITOS E PROIETO

menle passando por vários nós i ntermediários. Em cada nó ao longo da rota, é criada uma entrada em uma tabela, indicando qual enlace deve ser usado para ati ngir a próxima etapa da rota. Uma vez configurado o circu ito virtual, ele pode ser usado para transmitir qualquer quantidade de pacotes. Cada pacote da camada de rede contém apenas o número de circu ito virtual no lugar dos endereços de origem e de destino. Os endereços não são necc.tld)

int

Referência do Objeto

RemoteObjectRef

Identificador de método (rnethodld)

int 011 Method

Argumentos

11 array de bytes

Estrutura da mensagem de requisição e resposta.

Identificadores de mensagem O Todo esquema que envolve o gerenciamento de mensagens para fornecer propriedades adicionais, como a entrega confiável de mensagens ou a comu ni cação req uisição-resposta, exige que cada mensagem tenha um identificador exclusivo, por meio do qual ela possa ser referenciada. Um identificador de mensagem consiste em duas partes: 1. um identificador da req11isição, que é criado pelo processo remetente a partir de uma scqüência ascendente de valores inteiros; e

2. um identificador do processo remetente; por exemplo, sua porta e endereço l P. A primeira parte gera o idemificador exclusivo para o remetente e a segunda o torna único no sistema distribuído. (A segunda parte pode ser obti da diretamente da mensagem recebida- por exemplo. se UDP estiver em uso.) Quando o valor do idem ijicador da req11isição atingir o máximo para um inteiro sem si nal (por exe mplo, 2n - I ) ele voltará a zero. A única restrição aqui é que o tempo de vida de um identificador de mensagem deve ser muito menor do que o tempo que leva para esgotar os valores da seqUência de inteiros.

Modelo de fa lhas do protocolo requisição-resposta O Se as três primitivas doOperation. getRequest e sendReply forem implementadas em datagramas UDP. então elas sofrerão das mesmas falhas de comunicação. Isto é: • elas sofrerão de fal has por omissão; • não haverá garantia de que as mensagens sejam entregues na ordem da em issão. Além disso, o protocolo poderá sofrer com as falhas dos processos (veja a Seção 2.3.2). Pressupomos fal has do tipo colapso. isto é. quando eles fa lham, permanecem parados. Em outros termos, não há um comportamento bizantino. Para considerar as ocasiões em que um servidor ti ver falhado, ou que uma mensagem de requisição ou resposta tenha sido descartada, doOperation util iza umtimeout para limitar a espera de uma mensagem de resposta do servidor. A ação executada quando o timeow ocorre dependerá das garantias de entrega a serem oferecidas.

Timeouts O Existem várias opções para o que doOperation deva fazer após o timeo11t. A opção mais simples é retornar imediatameme de doOperation. com uma indicação para o cliente de que o métooo doOperarion falhou. Essa não é a estratégia usual- o timeout pode ter sido atingido devido à perda da mensagem de requisição ou da resposta - e, neste úhimo caso, a operação terá sido execu tada. Para com pensar a possibil idade de perda ele mensagens, doOperation envia a mensagem de requisição repetidamente até que receba uma resposta. ou esteja razoavelmente seguro de que o atraso é devido à faha de resposta do servidor e não por causa de mensagens perdidas. Final mente, quando doOperation retornar, indicará isso para o cl iente por meio de uma exceção, dizendo que nenhum resuhado foi recebido. Descartando mensagens de requisição duplicadas O Nos casos em que a mensagem de requ i sição é retransmi tida, o servidor pode recebê-la mais de uma vez. Por exemplo, o servidor pode receber

\iltrl

CAPITULO 4 • (OMUNICA amounr

retorna o ~a ido da conta serBalance(amount)

configura o saldo da conta como amount

Operações da interface Branch crcate(rwme)-'> accowrt

cria uma nova coma com um nome informado lookup( name)--'> c:ccowrt

retorna uma referência para a conta com o nome informado branclrToral(}-'> amowrr

retorna o total de todos os saldos da agência Figura 13.1 exemplo, a classe que implementa a interface Accowu poderá declarar os méwdos como synclrroni· Zl'd. Por exe mplo: pttblic synclrroniz.ul void deposir(illl amounr) rlrmws RemoreException{ 11 adiciona amowrt ao saldo da conta

Se uma tlrread invoca um métOdo sincronizado em um ob_jeto, então o acesso a esse objeto é travado (locked}; assim, se outra rlrread i nvocar um de seus métodos si ncronizados será bloq uc leiwra. a qual coloca uma indicação de tempo de leitura T, na 5

versão de 2.

7~;

T~ sol icita uma operação de escriTa, a qual produz uma nova versão de tentati va com indicação de tempo de escrita 7~;

3. T5 solicita urna operação de leitura, que us!i

01:.

opetiTrlltlSllCIÍOil

open Transaction

y = read(k); write(i. 55); write(j. 66): Commi1 x

= rl!ad(i);

writeU, 44);

O resultado do contro le de concorrênc ia otimista com validação para trás é que T será cance.lada. pois sua operação d e leitum c mra cm confl ito com n operaç5o de ewTita de U e m a,. embora as interposições sejam equivalentes e m série. Sug ira uma modificação no algorit mo q ue trate de ta is página 472-473 casos. 13.18 Faça uma comparação das seqüê ncias de operações das transações Te U do Exercício 13.8 que são possíveis sob o bloqueio de duas fases (Exercício 13.9 ) e sob o controle de concorrência otimista {Exercício 13.16). 13.19 Considere o uso de o rdenação de indicação de tempo cm cacl a um dos exemplos de imcrposições das transações T eU do Excrcfcio 13.9. Os valores iniciais de o, e ai são IOe 10, respectivamente. e indicações inic ia is de tempo de leitura e escrita são r.,. Suponha que cada transação seja aben a c obtenha uma indicação de tempo imediatamente antes de s ua pri meira open1ção: por exemplo, em (a) TeU obtêm as irndicações de tempo 11 e 12 respectivamente, o nde 10 < 11 < t!. Descreva. na ordem crescente de tempo, o~ efei(()s de cada opcr;1ção de Te U. Para cada operação. declare o segui nte: (i) se a operação pode prossegui r de acordo com a regra de escrita ou le iruo·a; (ii) as indicações de tempo atribuídas às transações ou aos objetos: {ii i) criação de obje tos de tentativa e seus valores. página 475-476

Quais são os valores fi nais dos objetos c s uas indicações de tempo·? 13.20 Repita o Exercíc io 13.19 para as seguintes interposiçõcs das transações TeU:

T

U

opeu Trmr.wction open Transocrion

O{Jt'JJTrattSCtCIÍOn

wrire(i. 55);

write(i. 55);

wrire(j. 66);

write(j, 66);

x = re(l{/ (i);

Commit x = read (i ):

"·rite(j. 44): COIIllllit

Write(j, 44); página 475-476

13.21 Repita o Exercício 13.20 usando ordenação de indicação de tempo de versão múltipla. página 479-480

13.22 Na ordenação de ind icação de tempo de versão nníltipla. as opcmçõ"s de leirum podem acessar versões de tentativa dos objctos. Dê um exemplo para mostrar como os c!lncelamcntos em cascata podem pá.~irw 479-480 acontecer se todas as opcmções de leiwm pudere m prosseguir i med iatamente. 13_23 Quais siio as vantagens c os inconvenientes da ordenação de ind icaçao de tempo de versão múltipla página 479-480 em comparação coon a onJenaçao de indicação de tempo nornnal? 13-24 Faça uma comparação das seqüências de operações das transações Te U do Exercício 13.8, q u.; são possíveis sob o bloq ueio de duas fases (Exercício 13.9) e sob o controle de concorrência otimista página 472--473 {Exercício 13. 16).

'li

li!

r to 'lUtO

S

(APfTULO 14 • TRANSAÇOES 01STRIBUfOA$

491

por uma transação é um parti cipante da transação. Cada p:1rticipante é responsüvel por rastrear rodos os objeros recuperáveis envolvidos na rransação nesse servidor. Os participantes são responsáveis por cooperar com o coordenador na execução do protocolo de ei'etivação. Durante o andamento da rransação o coordenador rcgisrra uma lisra de referências nos pa rtici pantes . e cada participante registra uma referência no coordenador. A interface para Coordinator, mostrada na Figura 13.3, fornece um méwdo adicional,join, usado quando um novo participame emra na rransação:

jain(Trans. referência tlO participame) Informa ao coordenador que um novo participante entrou na transação 1inns.

Ocoordenador registra o novo participante em sua lista de participantes. O fato de o coordenador conhecer todos os participantes. e cada participante conhecer o coordenador, permitirá que eles reúnam a.~ informações que serão necessárias no momenro da efetivação. A Figura 14.3 mostra um cl iente cuja transação bancária (pl3na) envolve as conras A, B, C e D, nos servidores AgênciaX, AgênciaY e AgênciaZ. A transaçào do cl iente. T. transfere $4 da coma A para a coma C, c depois transfere $3 da conta B para a coma D. A transação descrita à esquerda é expandida para mostrar que openTrtmsaCJitm c closeTranwction são direcionados para o coordenador, o qual csrará situado em um dos servidores envolvidos na transaçiio. Cada servidor é mostrado com um parlicipame, o qual cnrra na rransação invocando o método join no coordenador. Quando o cl iente invoca um dos métodos na transação, por exemplo, b.withdraw(T, 3), o objeto que recebe a invocação (8 em AgênciaY, neste caso) informa ao seu objcto participante que o objeto pertence à rransação T. Se ainda não ri ver informado ao coordenador. o objeto participa nte usa a operaçãojoin para fazer isso. Neste exemplo, mostramos o identificador de transação sendo passatlo como um argumento adicional. para que o destinatário possa passá-lo para o coordenador. Quando o clieme chama closeTrcmsaction. o coordenador rem referências para todos os parricipanres. Note que é possfvcl um participante chamar abortTran.saction no coordenador. se por algum moLivo n;i o for capaz de continuar com a transaçào.

coordenador

n

open Transactíon closeTransactíon

A

li)

a.withdraw(4);

Agênoax

~1ctpante Cheote

bwithdraw(T; 3);

T = openTransaction a.withdraw(4); c.deposit(4); b.withdraw(3);

8

join

d.d~posit(JJ;

doseTransaction Nota: O coordenador está em um dos servidores; por exemplo. AgénciaX. Figura 14.3

~

b.withdraw(3);

AgênaaY panictpante

C ~

c.deposit(4);

D ~

d.deposit(3);

AgênciaZ

Uma transação bancária distribuída.

1UIO

I

CAPITULO

14 • f RANSAÇOES 01STR18UIDAS

495

Outro pomo no qual um pm1icipamc pode ser retardado é quando tiver executado todos os pedidos de seu cliente na transação, mas ai nda não ti ver recebido uma chamada de callCommit do coordenador. Quando o cl iente envia o pedido ele c/oseTransaction para o coordenador, um partici pante só pode detectar tal situação se notar que n5o tinha um pedido em uma 1ransação específica por um longo tempo; por exemplo. por um período de tempo l imite sobre uma trava. Como nenhuma decisão foi tomada nesse estágio, o participante pode decidir cancelar unilateralmente, após algum período de tempo. O coordenador pode ser retardado quando estiver esperando pelos votos dos participantes. Como ele ainda não decidiu o destino da tra nsação. pode decidir cancelá-la ap6s algum período de tempo. Ele eleve então anunciar doAbort aos panicip:mtes que já enviaram seus votos. Alguns participames lemos podem tentar votar em Sim depois disso, mas seus votos serão ignorados c eles entrarão no estado de incerte:a, conforme descrito anteriormente. Desempenho do protocolo d'e efetivação de duas fases O Desde tJue tudo corrn bem - isto é. que o coordenador, os panicipant.es e a comunicação entre eles não falhem. o protocolo de efcti vação de duas fases envolvendo N participantes pode ser conclufdo com N mensagens e respost:ts canCommit, segu idas de N mensagens doCommir. Ou seja. o custo nas mensagens é proporciona l a 3N e o custo no tempo é o de três rodadas de mensagens. As mensagens haveCommiued não sõo contadas no custo estimado do protocolo, que pode funcionar corretamente sem elas - sua função é pe rmit ir que os servidores excluam informações velhas do coordenador. No pior caso, pode existir arbitrariamente muitas fal has ele serv idor e de comun icação durante o protocolo de efetivação de duas fases. Entretanto, o protocolo é feito para tolerar uma sucessão de falhas (falhas de serv idor ou mensagens perdidas) e é garantido que finalmente seja conclu ído, embora não seja possível especificar um limite de tempo clcmro elo qual ele terminará. Conforme mencionado na seção sobre tem pos limites, o protocolo de cfetivação de duas fases pode causar atrasos consideníveis para pa rti cipantes no estado de inc:e11eza. Esse.s atrasos ocorrem quando o coordenador fal hou c não pode responder aos pedidos de ge1Decision dos participantes. Mesmo que um protOcolo cooperati vo permita aos participantes fazerem pedido de gNDecision p3ruída. cada servidor mantém seu próprio arquivo de recuperação. O gerenciamerno de recuperação descri to na seção anterior deve ser ampliado para tratar com as transações que estão executando o protocolo de efetivação de duas fases no momento em que um servidor falha. Os gerenciadores de recuperação usam dois novos valores de Status: promo, incerto. Esses valores de status aparecem na Figura 14.6. Um coordenador usa ~fetivada para i ndicar que o resu ltado do voto é Sim e pmnto para indicar que o protocolo de efetivação de duas fases está concluído. Um participante usa incerto para indicar que votou ern Sim, mas ainda não conhece o resultado. Doi~ tipos adicionais de entrada perm item que um coordenador registre uma lista de participantes e que um participante registre seu coordenador:

TIÍXJ de entradà

DesçriÇlio ou : take() extrairia desses dois apenas . Na l inguagem L inda não é permitido nenhum acesso direto às tuplas no espaço de tuplas e os processos precisam substituir as tupias nesse espaço, em vez de rnodificOIIent("SiwpeList ", ·• "); NameComponent patlt f 1 = { nc }; SlmpeList shapeListRef= Sltape ListHe/per.nanvw( nc R ef resol•·e(patlt)); Slwpe{ 1sLisT = sltapeListRefal/Siwpes( ); Grapltica/Obj ect g = sList{Of.getAIIState(); } catch(org.omg.CORBA.SystemException e){...}

I

2 3 4

I }

Figura 20.5 Programa cliente em Java para as interfaces CORBA Shape e ShapeList.

inte1face WiliteboardCallback { oneway void cal/back(in int version);

J; Essa interface é implementada corno um objeto CORSA pelo cliente, permitindo que o servidor envie ao clieme um número de versão quando novos objc10s são ad icionados. Mas antes que o serv idor possa fazer isso. o cliente precisa i nformá-lo da referênc ia de objeto remoto de seu obj eto. Para tornar isso possível, a interface SltapeLis1 exige métodos adiciona is, como regis1er c deregi.Her, como segue: int regis1er(jn WhiteboardCallback callback); void deregister(in int callbackld);

Após um clicnue ter obtido uma referência para o objeto SlrapeList e criado uma instância de Wlrirel;oarllCallback, ele usa o método regisTer de SlrapeLi.st para informar o servidor de que está i nteressado em recebe r callbacks. O objeto SlmpeU.~t no servidor é responsável por manter uma lista de cl ientes interessados c notificar a todos eles sempre que seu número de versão aumentar. quando um novo objeto for adicionado. O método arllback é declarado como onell'a_r para que o servidor possa usar chamadas assírtcronas para cviwr ;maso ao noti ficar cada cl iente.

20.2.2 A arquitetura CORBA A arquitetura é projetada para suportar a funç~o de um agente de requisição de objeto (ORB - OIJjeci RequesT Broker) que permite aos clientes invocarem métodos em objetos remotos. onde cl ientes e servidores podem ser implememados em umn variedade de linguagens de programação. Os pri ncipais componentes da arquitetura CORBA estão ilustrados na Figura 20.6. Essa figura deve ser comparada com a Figura 5.7, no caso em que ser:í notado que a arquitetura CORBA contém três componen tes adicionais: o adaptador de objcto, o repositório de implementações e o reposi tório de inrerfaces. O CORBA forn.ece i nvocações estáticas e dinâmicas. As i nvocações estrilicas são usadas quando a i nterface remota do objeto CORBA é conhecida no momento da compilação, permitindo o uso de swbs de cliente e esqueletos de servidor. Se a interface remota não for conhecida no momento da compilação, a invocação dinâmica dever;í ser usada. A maioria dos programadores prefere usar invocação estática, pois ela fornece um modelo de programação mais natural.

dr to

uo

718

SISTEMAS 0 1STRIBUIDOS, CONCEITOS E PROJETO

serv1dor

Re uisi ão Resposta

ou invocação dinamica

ou esqueleto dinâmico

Figura 20.6 Os principais componentes da arquitetura CORBA.

Discutiremos agora os componentes da arquitewra, deix ando as preocupações com a invocação dinâmica por úhimo.

Núcleo ORB O A função do núcleo ORB é semelha me ao do módulo de comunicação da Figura 5.7. Além disso, um núcleo ORB fornece uma i nlerfnce que i nclu i o segui nte: • operações que o permirem ser iniciado c parado; • operações para fazer a conversão em re referências de objeto remoro e stri ngs; • operações para fornecer l isras de argumentos para requisições usando invocação dinâmica.

Adaptador de objeto O A função de um adaprador de objero é fazer a l igação entre objetos CORBA com interfaces IDL e as imerfaces da l inguagem de programação das classes servente> corresponden te. Essa função também i nclu i a dos módulos de referência remota e despachante na Figura 5.7. Um adaptador de obj cto tem as seguintes tarefas: • ele cria referências de objeto remoto para objetos CORBA (veja a Scção 20.2.4); • ele envia cada RM I, por meio de um esqueleto, para o servente apropriado; • ele ativa e desativa serventes. Um adaprador de objeto fornece para cada objeto CORBA um nome de objero exclusivo, o qual faz pane de sua referência de objeto remoto. O mesmo nome é usado sempre que um obj e1o é invocado. O nome do objeto pode ser especificado pela aplicação ou gerado pelo adaprador de objeto. Cada objeto CORBA é registrado em seu adaptador de objeto, o qual mantém uma tabela de obje1os remotos 4ue faz o mapeamento dos nomes de objeros CORBA para seLIS serventes. Cada adaptador de objeto tem seu próprio nome, o qual também faz parte das referências de objeto remoto de todos os objetos CORBA que gerencia. Esse nome pode ser espec ificado pela aplicação ou gerado automaticamente.

Adaptador de objeto portável O O padrão CORBA 2.2 para adaplador de objetos é chamado Por!able Objecr Adapte r (POA). Ele é chamado ponável porque permite que aplicações e serventes sejam executados em ORBs produzidos por diferenres desenvolvedores (Vinosk i 1998]. Isso é obtido por meio da padron ização das classes de esqueleto e das interações entre o POA e os serventes. O POA su porta objetos CORBA com doi s tipos diferentes de tempos de vida: • aqueles cujos tempos de vida são restri tos ao do processo cm que seus serventes são instanciados; • e aqueles cujos 1cmpos de vida podem abranger as instanciações de serventes em vários processos. Os primeiros têm referências de objeto transientcs c os úlrirnos têm referências de objero persisrentes (veja a Seção 20.2.4).

'111

r I

'l I

(APIIULO 20 • ESTUDO DE ( ASO: CORBA

721

module Whiteboard I struct Recranglel

... } ; srruct GraphicaiOIJject {

...}; imeiface Shape I ... }; t)'pedefsequence Ali; imeiface ShapeList I

... }; };

Figura 20.7 Módulo de lO L Whiteboard.

exemplos, os leiwres verão que uma interface define um conj unto de operações e at ributos, e geralmente depende de um conjunto de tipos definidos com ela. Por exemplo. a interface PersonList. na Figura 5.2, define um atributo e três métodos. e depende do tipo Person.

Métodos IDL O A forma geral de uma assinatura de método é a segui nte : {oneway} (parâmetro I, ...,parâmetroL) [raises (exceçãol, ..., exceçãoN)][comexw (nome / , ... , nomeM)] onde as expressões entre colchetes são opc ionais. Para um exemplo de assinatura de método que con tém apenas as partes exigidas, considere:

void getPerson(in string name, out Person p); Conforme explicado na i ntrodução da Seção 20.2, os parâmetros são ron1lados como in, out ou inour. onde o valor de um parâmetro in é passado do cl iente para o objeto CORBA invocado e o valor de um parâmetro out é passado de volta do objeto CORBA invocado para o cliente. Raramente são usados parâmetros rotulados como inout, mas eles indicam que o valor do parâmetro pode ser passado nas duas direções. O tipo de retorno pode ser especificado como void, caso nenhum valor deva ser retornado. A expressão opcional oneway i ndica que o cl iente que está invocando o método nâo será bloqueado enqu anto o objeto de destino estiver execu tando o método. Além disso, as invocações oneway são executadas uma vez ou nenhuma - isto é, com se mân tica de invocação maybe. Vimos o segui nte exemplo na Seção 20.2. 1:

Ollf!Wa)' void callback(in int version); Nesse exemplo. onde o servidor chama um cliente sempre que uma nova fi gura é adicionada. uma requisição perdida, ocasional, mio é problema para o cliente, pois a chamada apenas indica o número de versão· mais recente e é improvável que chamadas subseqüentes sejam perdidas. A expressão opcional raises indica as exceções definidas pelo usuário que podem ser disparnd;,s para terminar uma execução do método. Por exemplo, considere o exemplo a seguir da Figura 20. I:

exception Fui/Exception{ ); Shape newShape(in GraphicaiObject g) mises (Fui/Erception): Com a ex pressão rai.res. o método newShape especifica que ele pode disparar uma exccção chamada Fui/Exception, que está definida dentro da interface ShapeList. Em nosso exemplo, a exceção não contém variáveis. Entretanto, as exceções podem ser definidas para conter vari áveis, por exemplo:

exception Fui/Exception IGraphico/Object g }; Quando uma exceção que contém variáveis é disparada. o servidor pode usar as variáveis para retornar informações para o cliente sobre o contexto da exceçiio.

\1 tu I o

di

S

tOr'!IS

722

SISTEMAS 0 1STRIBUIOOS, CONCEITOS E PROJETO

O CORBA também pode produzir exccçõcs de sistema relacionadas a problemas nos servidores, como o fato de eles es1arem ocupados demais ou não poderem ser ativados, problemas com a comunicação c problemas no lado do cl ieme. Os programas cliemes devem tratar de exceçõcs definidas pelo usuário e de sistema. A expressão opcional context é usada para fornecer mapeamentos de nomes de stri ng para valores de string. Consulte Baker [1997 ] para ver uma ex plicação de context.

Tipos de IDL O A IDL suporta 15 tipos prim iti vos, os quais incluem shon (16 bi ts),/ong (32 bits). tmsigned shorr, tmsigned long,jloar (32 bits), doub/e (64 bits), char, boo/ean (TRUE, FALSE), octet (8 bits) e any (que pode representar qualquer tipo primitivo ou construído). Constantes da maioria dos tipos pri mitivos e strings conswntes podem ser declaradas usando-se a palavra-chave co11st. A IDL fornece um tipo especia l chamado Object, cujos valores são referências de objeto remoto . Se um parâmetro, ou resultado, é de tipo Object, então o argumemo correspondente pode se referir a qualquer objeto CORBA. Os tipos constmídos da IDL estão descritos na Figura 20.8, todos os quais são passados por valor em argumemos e resultados. Todos os arrays, ou seqliências, usados como argumentos devem ser definidos em typede.fs. Nenhum dos tipos de dados prim itivos ou constmídos pode conter referências .

At ributos O As interfaces IDL podem ter atributos, assim como métodos. Os atributos são como os campos de classe pública em Java. Eles podem ser definidos como readonly, onde ror apropriado. Os atributos são pri vativos dos objetos CORBA, mas para cada atributo declarado, dois métodos de acesso são gerados automaticamente pelo compi lador de IDL, um para recu perar o valor do atributo e o outro para configurá- lo. Para atri butos readm1ly é fornecido apenas o método de obtenção (getter). Por exemplo, a i nterface PersonList defini da na Figura 5.2 inclui a seguinte definição de atributo: readonly auribute string /istname;

TIPo'

..

., ..)

~":

t;.· ..•

' '•l"i'

sequence

t}1Jedefsequence Ali: typedefsequence AI/ seqüências limitadas e não limitadas de Slwpes

Define um tipo para urna seqüência de elementos de comprimento variável de um 1ipo IDL especificndo. Pode ser especificado um limite superior para o comprimento.

string

string 1wme: typedef string Smai/Srring; seqiiêncins limitadas e não limitadas de caracteres

Define uma seqUência de carncteres. terminada pelo caractere nulo. Pode ser especificado um limite superior pM!l o comprimento.

array

rypedef octet uniqueld[ I 2 }: typedef Graphica/Object G0[/0}(8}

Define um tipo parn uma seqUência multidimensional de elementos de comprimento fixo de um tipo I DL especificado.

record

struct Craphica!Object [ string type; Rectangle e11closing: boolean isFilled;

Define um tipo para um registro contendo um grupo de entidades relacionadas. Structs são passadas por va lor em argumentos e resultados.

}:

enumerated

emun Rand I Exp, Number. Name):

O tipo enumerado na IDL faz o mapeamento de um nome de tipo parn um pequcn0-4??

broadcost direcionado 593-594

c cache 46-47, 52·53. 521 coerência de arquivos armazenados ern 550-551 cache wcb Squirrcl 368-371 cadeia de cenificados 248-249, 266-267 callback

na invocação de método remoto do CORBA 11~11 nu invocação a método remoco do Java 194 camada de aplicação 79-82 ç;lmalgorirmos 267-268 e politica 268-269 na segumnç" da XML 695-696 criptografia assimétrica 253-254, 259-261 criptografia de chave pública 259-261 criptografia de curva elíptica 260-261 criptogmfia simé:ric.a 253-254 CSMA/CA 117 CSMA/CD 112 cursoJ94-395 Cyberfomging 609-61 O

D d:u1o'\ f'rírit·o~ com reh,ção ao lempo 51-52

datagrtlma 83. 95 delegação (de direitos) 252 depurando programas distribufdos 392-393. 398-404 DES (Data Encryption Standard) 257-258, 267-268 desafio, para autenticação 246 descobena de dispositivos 575-576 descobena de serviço w:ia serviço de descoberta

desempacotamento 137- 138 desempenho de saída 51 -52 dcspachunte 174-175 em serviços web 685 genérico na RMI Java 194-195 noCORBA 718-719 detecção de colisão 11 3-114 detecção de témlino 392-393 detector de falha 409-411 para resolver consenso 441-442 DHCP ( Dynamic Host Configuration Protocol) 99-100, 103-104. 574-575 difusão (na criptografia) 255-256 direitos de acesso 62-64 disponibilidade 33. 521.536-553 dispositivo móvel 49 Domain Name System (DNS) 106-107, 332-339 consulta 334 implementação do BSD 337-338 navegação 336-337 nome de domfnio 333- 334 registro de recurso 336-337 servidor de nomes 335-339 zona 335 domfnio de atribuição de nomes 329 domínio de proteção 249-250 download de código 26-27 na invocaçiio a método remoto Java 190- 191 DSL ( Digital Subscriber Line) 75-76, SS-89 DSM ' 'eja memória compartilh(lda distribuída

E efctivação 451 eleição 416-422 algoritmo valentão 419-421 de processos em um b:"cado• no tempo 625-626 fluxo' de dudos i>ócrono; 625-626 fom1mo de uúfcgo (para dado• rnuhimfdial 631-632 frame nday ··~ja rede.fmmf rr/ay Freenet 350.351. 353-355 fmm nu/ 52-1-525 FTP 81-83.91-92. 108-110 função de alçapão 253-254 função de hashing l 154·155

H Handle System 327-328 heterogeneidade 28-29. 290-292 serviço de nome 329-330 histórico 380.381 do servidor opcrnçõc~ e11 requtição c resposta 148- 149 TCP 133-134 transação 448-449 UDP 110- 11 1 modelo de interação 55-60 modelo de objcto distribuído 16!2 comparado com serviços web 681 ~68 2 modelo de scgurançu62·67 modelo swulbo.r de protcçiio 240 modelos de arquitctura ~ modelos fundamentais 54-67

2&-29. "-0:!11, l~Uí5

c heterogeneidade 164-165 suporte do sisrem:• operacional para 200-201

misturando 606-607 mobilclP 103- 105

modo de visualização. de grupo t•eja grupo, modo de visuuliz;.tçi\o modo supervisor 204-205 módulo de referência remota 174 montagem de pacote S2.:&3

morcego :uivo '\96-"07 MTU lreja unidade de 1ransfcréncía m{tXimn mud:mça de e.-cala

3(~33

289- 290

mu/Jicll.st 420.413

atómico 428-429 básico 423 confiável 156- 157. 424· 427 disrribuiçilo com ordem FIFO 426·427. 429-430 distribuição por ordcmu:;iío causal 4?7-4?8 ~ 1-432 distribuição totalmente ordenuda 4?7-410 grupo 4?0-422 operação IS1- I S4 ordenado 426-433 pam dados ele alta disponibilidade I S1-154 para dados replicados 156-1 'i7 para grupos sobrepostos 433 para notificações de evento l.il:IS!I. pam serviços de de web 675-676. 681-68? pásSi\'0 177-178 proteçiio 62 64 rcl(:n!ncia 167-168 rcl'érência remota 162: 110 objcto distribuído 168-162 comunicação 166- 1811 modelo 1..62 objeto persi stente 177- 178 no serviço de estado per.i,tcntc do CORBA ]?ó-7?7 ohjcto remoto 162 instanciaçiio l.1!h.I1.J OccnnStore 370-374 OMG (Object Managcmcnt Group) 7 11 Opcn ~1obi lc Alliancc (OMAJ 6()7-608 Opcn Shortc't Path 1-in.t (0SPI'J97-98 operação :t 127-128 opcrnções conll itantcs 454·455 opemções de :1rquivo no modelo de ;en•iço de arquivo simple.< 293-29-1 no modelo de •erviço de dirctório ~