Livro Sistemas Distribuidos Principios e Paradigmas - Tanembaum 2a ed

Prévia do material em texto

SISTEMAS DISTRIBUiDOS
~yt~c~~iO$ e ~CtrCt~igVVt,Ct$
2Q edi900
Andrew S. Tanenbaum
Maarten Van Steen
Tradu~ao
Arlete Simille Marques
Engenheira Qufmica - UFPR
Revisao Tecnica
. Wagner Luiz Zucchi
Professor doutor do Departamento de Sistemas Eletronicos da
Escola Politecnica da Universidade de Sao Paulo
PEARSON
Prentice
Hall
Sumario
Prefacio IX
1. Introducao
1.1 Defini«ao de urn sistema distribuido 1
1.2 Metas 2
1.3 Tipos de sistemas distribufdos 10
1.4 Resumo 18
2.1 Estilos arquitet6nicos 20
2.2 Arquiteturas de sistemas................................................................................................................................................................. 22
2.3 Arquiteturas versus middleware 32
2.4 Autogerenciamento em sistemas distribufdos.: 35
3.1 Threads 42
3.2 Virtual iza«ao 48
3.3 Clientes 50
3.4 Servidores 53
3.5 Migra«ao de c6digo 62
3.6 Resumo 67
4.1 Fundamentos 69
4.2 Chamada de procedimento remoto 75
4.3 Comunica«ao orientada a mensagem 84
4.4 Comunica«ao orientada a fluxo 95
4.6 Resumo 105
5.1 Nomes, identificadores e endere«os 108
5.2 Nomea«ao simples 110
5.3 Nomea«ao estruturada 118
5.4 Nomea«ao baseada em atributo 131
5.5 Resumo 137
6.1 Sincroniza«ao de rel6gios 140
6.2 Re16gios 16gicos....................................................................................................................... 147
6.3 Exclusao mutua 152
6.4 Posicionamento global de n6s 157
6.5 Algoritmos de elei«ao 159
6.6 Resumo 163
7.1 Introdu«ao 165
7.2 Modelos de consistencia centrados em dados 167
7.3 Modelos de consistencia centrados no cliente 174
7.4 Gerenciamento de replicas 178
7.5 Protocolos de consistencia 185
7.6 Resumo 191
8.1 Introdu«ao 11 tolerancia a falha 194
8.2 Resiliencia de processo 198
8.3 Comunicar;ao confiavel cliente-servidor 203
8.4 Comunicar;ao confiavel de grupo 207
8.5 Comprometimento distribuido 215
8.6 Recuperar;ao 220
8.7 Resumo 226
9.1 Introdur;ao 11 seguranr;a 228
9.2 Canais seguros 240
9.3 Controle de acesso 250
9.4 Gerenciamento da seguranr;a 259
9.5 Resumo 266
10.1 Arquitetura 268
10.2 Processos 272
10.3 Comunicar;ao 275
10.4 Nomear;ao : 281
10.5 Sincronizar;ao 284
10.6 Consistencia e replicar;ao 285
10.7 Tolerancia a falba 288
10.8 Seguranr;a 291
10.9 Resumo 294
11.1 Arquitetura 296
11.2 Processos 302
11.3 Comunicar;ao 303
11.4 Nomear;ao 306
11.5 Sincronizar;ao 310
11.6 Consistencia e replicar;ao 314
11.7 Tolerancia a falha 320
11.8 Seguranr;a , 322
11.9 Resumo 328
12.1 Arquitetura 330
12.2 Process os 335
12.3 Comunicar;ao 339
12.4 Nomear;ao 344
12.5 Sincronizar;ao 345
12.6 Consistencia e replicar;ao 346
12.7 Tolerancia a falha 353
12.8 Seguranr;a 354
12.9 Resumo 355
13.1 Introdur;ao a modelos de coordenar;ao 357
13.2 Arquiteturas 358
13.3 Processos 364
13.4 Comunicar;ao 364
13.5 Nomear;ao 365
13.6 Sincronizar;ao 367
13.7 Consistencia e replicar;ao 367
13.8 Tolerancia a falha 371
13.9 Seguranr;a , 374
13.10 Resumo 375
14.1 Sugest6es para leitura adicional.. 377
14.2 Bibliografia em ordem a1fabetica 382
Prefacio
Sistemas distribuidos sao uma area da ciencia da computa<;ao que esta mudando rapidamente. Nos ultimos anos vem
surgindo novos t6picos muito interessantes, como computa<;ao peer-to-peer e redes de sensores, enquanto outros
amadureceram muito, como servi<;os Web e aplica<;6es Web em geral. Mudan<;as como essas exigiram uma revisao de
nosso texto original para que ficasse atualizado.
Esta segunda edi<;aoreflete uma grande revisao em compara<;ao com a anterior. Adicionamos urn capitulo especifico
sobre arquiteturas, que reflete 0 progresso alcan<;ado na organiza<;ao de sistemas distribuidos. Vma outra diferen<;a
importante e que, agora, ha muito mais material sobre sistemas descentralizados, em particular computa<;ao peer-to-peer.
Nao nos limitamos a discutir apenas as tecnicas basicas, mas tambem demos aten<;ao as suas aplica<;6es, como
compartilhamento de arquivo, divulga<;a? de informa<;6es, redes de entrega de conteudo e sistemas publicar/subscrever.
Assim como esses dois assuntos importantes, ainda discutimos novos assuntos em todo 0 livro. Por exemplo,
adicionamos material sobre redes de sensores, virtualiza<;ao, clusters de servidores e computa<;ao em grade. Demos
aten<;ao especial ao autogerenciamento de sistemas distribuidos, urn t6pico cada vez mais importante dado 0 continuo
crescimento da escala desses sistemas.
Certamente, modemizamos 0 material onde foi adequado. Por exemplo, quando discutimos consistencia e
replica<;ao, era agora focalizamos modelos de consistencia mais apropriados para sistemas distribuidos modemos mais
do que os modelos originais, que foram talhados para computa<;ao distribuida de alto desempenho. Da mesma maneira,
adicionamos material sobre modemos algoritmos distribuidos, entre eles algoritmos de sincroniza<;ao de rel6gio e de
localiza<;ao baseados em GPS.
Embora isso nao seja comum, conseguimos reduzir 0 numero total de paginas. Essa redu<;ao e causada, em parte,
pela exclusao de assuntos como coleta distribuida de lixo e protocol os de pagamento eletr6nico, e tambem pela
reorganiza<;ao dos quatro ultimos capitulos.
Como na edi<;ao anterior, 0 livro e dividido em duas partes. Principios de sistemas distribuidos sao discutidos do
Capitulo 2 ao Capitulo 9, enquanto as abordagens globais dos modos de desenvolvimento de aplica<;6es distribufdas (os
paradigmas) sao discutidas do Capitulo 10 ao Capitulo 13. Entretanto, diferente da edi<;ao anterior, decidimos nao
discutir estudos de casos completos nos capftulos dedicados a paradigmas. Em vez disso, agora cada principio e
explicado por meio de urn caso representativo. Por exemplo, invoca<;6es de objeto sao discutidas como urn principio de
comunica<;ao no Capitulo 10 sobre sistemas distribufdos baseados em objetos. Essa abordagem nos permitiu condensar
o material, mas tambem tomou a leitura e 0 estudo mais agradaveis.
Claro que continuamos a recorrer extensivamente a prMica para explicar 0 que sao, afinal, sistemas distribufdos.
Varios aspectos de sistemas utilizados na vida real, como WebSphere MQ, DNS, GPS, Apache, Corba, Ice, NFS,
Akamai, TIBlRendezvous, Jini e muitos outros sao discutidos em todo 0 livro. Esses exemplos ilustram a tenue divisao
entre teoria e pratica, que toma a area de sistemas distribufdos tao interessante.
Muitas pessoas contribufram para este livro de divers as maneiras. Gostarfamos de agradecer em especial a
D. Robert Adams, Amo Bakker, Coskun Bayrak, Jacques Chassin de Kergommeaux, Randy Chow, Michel Chaudron,
Puneet Singh Chawla, Fabio Costa, Cong Du, Dick Epema, Kevin Fenwick, Chandana Gamage, Ali Ghodsi, Giorgio
Ingargiola, Mark Jelasity, Ahmed Kamel, Gregory Kapfhammer, Jeroen Ketema, Onno Kubbe, Patricia Lago, Steve
MacDonald, Michael J. McCarthy, M. Tamer Ozsu, Guillaume Pierre, Avi Shahar, Swaminathan Sivasubramanian,
Chintan Shah, Ruud Stegers, Paul Tymann, Craig E. Wills, Reuven Yagel e Dakai Zhu pel a leitura de partes do
manuscrito e por terem ajudado a identificar erros cometidos na edi<;ao anterior e oferecido comentarios uteis.
Por fim, gostarfamos de agradecer a nossas farmlias. Ate agora, Suzanne ja passou por esse processo dezessete
vezes. E muito para mim, mas tambem para ela. Ela nunca disse: "Agora, chega!", embora eu tenha certeza de que teve
vontade de dizer. Obrigado. Agora, Barbara e Marvin tern uma ideia muito melhor do que professores fazem para viver
e sabem quais sao as diferen<;as entre urn born e um mau livro didMico. Agora eles sao uma inspira<;ao para eu tentar
produzir mais bons do que maus livros (AST).
Como tirei uma licen<;a para atualizar 0 livro, 0 trabalho de escrever tambem ficou muito mais agradavel para
Marielle. Ela esta apenas come<;ando a se acostumar com ele, mas continua a me dar suporte e a me alertar quando e
tempo de voltar rninha aten<;ao a assuntosmais importantes. Eu the devo muito. A essa altura, Max e Elke ja tem uma
ideia muito melhor do que significa escrever um livro, porem, em cornpara<;ao com 0 que eles mesmos estao lendo,
acham diffcil entender 0 que ha de tao interessante nessas coisas estranhas que chamamos sistemas distribufdos. E eu
nao posso culpa-Ios (MvS).
Companion Website
i
·0 Companion Website desta edi<;ao (www.prenhall.com/tanenbaum_br)ofereceumconjuntocompleto de apre-
senta<;6es em PowerPoint para auxiliar os professores a preparar suas aulas, assim como manual de solu<;6es em
ingles. Esse material pode ser acessado por meio de uma senha, e, para obte-Ia, os professores devem entrar
o •• 0 em contato com um representante Pearson ou enviar urn e-mail parauniversitarios@pearsoned.com.
'0 •
Introdu~ao
Os sistemas de computac;ao estao passando por uma
revoluc;ao. Desde 1945, quando comec;ou a era modem a
dos computadores, ate aproximadamente 1985, os com-
putadores eram grandes e caros. Mesmo os minicomputa-
dores custavam no minimo dezenas de milhares de d6la-
res cada. 0 resultado e que a maioria das organizac;6es
tinha apenas alguns poucos computadores e, na falta de
urn modo de conecta-Ios, eles funcionavam independente-
mente uns dos outros.
Contudo, mais ou menos a partir de meados da deca-
da de 1980, dois avanc;os tecnol6gicos comec;aram a mudar
es a situac;ao. 0 primeiro foi 0 desenvolvimento de micro-
processadores de grande capacidade. De infcio, eram
maquinas de 8 bits, mas logo se tomaram comuns CPUs de
16,32 e 64 bits. Muitas dessas CPUs tinham a capacidade
de computac;ao de urn mainframe - isto e, urn grande
computador central-, mas por uma frac;ao do prec;o dele.
A quantidade de melhorias que ocorreu na tecnologia
de computadores nos ultimos 50 anos e verdadeiramente
as ombrosa e totalmente sem precedentes em outros seto-
re . De uma maquina que custava dez milh6es de d61ares
e executava uma instruc;ao por segundo, chegamos a
maquinas que custam mil d61ares e podem executar urn
bilhao de instruc;6es por segundo, urn ganho prec;o/desem-
penho de 1013. Se os carros tivessem melhorado nessa pro-
porc;ao no mesmo periodo de tempo, urn Rolls Royce cus-
taria agora urn d61ar e faria urn bilhao de milhas por galao.
(Infelizmente, e provavel que tamMm tivesse urn manual
de 200 paginas para ensinar como abrir a porta.)
o segundo desenvolvimento foi a invenc;ao de redes
de computadores de alta velocidade. Redes locais, ou
LANs (local-area networks), permitem que centenas de
maquinas localizadas dentro de urn ediffcio sejam conec-
tadas de modo tal que pequenas quantidades de informa-
c;ao possam ser transferidas entre maquinas em alguns
microssegundos, ou algo parecido. Maiores quantidades
de dados podem ser movimentadas entre maquinas a
taxas de 100 milh6es a 10 bilh6es de bits/so Redes de
longa distancia, ou WANs (wide-area networks), per-
mitem que milh6es de maquinas no mundo inteiro se
conectem a velocidades que variam de 64 Kbits/s a giga-
bits por segundo.
o resultado dessas tecnologias e que, atualmente, nao
somente e viavel, mas tambem facil, montar sistemas de
computac;ao compostos por grandes quantidades de com-
putadores conectados por uma rede de alta velocidade.
Esses sistemas costumam ser denominados redes de com-
putadores ou sistemas distribuidos, em comparac;ao com
os sistemas centralizados (ou sistemas monoprocessa-
dores) anteriores, que consistem em urn unico computa-
dor, seus perifericos e, talvez, alguns terrninais remotos.
1.1 Uefini~ao de urn Sistema UistribuTdo
Varias definic;6es de sistemas distribuidos ja foram
dadas na literatura, nenhuma delas satisfat6ria e de acor-
do com nenhuma das outras. Para nossa finalidade, e sufi-
ciente dar uma caracterizac;ao sem ser muito especifica:
Um sistema distribufdo e um conjunto de compu-
tadores independentes que se apresenta a seus
usuarios como um sistema unico e coerente.
Essa definic;ao tern varios aspectos importantes. 0
primeiro e que urn sistema distribuido consiste em com-
ponentes ,;to e, computadores) autonomos. Urn segundo
aspecto e que os usuarios, sejam pessoas ou programas,
acham que estao tratando com urn unico sistema. Isso sig-
nifica que, de urn modo ou de outro, os componentes
autonomos precis am colaborar. Como estabelecer essa
colaborac;ao e 0 ceme do desenvolvimento de sistemas
distribuidos. Observe que nenhuma premissa e adotada
em relac;ao ao tipo de computadores. Em principio, ate
mesmo dentro de urn unico sistema, eles poderiam variar
des de computadores centrais (mainframes) de alto desem-
penho ate pequenos n6s em redes de sensores. Da mesma
maneira, nenhuma premissa e adotada quanta ao modo
como os computadores sao interconectados. Voltaremos a
esses aspectos mais adiante neste capitulo.
Em vez de continuar com definic;6es, talvez seja
mais util que nos concentremos em' caracterfsticas impor-
tantes de sistemas distribuidos. Uma caracterfstica impor-
tante e que as diferenc;as entre os vanos computadores e 0
modo como eles se comunicam estao, em grande parte,
ocultas aos usmirios. 0 mesmo vale para a organizac;ao
interna do sistema distribufdo. Uma outra caracterfstica
importante e que uswirios e aplicac;6es podem interagir
com urn sistema distribufdo de maneira consistente e uni-
forme, independentemente de onde a interac;ao ocorra.
Em principio, tambem deveria ser relativamente
facil expandir ou aumentar a escala de sistemas distribuf-
dos. Essa caracterfstica e uma conseqtiencia direta de ter
computadores independentes, porem, ao mesmo tempo,
de ocultar como esses computadores realmente fazem
parte do sistema como urn todo. Em geraI, urn sistema
distribufdo estara continuamente disponfveI, embora
algumas partes possam estar temporariamente avariadas.
Usuarios e aplicac;6es nao devem perceber quais SaG as
partes que estao sendo substitufdas ou consertadas, ou
quais SaGas novas partes adicionadas para atender a mais
usuarios ou aplicac;6es.
Para suportar computadores e redes heterogeneos e,
simultaneamente, oferecer uma visao de sistema unico, os
sistemas distribufdos costumam ser organizados por meio
de uma camada de software - que e situada Iogicamente
entre uma camada de nfvel mais alto, composta de usua-
rios e aplicac;6es, e uma camada subjacente, que consiste
em sistemas operacionais e facilidades basicas de comu-
nicac;ao, como mostra a Figura 1.1. Por isso, tal sistema
distribufdo as vezes e denorninado middleware.
Figura 1.1 Sistema distribuido organizado como middleware.
A camada de middleware se estende por varias
maquinas e oferece a mesma interface a cada aplica<;:ao.
A Figura 1.1 mostra quatro computadores em rede e
tres aplicac;6es, das quais a aplicac;ao B e distribufda para
os computadores 2 e 3. A mesma interface e oferecida a
cada aplicac;ao. 0 sistema distribufdo proporciona os
meios para que os componentes de uma unica aplicac;ao
distribulda se comuniquem uns com os outros, mas tam-
bem perrnite que diferentes aplicac;6es se comuniquem.
Ao me mo tempo, ele ocuIta, do melhor e mais razoavel
modo po fyel. as diferenc;as em hardware e sistemas ope-
ra ionais para cada aplicac;ao.
e er posslvel montar sistemas distribuldos
e: sariamente que essa seja uma boa
a tecnologia corrente, tambem e possf-
vel colocar quatro drives de disco flexfvel em urn compu-
tador pessoal. A questao e que nao teria sentido fazer isso.
Nesta sec;ao, discutiremos quatro metas importantes que
devem ser cumpridas na construc;ao de urn sistema distri-
bUldo para que valha a pen a 0 esforc;o. Urn sistema dis-
tribuldo deve oferecer facil acesso a seus recursos; deve
ocultar razoavelmente bem 0 fato de que os recursos SaG
distribufdos por uma rede; deve ser aberto e deve poder
ser expandido.
A principal meta de urn istema distribufdo e facili-
tar aos usuanos, e as aplica<;:6es, 0 acesso a recursos
remotos e seu compartilhamenrode maneira controlada e
eficiente. Os recursos podem ser muito abrangentes, mas
entre os exemplos tfpicos estao impressoras."computado-
res, facilidades de armazenamento, dados, paginas Web e
redes, s6 para citar alguns. Ha muitas raz6es para querer
compartilhar recursos, e uma razao 6bvia e a economia.
Por exemplo, e mais barato perrnitir que uma impressora
seja compartilhada por diversos usuanos em urn pequeno
escrit6rio do que ter de comprar e manter uma impresso-
ra direcionada a cada usuano. Do mesmo modo, em ter-
mos econornicos, faz sentido compartilhar recursos de
alto custo como supercomputadores, sistemas de armaze-
namento de alto desempenbo, images etters e outros peri-
fericos caros.
Conectar usuarios e recursos tambem facilita a cola-
borac;ao e a troca de informac;6es, 0 que e claramente ilus-
trado pelo sucesso da Internet com seus protocolos sim-
ples para trocar arquivos, correio, documentos, audio e
vfdeo. Agora, a conectividade da Internet esta Ievando a
vanas organizac;6es virtuais nas quais grupos de pessoas
muito dispersas geograficamente trabalham juntas por
meio de groupware, isto e, software para edic;ao colabo-
rativa, teleconferencia e assim por diante. Da mesma
maneira, a conecti idade da Internet possibilitou 0 comer-
cio eletronico, que nos perrnite comprar e vender todos os
tipos de mercadoria sem ter de realmente ir a uma Ioja ou
ate mesmo sair de casa.
Contudo, a medida que a conectividade e 0 compar-
tilhamento crescem, a seguranc;a se torna cada vez mais
importante. a prlitica corrente, os sistemas ofere cern
pouca protec;ao contra bisbilhotice ou intrusao na comu-
nicac;ao. Senhas e outras informac;6es sensfveis muitas
vezes sao enviadas como texto comum - isto e, nao crip-
tografado - pela rede, ou armazenadas em servidores
que podemos apenas esperar que sejam confiaveis. Nesse
sentido, ha muito espac;o para melhorias. Por exemplo,
hoje e posslvel fazer pedidos de mercadorias informando
apenas urn numero de cartao de credito.'Raramente e soIi-
citada uma prova de que 0 cliente seja 0 proprietario do
cartao. No futuro, fazer pedidos desse modo s6 sera pos-
slvel se voce realmente provar que possui 0 cartao em
maos, inserindo-o em uma Ieitora de cart6es.
Urn outro problema de seguranc;a e 0 rastreamento
de comunica~6es para montar urn perfil de preferencias
de urn usuano especffico (Wang et aI., 1998). Esse ras-
treamento e uma viola~ao explicita da privacidade, em
especial se for feito sem avisar 0 usmirio. Urn problema
relacionado e que maior conectividade tambem pode
resultar em comunica~ao indesejavel, como envio de
mala direta sem permissao, muitas vezes denominada
spam. Nesses casos, talvez precisemos nos proteger usan-
do filtros especiais de informa~6es que selecionam men-
agens de entrada com base em seu conteudo.
1.2.2 Transparencia da distribuicao
Uma meta importante de urn sistema distribufdo e
ocultar 0 fato de que seus processos e recurs os estao fisi-
amente distribufdos por varios computadores. Urn siste-
ma distribufdo que e capaz de se apresentar a usuarios e
aplicac;6es como se fosse apenas urn unico sistema de
omputador e denominado transparente. Em primeiro
lugar, vamos examinar quais saG os tipos de transparencia
que existem em sistemas distribufdos. Em seguida, abor-
daremos a questao mais geral sobre a decisao de se a
rransparencia e sempre requerida.
o conceito de transparencia pode ser aplicado a
di\'ersos aspectos de urn sistema distribuido - os mais
importantes sao mostrados na Tabela 1.1.
Transparencia Descri~ao
cesso Oculla diferengas na represenlagao de dados e
no modo de acesso a um recurso
LocaJizagao Oculla 0 lugar em que um recurso esla localizado
Migragao Oculla que um recurso pode ser
movido para oulra localizagao
Relocagao Oculla que um recurso pode ser movido para
uma oulra localizagao enquanto em uso
Replicagao Oculla que um recurso e replicado
Concorrencia Oculla que um recurso pode ser comparlilhado
por diversos usuarios concorrenles
Falha Oculla a falha e a recuperagao de um recurso
Tabela 1.1 Diferentes formas de transparencia em um sistema
distribufdo (ISO. J 995).
Transparencia de acesso trata de ocultar diferenc;as
em representa~ao de dados e 0 modo como os recursos
podem ser acessados por usuarios. Em urn nivel basico,
desejamos ocultar diferen~as entre arquiteturas de maqui-
nas, porem 0 mais importante e chegar a urn acordo sobre
como os dados devem ser representados por maquinas e
sistemas operacionais diferentes. Por exemplo, urn siste-
ma distribuido pode ter sistemas de computac;ao que exe-
cutam sistemas operacionais diferentes, cada urn com
suas proprias conven~6es para nomea~ao de arquivos.
Diferenc;as entre conven~6es de nomea~ao e tambem 0
modo como os arquivos devem ser manipulados devem
ficar ocultos dos usuarios e das aplicac;6es.
Urn importante grupo de tipos de transparencia tern
a ver com a localizac;ao de urn recurso. Transparencia de
localiza(,;ao refere-se ao fato de que os usuarios nao
podem dizer qual e a localiza~ao fisica de urn recurso no
sistema. A nomea~ao desempenha urn papel importante
para conseguir transparencia de localizac;ao.
Em particular, pode-se conseguir transparencia de
localiza~ao ao se atribuir somente nomes logicos aos recur-
sos, isto e, nomes nos quais a localiza~ao de urn recurso
nao esta secretamente codificada. Urn exemplo desse tipo
de nome e 0 URL http://www.prenhall.com/index.html. que
nao da nenhuma pista sobre a localiza~ao do principal ser-
vidor Web da Prentice Hall. 0 URL tambem nao da nenhu-
ma pista se index.html sempre esteve em sua localizac;ao
corrente ou se foi transferido para la recentemente. Diz-se
que sistemas distribufdos nos quais recursos podem ser
movimentados sem afetar 0 modo como podem ser acessa-
dos proporcionam transparencia de migra(,;ao. Ainda
mais vantajosa e a situa~ao na qual recursos podem ser
relocados enquanto estao sendo acessados sem que 0 usua-
rio ou a aplica~ao percebam qualquer coisa. Nesses casos,
diz-se que 0 sistema suporta transparencia de reloca(,;ao.
Urn exemplo de transparencia de reloca~ao e 0 uso movel
de laptops sem fio, cujos usuarios podem continuar a usa-
10 quando vaGde urn lugar a outro sem sequer se desconec-
tar temporariamente.
Como veremos, a replicac;ao desempenha urn papel
muito importante em sistemas distribuidos. Por exemplo,
recursos podem ser replicados para aumentar a disponibili-
dade ou melhorar 0 desempenho colocando uma copia
perto do lugar em que ele e acessado. Transparencia de
replica(,;ao esta relacionada a ocultar 0 fato de que existem
vanas copias de urn recurso. Para ocultar a replica~ao dos
usuanos, e necessario que todas as replicas tenham 0 mes-
mo nome. Por conseqiiencia, urn sistema que suporta trans-
parencia de replicac;ao em geral tambem deve suportar
transparencia de localizac;ao porque, caso contrano, seria
impossivel referir-se a replicas em diferentes localiza~6es.
Ja mencionamos que uma importante meta de siste-
mas distribufdos e perrnitir compartilhamento de recur-
sos. Em muitos casos, esse compartilhamento e coopera-
tivo, como no caso da comunicac;ao. Todavia, tambem ha
muitos exemplos de compartilhamento competitivo de
recursos. Urn deles pode ser 0 caso de dois usuarios inde-
pendentes, em que cada urn pode ter armazenado seus
arquivos no mesmo servidor de arquivosou pode acessar
as mesmas tabelas em urn banco de dados compartilhado.
Nesses casos, e importante que tada usuario nao perceba
que 0 outroesta utilizando 0 mesmo recurso. Esse feno-
meno e denominado transparencia de concorrencia.
Uma questao importante e que 0 aces so concorrente a urn
recurso compartilhado deixe esse recurso em estado con-
sistente. Pode-se conseguir consistencia por meio de tra-
vas de acesso, 0 que da a cada usuario, urn por vez, aces-
so exclusivo ao recurso desejado. Urn mecanismo mais
refinadoe utilizar transa~oes; porem, como veremos em
capftulos posteriores, e bastante diffcil implementar tran-
sa~oes em sistemas distribufdos.
Uma defini~ao alternativa e popular de urn sistema
distribufdo, devida a Leslie Lamport, e "Voce sabe que tern
urn quando a falha de urn computador do qual nunca ouviu
falar impede que voce fa~a qualquer trabalho". Essa des-
cri~ao pontua uma outra questao importante no projeto de
sistemas distribufdos: como tratar falhas. Fazer com que
urn sistema distribufdo seja transparente a falha signifi-
ca que urn usuario nao percebe que urn recurso (do qual
possivelmente nunc a ouviu falar) deixou de funcionar bem
e que, subseqiientemente, 0 sistema se recupero.u da falha.
Mascarar falhas e uma das questoes mais diffceis em sis-
temas distribufdos e ate mesmo impossfveis de se realizar
quando sao adotadas certas prernissas aparentemente rea-
listas, como discutiremos no Capftulo 8. A principal difi-
culdade para mascarar falhas esta na incapacidade de dis-
tinguir entre urn recurso morto e urn recurso insuportavel-
mente lento. Por exemplo, quando contatamos urn servidor
Web ocupado, a certa altura 0 tempo do browser se esgo-
tara e ele avisara que a pagina Web nao esta disponfvel.
Nesse ponto, 0 usuario nao pode concluir se, na verdade,
o servidor esta avariado.
Embora a transparencia de distribui~ao seja geral-
mente considerada preferfvel para qualquer sistema distri-
bufdo, ha situa~oes em que tentar ocultar completamente
dos usuanos todos os aspectos da distribui~ao nao e uma
boa ideia. Urn exemplo e requisitar que seu jornal eletro-
nico apare~a em sua caixa postal antes das 7 horas da
manha, hora local, como sempre, enquanto naquele
momenta voce esta no outro lado do mundo, onde 0 fuso
horario e diferente. Seu jornal matutino nao seraaquele ao
qual voce esta acostumado.
Da mesma maneira, nao se pode esperar que urn sis-
tema distribufdo de longa distancia que conecta urn pro-
cesso em San Francisco a urn processo em Amsterda
oculte 0 fato de que a Mae Natureza nao permitira que ele
envie uma mensagem de urn processo para 0 outro em
menos do que aproximadamente 35 milissegundos. Na
pratica, quando se esta usando uma rede de computado-
res, isso levara varias centenas de rnilissegundos. A trans-
rnissao de sinal nao somente esta lirnitada pela velocidade
da luz, mas tambem pelas capacidades de processamento
dos comutadores intermedianos.
Tambem ha urn comprornisso entre urn alto grau de
transparencia e 0 desempenho de urn sistema. Por exem-
plo, muitas aplica~oes de Internet tentam contatar urn ser-
vidor repetidas vezes antes de finalmente desistir. Por
conseqiiencia, tentar mascarar uma falha transit6ria de
servidor antes de tentar urn outro pode reduzir a velocidade
do sistema como urn todo. Nesse caso, talvez seja melhor
desistir mais cedo ou, ao menos, perrnitir que 0 usuario
cancele as tentativas para fazer contato.
Urn outro exemplo e 0 de precisar garantir que varias
replicas, localizadas em continentes diferentes, devam ser
consistentes 0 tempo todo. Em outras palavras, se uma
c6pia for alterada, essa altera~ao deve ser propagada para
todas as c6pias antes de perrnitir qualquer outra opera~ao.
E claro que, agora, uma unica opera~ao de atualiza~ao
pode demorar ate alguns segundos para ser conclufda,
algo que nao pode ser ocultado dos usuanos.
Por fim, ha situa~oes em que nao e nem urn pouco
6bvio que ocultar distribui<;ao seja uma boa ideia. A medi-
da que sistemas distribufdos estao se expandindo para dis-
positivos que as pessoas carregam consigo, e a pr6pria
no~ao de localiza~ao e percep~ao de contexto esta se tor-
nando cada vez mais importante, pode ser melhor expor
a distribui~ao em vez de tentar oculta-la. Essa exposi~ao
de distribui~ao ficara mais evidente quando discutirmos
sistemas distribufdos embutidos e ubfquos neste capftulo.
Como urn exemplo simples, considere uma funcionana
que quer imprimir urn arquivo que esta em seu notebook.
E melhor enviar 0 trabalho a ser impressa a uma impres-
sora ocupada que esta pr6xima do que a uma desocupada
localizada na sede corporativa em urn pafs diferente.
Tambem ha outros argumentos contra a transparen-
cia de distribui<;ao. Reconhecendo que a total transparencia
de distribui~ao e simples mente impossfvel, devemos nos
perguntar se e ate mesmo sensato dissimular que pode-
mos alcan~a-la. Talvez seja muito melhor tornar a distri-
bui<;aoexplfcita, de modo que 0 usuano e 0 desenvolvedor
de aplica~ao nunca sejam levados a acreditar que existe
uma coisa denorninada transparencia. 0 resultado sera
que os usuarios entenderao de maneira mais clara 0 com-
portamento, as vezes inesperado, de urn sistema distribuf-
do e, por isso, estarao mais bem preparados para lidar
com esse comportamento.
A conclusao e que visar a transparencia de distribui-
<;aopode ser uma bela meta no projeto e na implementa-
~ao de sistemas distribufdos, mas deve ser considerada em
conjunto com outras questoes, como desempenho e faci-
lidade de compreensao. Nem sempre vale a pen a tentar
conseguir total transparencia, pois 0 pre~o que se paga
por isso pode ser surpreendentemente alto.
Uma outra meta importante de sistemas distribufdos
e a abertura. Urn sistema distribuido aberto e urn siste-
ma que oferece servi~os de acordo com regras padroniza-
das que descrevem a sintaxe e a semantica desses servi-
~os. Por exemplo, em redes de computadores ha regras
padronizadas que governam 0 formato, 0 conteudo e 0
significado de mensagens enviadas e recebidas. Tais
regras sao formalizadas em protocolos. No caso de siste-
mas distribufdos, em geral os servic;os sao especificados
por meio de interfaces, que costumam ser descritas em
uma lingua gem de defini~ao de interface (Interface
Definition Language - IDL).
Definic;6es de interfaces escritas em IDL quase sem-
pre capturam apenas a sintaxe de servic;os. Em outras
palavras, elas especificam com precisao os nomes das
func;6es que estao disponfveis, junto com os tipos dos
parametros, os valores de retorno, as possfveis excec;6es
que podem surgir e assim por diante. A parte diffcil e
especificar com precisao 0 que esses servic;os fazem, isto
e, a semantica das interfaces. Na pnitica, tais especifica-
c;6es sao sempre dadas de modo informal por meio de lin-
guagem natural.
Se adequadamente especificada, uma definic;ao de
interface permite que urn processo arbitrario que necessi-
ta de certa interface se comunique com urn outro proces-
so que fornece aquela interface. Pennite tambem que duas
partes independentes construam implementac;6es compl~-
tamente diferentes dessas interfaces, 0 que resulta em dOlS
sistemas distribufdos separados que funcionam exatamen-
te do mesmo modo.
Especificac;6es adequadas sao completas e neutras.
Completa significa que tudo que e necessario para uma
implementac;ao foi, de fato, especificado. Contudo,
muitas definic;6es de interface nao sao absolutamente
completas, portanto e necessario que urn desenvolvedor
adicione detalhes especfficos da implementac;ao. De
igual importancia e 0 fato de que especificac;6es nao
prescrevem como deve ser a aparencia da implementa-
c;ao; elas devem ser neutras. Completude e neutralidade
sao importantes para interoperabilidade e portabilidade
(Blair e Stefani, 1998).
Interoperabilidade caracteriza ate que ponto duas
implementac;6es de sistemas ou componentes de for.nece-
dores diferentes devem coexistir e trabalhar em conJunto,
com base na mera confianc;a mutua nos servic;os de cada
urn, especificados por urn padrao comum ..
Portabilidade caracteriza ate que ponto uma aplica-
c;ao desenvolvida para urn sistema distribufdo A pode ser
executada, sem modificac;ao, em urn sistema distribufdo
diferente B que implementa as mesmas interfaces que A.
Uma outra meta importante para urn sistema distri-
bufdo aberto e que deve ser facil configura-Io com base
em co~ponentes diferentes(possivelmente de desenvol-
vedores diferentes). Alem disso, deve ser facil adicionar
novos componentes ou substituir os existentes sem afetar
os que continuam no mesmo lugar. Em outras palavras,
urn sistema distribufdo aberto deve ser tambem extensf-
vel. Por exemplo, em urn sistema extensfvel, deve ser
relativamente facil adicionar partes que sao executadas
em urn sistema operacional diferente, ou ate mesmo subs-
tituir todo urn sistema de arquivo. Como muitos de nos
sabemos por experiencia propria, e mais facil falar do que
conseguir tal flexibilidade.
Separacao entre porrtica e mecanismo
Para conseguir flexibilidade em sistemas distribuf-
dos abertos, e crucial que 0 sistema seja organizado como
urn conjunto de componentes relativamente pequenos e
de facil substituic;ao ou adaptac;ao. Isso implica que deve-
mos fomecer definic;6es nao somente para as interfaces de
nfvel mais alto, isto e, as que sao vistas por usuarios e
aplicac;6es, mas tambem definic;6es para interfaces com
partes internas do sistema, alem de descrever como essas
partes interagem.
Essa abordagem e relativamente nova. Muitos siste-
mas mais antigos, ou mesmo alguns contemporaneos, sao
construfdos segundo uma abordagem monolftica na qual a
separac;ao dos componentes e apenas logica, embora eles
sejam implementados como urn unico e imenso programa.
Essa abordagem dificulta a substituic;ao ou adaptac;ao de
urn componente sem afetar todo 0 sistema. Portanto, siste-
mas monolfticos tendem a ser fechados em vez de abertos.
A necessidade de alterar urn sistema distribufdo e
quase sempre causada por urn componente que nao forne-
ce a polftica ideal para uma aplicac;ao ou usuario especf-
fico. Por exemplo, considere a cache na World Wide Web.
Em geral, os browsers permitem que os usuarios adaptem
sua polftica de cache especificando 0 tamanho da cache e
se a consistencia de urn documento em cache deve ser
verificada sempre ou se apenas uma vez por sessao.
Contudo, 0 usuario nao pode influenciar outros parame-
tros de cache, como 0 perfodo que urn documento pode
permanecer na cache, ou qual documento deve ser retira-
do quando a cache estiver cheia. Alem disso, e impossfvel
tomar decis6es de cache com base no conteudo de urn
documento. Urn usuario pode querer manter em cache
uma tabela de horarios de trens porque sabe que esses
horarios dificilmente mudam, mas nunca as informac;6es
sobre as condic;6es de trafego correntes nas rodovias.
Precisamos de uma separac;ao entre polftica e meca-
nismo. No caso de cache na Web, por exemplo, 0 ideal
seria que urn browser proporcionasse facilidades apenas
para armazenar documentos e, ao mesmo tempo, pennitis-
se aos usuarios decidir quais documentos teriam de ser
armazenados e por quanta tempo. Na pr<itica, isso pode ser
implementado pela oferta de urn rico conjunto de parame-
tros que 0 usuario pode estabelecer dinamicamente.
Ainda melhor e que urn usuario possa implementar
sua propria polftica sob a forma de urn componente que
possa ser conectado diretamente ao browser. Claro que
esse componente deve ter uma interface que 0 browser
possa entender, de modo que ele possa chamar procedi-
mentos dessa interface.
A conectividade mundial pela Internet esta rapida-
mente se tornando tao comum quanta poder enviar urn
cartao-postal para qualquer pessoa em qualquer lugar do
mundo. Com isso em mente, a escalabilidade e uma das
mais importantes metas de projeto para desenvolvedores
de sistemas distribuidos.
A escalabilidade de urn sistema pode ser medida
segundo, no minima, tres dimens6es diferentes (Neuman,
1994). Em primeiro lugar, urn sistema pode ser escahivel
em relac;ao a seu tamanho, 0 que significa que e facil adi-
cionar mais usuarios e recursos ao sistema. Em segundo
lugar, urn sistema escalavel em termos geograficos e urn
sistema no qual usuarios e recursos podem estar longe uns
dos outros. Em terceiro lugar, urn sistema pode ser esca-
lavel em termos administrativos, 0 que significa que ele
ainda pode ser facil de gerenciar, mesmo que abranja mui-
tas organizac;6es administrativas diferentes. Infelizmente,
urn sistema escalavel em uma ou mais dessas dimens6es
muitas vezes apresenta perda na capacidade de qesempe-
nho a medida que e ampliado.
Quando e necessario arnpliar urn sistema, e precise
resolver problemas de tipos muito diferentes. Em pri-
meiro lugar, vamos considerar a escalabilidade em rela-
c;ao ao tamanho. Se for precise suportar mais usuarios
ou recursos, freqiientemente deparamos com as limita-
c;6es de servic;os centralizados, dados e algoritmos (ver
Tabela 1.2). Por exemplo, muitos servic;os sac centrali-
zados no sentido de que sac implementados por meio de
apenas urn unico servidor que executa em uma maquina
especifica no sistema distribuido. 0 problema com esse
esquema e 6bvio: 0 servidor pode se transformar em urn
gargalo a medida que 0 numero de usuarios e aplicac;6es
cresce. Ainda que tenhamos capacidades de process a-
mento e armazenagem praticamente ilimitadas, a comu-
nicac;ao com aquele servidor acabara por impedir cresci-
mento ulterior.
Infelizmente, as vezes e inevitavel usar apenas urn
unico servidor. Imagine que temos urn servic;o para geren-
ciar informac;6es altamente confidenciais como hist6ricos
medicos, contas de bancos e assim por diante. Nesses
casos, talvez seja melhor implementar 0 servic;o por meio
de urn unico servidor localizado em uma sala separada, de
alta seguranc;a, e protegido em relac;ao as outras partes do
sistema distribuido por meio de componentes de rede
especiais. Copiar 0 servidor para divers as 10calizac;6es
para melhorar 0 desempenho pode estar fora de questao
porque isso tornaria 0 servic;o menos seguro.
Conceito Exemplo
Servi90s centralizados Um Ii.nico servidor para lodos os usuarios
Algoritmos centralizados Fazer roteamento com base em
informa90es com pietas
Tao ruins quanta servic;os centralizados sac dados
centralizados. Como nao perder de vista os numeros de
telefones e enderec;os de 50 milh6es de pessoas? Suponha
que cada registro de dados pudesse caber em 50 caracte-
res. Vma unica partic;ao de disco de 2,5 gigabytes propor-
cionaria armazenamento suficiente. Porem, mais uma vez,
nesse caso, ter urn unico banco de dados sem duvida satu-
raria todas as linhas de comunicac;ao que 0 acessam. Do
mesmo modo, imagine como a Internet funcionaria se seu
Sistema de Nomes de Dominio (Domain Name System-
DNS) ainda estivesse implementado como uma tabela
unica. 0 DNS mantem informac;6es de milh6es de compu-
tadores no mundo inteiro e forma urn servic;o essencial
para localizar servidores Web. Se cada requisic;ao para
resolver urn VRL tivesse de ser passada para aquele unico
servidor DNS, e claro que ninguem estaria usando a Web
- 0 que, por falar nisso, resolveria 0 problema.
Por fim, algoritmos centralizados tambem sac ma
ideia. Em urn sistema distribuido de grande porte, uma
quantidade enorrne de mensagens tern de ser roteada por
muitas linhas. De urn ponto de vista te6rico, urn born
modo de fazer isso e colher informac;6es completas sobre
a carga em todas as maquinas e linhas, e entao executar
urn algoritmo para computar todas as rotas 6timas. Em
seguida, essa informac;ao pode ser propagada por todo 0
sistema para melhorar 0 roteamento.
o problema e que colher e transportar todas as infor-
mac;6es de entrada e saida tambem seria ma ideia porque
essas mensagens sobrecarregariam parte da rede. Na ver-
dade, qualquer algoritmo que colha informac;6es de todos
os sites, envie-as a uma unica maquina para processamen-
to e entao distribua os resultados para todos os sites deve
ser, de maneira geral, evitado. Somente algoritmos des-
centralizados devem ser utilizados. Em geral, esses algo-
ritmos tern as seguintes caracteristicas, que os distinguem
dos algoritmos centralizados:
I. Nenhuma maquina tern informac;6es completas
sobre 0 estado do sistema.
2. As maquinastomam decis6es tendo como base
somente informac;6es locais.
3. A falha de uma maquina nao arruina 0 algoritmo.
4. Nao ha nenhuma premissa implicita quanta a
existencia de urn re16gio global.
As tres primeiras decorrem do que dissemos ate agora.
A ultima talvez seja menos 6bvia, mas tambem e importan-
te. Qualquer algoritmo que comece com "Precisamente as
12:00:00 todas as maquinas anotarao 0 tamanho de sua fila
de saida" falhara porque e impossivel conseguir a exata sin-
cronizac;ao de todos os rel6gios, fato que os algoritmos
devem levar em conta. Quanto maior.o sistema, maior a
incerteza. Talvez seja possivel conseguir a sincronizac;ao de
todos os re16gios com tolerancia de alguns microssegundos
em uma unica LAN, com consideravel esforc;o, mas fazer
isso em escala nacional ou internacional e complicado.
A escalabilidade geognifica tern seus pr6prios pro-
blemas. Vma das principais raz6es por que hoje e diffcil
ampliar sistemas distribufdos existentes que foram origi-
nalmente projetados para redes locais e que eles saG
baseados em cornunica~ao sincrona. Nessa forma de
omunica<;ao, uma parte que requisita urn servi<;o, em
geral denominada cliente, fica bloqueada ate que uma
mensagem seja enviada de volta. Essa abordagem costuma
funcionar bem em LANs nas quais a comunica<;ao entre
duas maquinas, na pior das hip6teses, demora, comumen-
te, algumas centenas de microssegundos. Todavia, em urn
i tema de longa distancia, precisamos levar em conta que
a comunica<;ao entre processos pode demorar centenas de
milissegundos, isto e, ela e tres ordens de grandeza mais
lenta. Construir aplica<;6es interativas usando comunica-
~o sfncrona em sistemas de longa distanciarequer muito
uidado, alem de muita paciencia.
Urn outro problema que atrapalha a escalabilidade
geografica e que a comunica<;ao em redes de longa distan-
ia e inerentemente nao confiavel e quase sempre ponto a
ponto. Por compara<;ao, redes locais em geral proporcio-
nam facilidades de comunica<;ao de alta confian<;a com
ase em broadcast, 0 que facilita muito 0 desenvolvimen-
'0 de sistemas distribufdos. Considere 0 problema de
ocalizar urn servi<;o. Em urn sistema de area local, urn
rocesso pode simplesmente enviar uma mensagem
broadcast a todas as maquinas, perguntando a cada uma
e esta executando 0 servi<;o de que ele necessita. Somen-
te as maquinas que tern aquele servi<;o respondem, cada
uma delas fornecendo seu endere<;o de rede na mensagem
de resposta. Tal esquema de localiza<;ao e inconcebfvel
em urn sistema de longa distancia: imagine s6 0 que acon-
teceria se tentassemos localizar urn servi<;o desse modo
na Internet. Em vez disso, e preciso projetar servi<;os
especiais de localiza<;ao, que talvez tenham alcance mun-
dial e sejam capazes de atender a bilh6es de usuarios.
Voltaremos a abordar esses servi<;os no Capftulo 5.
A escalabilidade geografica esta forte mente relacio-
nada com problemas de solu<;6es centralizadas que atra-
palham a escalabilidade de tamanho. Se tivermos urn sis-
tema com muitos componentes centralizados, e claro que
a escalabilidade geografica estara limitada pelos proble-
mas de desempenho e confiabilidade resultantes da comu-
nica<;ao a long a distancia. Alem disso, nessa circunstancia
os componentes centralizados resultarao em desperdfcio
de recursos de rede. Imagine que urn unico servidor de
correio seja usado por urn pafs inteiro. Isso significaria
que, quando voce enviasse urn e-mail aseuvizinho.pri-
meiro 0 e-mail teria de ir ate 0 servidor central de correio,
que poderia estar a qui16metros de distancia. Claro que
esse nao e 0 melhor caminho.
Por fim, uma questao diffcil e, em muitos casos, ainda
aberta e como ampliar urn sistema distribufdo por vanos
dominios administrativos independentes. Urn problema
irnportante que precisa ser resolvido e 0 de polfticas con-
flitantes em rela<;ao a utiliza<;ao - e pagamento - de re-
cursos, gerenciamento e seguran<;a.
Muitas vezes, por exemplo, os usuarios de urn unico
dominio podem confiar em componentes de urn sistema
distribufdo que residam dentro desse mesmo dominio. Em
tais casos, a administra<;ao do sistema deve ter testado e
certificado aplica<;6es e tornado providencias especiais
para garantir que os componentes nao sofram nenhuma
a<;aoindevida. Em essencia, os usuarios confiam em seus
administradores de sistema. Contudo, essa confian<;a nao
ultrapassa naturalmente as fronteiras do domfnio.
Se urn sistema distribufdo se expandir para urn outro
domfnio, e preciso tomar duas medidas de seguran<;a.
Antes, 0 sistema distribufdo tern de se proteger contra ata-
ques maliciosos do novo domfnio: os usuarios do novo
domfnio podem ter somente acesso de leitura ao sistema
de arquivos no novo dominio original. Da mesma forma,
facilidades como imagesetters CarOSou computadores de
alto desempenho podem nao estar disponfveis para usua-
rios estranhos. Em segundo lugar, 0 novo dominio tern de
se proteger contra ataques maliciosos do sistema distribuf-
do. Urn exemplo tfpico e 0 download de programas como
applets em browsers Web. Basicamente, 0 novo dominio
nao sabe que comportamento esperar de tal c6digo estra-
nho e, portanto, pode decidir impor lirnites severos aos
direitos de acesso para esse c6digo. 0 problema, como
veremos no Capftulo 9, e como impor essas limita<;6es.
Ap6s discutirmos alguns problemas de escalabilida-
de, surge a questao de como resolve-los de maneira geral.
Na maioria dos casos, problemas de escalabilidade em sis-
temas distribufdos aparecem como problemas de des em-
penho causados por capacidade limitada de servidores e
rede. Agora, ha basicamente apenas tres tecnicas para
ampliar sistemas: ocultar latencias de comunica<;ao, distri-
bui<;ao e replica<;ao [ver tambem Neuman (1994)].
Ocultar latencias de comunica<;ao e importante para
conseguir escalabilidade geografica. A ideia basica e sim-
ples: tentar evitar, 0 quanta possfvel, esperar por respos-
tas a requisi<;6es remotas - e potencialmente distantes -
de servi<;os. Vamos supor que urn servi<;o seja requisitado
em uma maquina remota. Uma alternativa a esperar por
uma resposta do servidor e executar outro trabalho Util no
lado do requisitante. Em essencia, isso significa construir
a aplica<;ao requisitante de modo tal que ela use s6 cornu-
nica~ao assincrona. Quando chega uma resposta, a apli-
ca<;aoe interrompida e urn manipulador especial e chama-
do para concluir a requisi<;ao emitida anteriormente.
A comunica<;ao asslncrona muitas vezes pode serusada
em sistemas de processamento de.lotes e em aplica<;6espara-
lelas, nos quais tarefas mais ou menos independentes podem
ser escalonadas para execu<;ao enquanto uma outra tarefa
esm esperando pela conclusao da comunica<;ao. Como alter-
nativa, pode-se iniciar urn novo thread de controle para exe-
cutar a requisi<;ao. Embora ele fique bloqueado it espera da
resposta, outros threads no processo podem continuar.
Colltudo, ha muitas aplica<;6es que nao podem fazer
uso efetivo da comunica<;ao assfncrona. Por exemplo, em
aplica<;6es interativas, quando urn usuano envia uma requi-
si<;ao, em geral ele nao ten! nada melhor a fazer do que
esperar pela resposta. Nesses casos, uma solu<;ao muito
melhor e reduzir a comunica<;ao global, passando parte da
computa<;ao que normalmente e executada no servidor para
o processo do cliente que esta requisitando 0 servi<;o.
Urn caso tfpico em que essa abordagem funciona e 0
acesso a bancos de dados por meio de formularios. 0
preenchimento de formularios pode ser feito com 0 envio
de uma mensagem separada para cada campo e a espera
por urn reconhecimento do servidor, como mostra a
Figura 1.2(a). 0 servidor pode verificar se ha enos de sin-
taxe antes de aceitar uma entrada.
Uma solu<;aomuito melhor e despachar para 0 clien-
te 0 c6digo para preencher 0 formulario e possivelmente
verificar as entradas, alem de fazer com que 0 cliente
devolvaurn formulario completo, como mostra a Figura
1.2(b). Essa abordagem de despacho de c6digo atualmen-
te e amplamente suportada pela Web sob a forma de
applets Java e Javascript.
Uma outra tecnica irnportante de amplia<;ao e a distri-
bui\;ao. A distribui<;ao envolve tomar urn componente, sub-
dividi-Io em partes menores e, na sequencia, espalhar essas
partes pelo sistema. Urn excelente exemplo de distribui<;ao
eo Sistema de Nomes de Dornfnio da Internet. 0 espa<;ode
nomes do DNS e organizado por hierarquia em uma arvo-
re de dominios, dividida em zonas sem sobreposi<;ao,
como mostra a Figura 1.3. Os nomes em cada zona saG
manipulados por urn linico servidor de nomes. Sem entrar
em muitos detalhes, podemos imaginar cada nome de
carninho como 0 nome de urn hospedeiro na Internet e, por
isso, associado a urn endere<;o de rede daquele hospedeiro.
Basicamente, resolver urn nome significa retornar 0
endere<;o de rede do hospedeiro associado. Considere, por
exemplo, 0 nome nl.vu.cs.flits. Para resolver esse nome, pri-
meiro ele e passado ao servidor de zona 21 (ver Figura 1.3),
Primeiro nome IMAARTEN I
Ultimo nome IVAN STEEN I
ISTEEN@CS.VU.NL I
[Q]
Verifique
formulario
Processe
formulario
IMAARTEN I
I ~
IVAN STEEN I •..
ISTEEN@CS.VU.NL I
[Q] .•...
'1f
, ••, \
Venflque
formulario
Processe
formulario
reloma 0 enderec;o do servidor para a zona Z2, para a
o resto do nome, vu.cs.flits, pode ser entregue. 0 servi-
tJaIa Z2 retomara 0 enderec;o do servidor para a zona Z3,
e paz de manipular a ultima parte do nome e retoma-
enderec;o do hospedeiro associado.
E e exemplo ilustra como 0 servi({o de nomea({iio
= ecido pelo DNS e distribufdo por varias maquinas,
_ 'rando, desse modo, que urn unico servidor tenha de
om todas as requisic;6es de resoluc;ao de nomes.
Como outro exemplo, considere a World Wide Web.
a maioria dos usuarios, a Web parece ser urn enorme
~ma de informac;6es baseado em documentos, no qual
documento tern seu pr6prio nome exclusivo sob a
.: a de urn URL. Em termos de conceito, pode ate pare-
__• que ha apenas um unico servidor. Entretanto, a Web e
- ' amente distribufda por urn grande numero de servido-
~-. e cad a urn deles manuseia certa quantidade de docu-
mo da Web. 0 nome do servidor que manuseia urn
umento esta codificado no URL do documento.
- mente grac;as a essa distribuic;ao de documentos e que
: i po sivel aumentar a Web ate seu tamanho atual.
Considerando que problemas de escalabilidade fre-
- memente aparecem sob a forma de degradac;ao do
mpenho, em geral e uma boa ideia replicar componen-
por urn sistema distribuido. A replicac;ao nao somente
3llIIlenta a disponibilidade, mas tambem ajuda a equilibrar a
carga entre componentes, 0 que resulta em melhor desem-
penho. AIem disso, em sistemas de ampla dispersao geogra-
-ca ter uma c6pia por perto pode ocultar grande parte dos
roblemas de latencia de comunicac;ao ja mencionados.
Cache e uma forma especial de replicac;ao, embora
muitas vezes a distinc;ao entre as duas seja diffcil de com-
reender ou ate mesmo artificial. Como no caso da repli-
,ao, a cache resulta em fazer uma c6pia de urn recurso,
em geral na proximidade do aces so do cliente aquele
recurso. Entretanto, ao contrario da replicac;ao, a cache e
uma decisao tomada pelo cliente de um recurso, e nao por
eu proprietario. Alem disso, a cache acontece sob de-
manda, ao passo que a replicac;ao costuma ser planejada
amecipadamente.
Tanto a cache quanta a replicac;ao tern uma seria des-
\'antagem que pode causar efeitos adversos na escalabili-
dade. Como nessa circunstancia temos varias c6pias de
urn recurso, se uma del as for modificada, ficara diferente
das outras. Por conseqiiencia, cache e replicac;ao resultam
em problemas de consistencia.
Ate que ponto as inconsistencias podem ser toleradas
depende em grande palte da utilizac;ao de urn recurso.
:YIuitosusuanos da Web acham aceitavel que seus browsers
retomem urn documento em cache cuja validade nao tenha
ido verificada nos ultirnos minutos passados. Contudo, tam-
bem ha muitos casos em que e preciso cumprir fortes garan-
tias de consistencia, tal como no caso de bolsas de valores e
leil6es eletr6nicos. 0 problema com a forte consistencia e
que uma atualizac;ao deve ser imediatamente propagada para
todas as outras c6pias. Alem do mais, se duas atualizac;6es
ocorrerem ao mesmo tempo, freqiientemente tambem e exi-
gida a atualizac;ao de cada c6pia na mesma ordem.
Situac;6es como essa em geral requerem algum meca-
nismo de sincronizac;ao global. Infelizmente, e extrema-
mente diffcil ou ate impossivel implementar esses meca-
nismos de modo escalavel porque as leis da fisica insistem
em que os f6tons e os sinais eletricos obedec;am a um limi-
te de velocidade de 3 X 108 m/s (a velocidade da luz). Por
conseqiiencia, ampliar urn sistema por replicac;ao pode
introduzir outras soluc;6es inerentemente nao escalaveis.
Voltaremos a replicac;ao e a consistencia no Capitulo 7.
Ao considerarmos essas tecnicas de ampliac;ao de
escala de urn sistema, poderiamos argumentar que a esca-
labilidade de tamanho e a menos problematica do ponto
de vista tecnico. Em muitos casos, 0 simples aumento da
capacidade de uma maquina resolvera a questao, ao
menos temporariamente, e talvez a custos significativos.
A escalabilidade geografica e um problema muito mais
diffcil, porque e a Mae Natureza que esta atrapalhando.
~inda assim, a pratica mostra que combinar tecnicas de
distribuic;ao, replicac;ao e cache com diferentes formas de
consistencia costuma ser suficiente em muitos casos.
Por fim, escalabilidade administrativa parece ser a
mais diffcil, em parte porque tambem precisamos resolver
problemas que nao sao tecnicos (como polfticas de organi-
zac;6es e colaborac;ao humana). Nao obstante, houve pro-
gresso nessa area simplesmente ignorando dominios
administrativos. A introduc;ao, e agora a utilizac;ao, disse-
minada de tecnologia peer-to-peer demonstra 0 que pode
ser conseguido se os usuanos finais sirnplesmente toma-
rem 0 controle (Aberer e Hauswirth, 2005; Lua et aI.,
2005; Oram, 2001). Contudo, vamos deixar claro que, na
melhor das hip6teses, a tecnologia peer-to-peer pode ser
apenas uma soluc;ao parcial para a escalabilidade adminis-
trativa. Mas, em algum momento, teremos de tratar dela.
Agora ja deve estar claro que desenvolver sistemas
distribuidos pode ser uma tarefa dificflima. Como vere-
mos muitas vezes em todo este livro, ha tantas quest6es a
considerar ao mesmo tempo que parece poder ser apenas
a complexidade 0 unico resultado. Mesmo assim, seguin-
do alguns princfpios de projeto, podem-se desenvolver
sistemas distribuidos que cumpram a risca as metas que
estabelecemos neste capitulo. Muitos princfpios seguem
as regras basicas da engenharia decente de software e nao
serao repetidos aqui.
Contudo, sistemas distribuidos sao diferentes do
software tradicional porque os componentes estao disper-
sos por uma rede. Nao levaf" essa dispersao em conta
durante 0 projeto e 0 que toma tantos sistemas desneces-
sariamente complexos e resulta em erros que precisam ser
consertados mais tarde. Peter Deutsch, que, na epoca, tra-
balhava na Sun Microsystems, formulou esses erros como
as seguintes premissas falsas que todos ado tam ao desen-
volver uma aplica~ao distribufda pela primeira vez:
1. A rede e confiavel.
2. A rede e segura.
3. A rede e homogenea.
4. A topologia nao muda.
5. A latencia e zero.
6. A largura de banda e infinita.
7. 0 custo de transporte e zero.
B. Ha so urn administrador.
Observe como essas premissas se referem a proprie-
dades exclusivas de sistemas distribufdos: confiabilidade,
seguran~a, heterogeneidade e topologia da rede; latencia
e largura de banda; custos de transporte e,por fim, domf-
nios administrativos. No desenvolvimento de aplica~6es
nao distribufdas, e provavel que a maioria dessas quest6esnem apare~a.
A maior parte dos princfpios que discutimos neste
livro esta imediatamente relacionada a essas premissas.
Em todos os casos, discutiremos solu~6es para problemas
causados pelo fato de uma ou mais premissas serem fal-
sas. Por exemplo, redes confiaveis simples mente nao
.existem, 0 que leva a impossibilidade de conseguir trans-
parencia a falha. Dedicaremos urn capftulo inteiro para
tratar do fato de que a comunica~ao por rede e inerente-
mente insegura. Ja discutimos que sistemas distribufdos
precisam levar em conta a heterogeneidade. Na mesma
toada, quando discutimos replica~ao para resolver proble-
mas de escalabilidade, estamos, em essencia, atacando
problemas de latencia e largura de banda. Tambem abor-
daremos quest6es de gerenciamento em varios pontos
desta obra, tratando das falsas premissas do transporte a
custo zero e de urn unico domfnio administrativo.
1.3 Tipos de Sistemas OistribuTdos
Antes de come~armos a discutir os princfpios de sis-
temas distribufdos, vamos examinar com maior aten~ao
os varios tipos de sistemas distribufdos. A seguir faremos
a distin~ao entre sistemas de computa~ao distribufdos,
sistemas de informa~ao distribufdos e sistemas embuti-
dos distribufdos.
1.3.1 Sistemas de computacao distribuTdos
Uma classe importante de sistemas distribufdos e a
utilizada para tarefas de computa~ao de alto desempenho.
Em termos estritos, podemos fazer uma distin~ao entre
dois subgrupos. Na computal;ao de cluster, 0 hardware
subjacente consiste em urn conjunto de esta~6es de traba-
lho ou PCs semelhantes, conectados por meio de uma
rede local de aHa velocidade. Alem disso, cada no execu-
ta 0 mesmo sistema operacional.
A situa~ao fica bem diferente no caso da computa-
l;ao em grade. Esse subgrupo consiste em sistemas distri-
bufdos que costumam ser montados como federa~ao de
computadores, na qual cada sistema pode cair sob urn
domfnio administrativo diferente, e pode ser muito dife-
rente no que tange a hardware, software e tecnologia de
rede empregada.
Sistemas de computacao de cluster
Sistemas decomputa~ao de cluster tornaram-se
populares quando a razao pre~o/desempenho de computa-
dores pessoais e esta~oes de trabalho melhorou. A certa
altura ficou atraente, em termos financeiros e tecnicos,
construir urn supercomputador que usasse tecnologia de
prateleira simplesmente conectando uma serie de compu-
tadores relativamente simples a uma rede de aHa velocida-
de. Em quase todos os casos, a computa~ao de cluster e
usada para programa~ao paralela na qual urn unico progra-
ma, intensivo em computa~ao, e executado em paralelo em
varias maquinas.
Urn exemplo bem conhecido de urn computador de
cluster e formado pelos clusters Beowulf baseados em
Linux, cuja configura~ao geral e mostrada na Figura 1.4.
Cada cluster consiste em urn conjunto de nos de compu-
ta~ao controlados e acessados por meio de urn unico no
mestre. As tarefas tfpicas do mestre sao manipular a alo-
ca~ao de nos a urn determinado programa paralelo, man-
ter uma fila de jobs apresentados e proporcionar uma
Aplicac;:ao de
gerenciamento
Componente
da
aplicac;:ao
paralela
Componente
da
aplicac;:ao
paralela
Componente
da
aplicac;:ao .
paralela
Rede de
acesso remoto
- - -e para as usuarios do sistema. Assim, na verdade,
executa a middleware necessaria para a execu-
rogramas e a gerenciamento do cluster, ao passo
os nos de computa~3oo, muitas vezes basta um
operacional padr300e nada mais.
L IDa parte importante desse middleware e formada
- - bibliotecas para execu~3oode programas paralelos.
discutiremos no Capitulo 4, na realidade, muitas des-
liotecas fomecem somente facilidades avan~adas de
-calf3.opor mensagem, mas n300SaGcapazes de mani-
seguran~a, processos com falhas e assim par diante.
Como altemativa para essa organiza~3oo hierarquica,
ma Mosix adota uma abordagem simetrica (Amar
__ 004). Esse sistema tenta prover uma imagem de
~:teInaUnico de urn cluster, a que significa que, para um
0, urn computadar de cluster oferece a transparen-
~ di tribui~3oodefinitiva porque parece ser um tinico
~mador. Como ja mencionamos, e impossivel propar-
£a1 irnagem sob todas as circunstancias. No caso do
_~ six .. 0 alto grau de transparencia e conseguido com a
p=:CIl15- ;S3oOde uma forma din arnica e preventiva de migra-
"- de processos entre os nos que comp6em 0 cluster.
A migray300de processos permite que urn usumo ini-
~ rrma aplica~ao em qualquer no (denominado no nativo),
~ -- 0 que ele pode se mover transparentemente para outros
- a fun de, par exemplo, fazer usa eficiente de recursos.
mas a migra~ao de processos no Capitulo 3.
as de computa~ao em grade
Urn aspecto caracterfstico da computa~ao de cluster
_ _ bomogeneidade. Na maioria dos casos, os computa-
- '- que comp6em urn cluster s3oo,em grande parte, as
-esmos, todos tern a mesmo sistema operacional e todos
_ -0 onectados a mesma rede. Par compara~3oo, sistemas
~ omputac:;ao em grade tern alto grau de heterogeneida-
c:~: nenhuma premissa e adotada em rela~ao a hardware,
-.-=-Dmasoperacionais, redes, dominios administrativos,
- liricas de seguran~a e assim par diante.
Uma questao fundamental em urn sistema de compu-
~~o em grade e que recursos de diferentes organiza~6es
-" reunidos para permitir a colabara~3oo de urn grupo de
?S oas au institui~6es. Tal colabora~3oo e realizada sob a
:orma de uma organiza~ao virtual. As pessoas que per-
ten cern a mesma organiza~3oovirtual tern direitos de aces-
so aos recurs as fomecidos par aquela organiza~ao. Entre
os recursos tipicos estao servidares de computa~ao (entre
eles supercomputadores, possivelmente implementados
como computadores de cluster), facilidades de armazena-
menta e bancos de dados. Alem disso, tambem podem ser
oferecidos equipamentos especiais em rede, como teles-
capias, sensores e outros.
Dada a sua natureza, grande parte do software para
realizar computa~3oo em grade e desenvolvida com a fina-
lidade de prover aces so a recursos de diferentes dominios
administrativos, e somente para usuarios e aplica~5es que
perten~am a uma organiza~3oo virtual especffica. Par essa
raz3oo,a foco costuma ser dirigido as quest5es de arquite-
tura. Uma arquitetura proposta par Foster et al. (2001) e
mostrada na Figura 1.5.
A arquitetura consiste em quatro camadas. A mais
baixa, denominada camada-base, prove interfaces para
recursos locais em urn site especffico. Observe que essas
interfaces S300projetadas para permitir compartilhamento
de recurs as dentro de uma arganiza~ao virtual. A tarefa
tipica dessas interfaces e prover fun~5es para consultar 0
estado e as capacidades de urn recurso, em conjunto com
fun~5es para 0 gerenciamento de recursos propriamente
dito. Par exemplo: travar recursos.
A camada de conectividade consiste em protocolos de
comunica~3oopara suportar transa~5es da grade que abran-
jam a utiliza~3oode mtiltiplos recursos. Par exemplo, S300
necessmos protocolos para transferir dados entre recursos,
au para a simples acesso de urn recurso desde uma locali-
za~3ooremota. Alem disso, a camada de conectividade con-
tera protocolos de seguran~a para autenticar usumos e
recursos. Observe que, em muitos casas, usumos humanos
n300sao autenticados; em vez disso, S300autenticados pro-
gramas que agem em nome dos usumos. Nesse sentido,
delegar direitos de urn usumo a programas e uma fun~3oo
importante que precisa ser suportada na camada de conec-
tividade. Daremos mais detalhes sabre a delega~3ooquando
discutirmos seguran~a em sistemas distribuidos.
A camada de recursos e responsavel pelo gerenciamen-
to de urn tinico recurso. Ela utiliza as fun~5es fomecidas pela
camada de conectividade e chama diretamente as interfaces
disponibilizadas pela camada-base. Par exemplo, essa cama-
Aplicac;:6es-J-
da ofereceni funr;oes para obter informar;oes de configurar;ao
sobre urn recursoespecffico ou, em geral, para realizar ope-
rar;oes especfficas como criar urn processo ou ler dados.
Portanto, a camada de recurs os e considerada responsavel
pelo controle de acesso e, por isso, dependera da autentica-
r;ao realizada como parte da camada de conectividade.
A camada seguinte na hierarquia e a camada coleti-
va. Ela trata de manipular 0 acesso a multiplos recursos e
normalmente consiste em servir;os para descoberta de
recursos, alocar;ao e escalonamento de tarefas para multi-
pIos recursos, replicar;ao de dados e assim por diante.
Diferentemente das camadas de conectividade e de recur-
sos, que consistem em urn conjunto padronizado e relati-
vamente pequeno de protocol os, a camada coletiva pode
consistir em muitos protocolos diferentes para muitas
finalidades diferentes, que reflitam 0 amplo' espectro de
servir;os que ela pode oferecer a uma organizar;ao virtual.
Por fim, a camada de aplica~iio consiste em aplica-
r;oes que funcionam dentro de uma organizar;ao virtual e
que fazem uso do ambiente de computar;ao em grade.
Normalmente, as camadas coletiva, de conectividade
e de recursos formam 0 cerne daquiloque poderia ser
denorninado camada de middleware em grade. Em conjun-
to, essas camadas dao aces so e gerenciam recursos que
estao potencialmente dispersos por vanos sites. Vma
observar;ao importante da perspectiva do rniddleware e
que, com a computar;ao em grade, a nor;ao de urn site (ou
unidade administrativa) e comum. Essa prevalencia e enfa-
tizada pela tendencia gradual a migrar;ao para uma arqui-
tetura orientada a servi"os na qual sites oferer;am aces-
so as vacias camadas por meio de urn conjunto de servir;os
Web (Joseph et aI., 2004).
A essa altura, isso nos levou a definir;ao de uma arqui-
tetura alternativa conhecida como arquitetura de servi"os
de grade aberta (Open Grid Services Architecture -
OGSA). Essa arquitetura consiste em varias camadas e
muitos componentes, 0 que a torna bastante complexa. A
complexidade parece ser 0 destino de qualquerprocesso de
padronizar;ao. Detalhes sobre a OGSA podem ser encon-
trados em Foster et al. (2005).
1.3.2 Sistem~sde inform~c~odistribuldos
Vma outra classe importante de sistemas distribui-
dos e encontrada em organizar;oes que se defrontaram
com uma profusao de aplicar;oes em rede para as quais a
interoperabilidade se mostrou uma experiencia dolorosa.
Muitas das solur;oes de rniddleware existentessao resul-
tado do trabalho com uma infra-estrutura na qual era mais
facil integrar aplicar;oes a urn sistema de informar;oes de
ambito empresarial (Bernstein, 1996; Alonso et aI., 2004).
Podemos distinguir vanos niveis nos quais ocorreu a
integrar;ao. Em muitos casos, uma aplicar;ao em rede con-
sistia simples mente em urn servidor que executava aquela
aplicar;ao, freqtientemente incluindo urn banco de dados, e
a disponibilizava para programas remotos, denorninados
clientes. Esses clientes podiam enviar uma requisir;ao ao
servidor para executar uma operar;ao especffica e depois
receber uma resposta que era devolvida. Integrar;ao no
nivel mais baixo perrnitiria que clientes empacotassem
vanas requisir;oes, possivelmente para diferentes servido-
res, em uma unica requisir;ao maior, e as enviassem para
execur;ao como uma transa"ao distribuida. A ideia funda-
mental era que todas as - ou nenhuma das - requisir;oes
seriam executadas.
A medida que as aplicar;oes se tornavam mais sofistica-
das e eram gradualmente separadas em componentes inde-
pendentes, notavelmente distinguindo componentes de
banco de dados de componentes de processamento, ficou
claro que a integrar;ao tambem deveria ocorrer de modo que
perrnitisse as aplicar;oes se comunicar diretamente urnas
com as outras. Isso resultou, atualmente, em uma enorme
industria dedicada a integra"ao de aplica"oes empresariais
(Enterprise Application Integration - EAI). A seguir,
abordaremos essas duas formas de sistemas distribuidos.
Para deixar nossa discussao mais clara, vamos nos
concentrar em aplicar;oes de banco de dados. Na pratica,
operar;oes em urn banco de dados costumam ser realizadas
sob a forma de transa"oes. Programar a utilizar;ao de tran-
sar;oes requer prirnitivas especiais que devem ser forneci-
das pelo sistema distribuido subjacente ou pelo sistema de
linguagem em tempo de execur;ao. Exemplos tipicos de
primitivas de transar;ao saG mostrados na Tabela 1.3.
A lista exata de prirnitivas depende dos tipos de obje-
tos que estao sendo usados na transar;ao (Gray e Reuter,
1993). Em urn sistema de correio, poderia haver primitivas
para enviar, receber e repassar correio. Em urn sistema de
contabilidade, elas poderiam ser bastante diferentes.
Entretanto, READ e WRITE saG exemplos tipicos. Decla-
rar;oes ordinarias, chamadas de procedimento e assim par
diante, tambem saG perrnitidas dentro de uma transar;ao.
Em particular, mencionamos que chamadas a procedimen-
tos remotos (Remote Procedure Calls - RPCs), isto e,
chamadas de procedimento em servidores remotos, tam-
bem costumam ser encapsuladas em uma transar;ao, 0 que
resulta no que e conhecido como RPC transacional.
Discutiremos RPCs rninuciosamente no Capitulo 4.
Primitiva Descri~ao
BEGIN_TRANSACTION Marque 0 infcio de uma transa930
END_TRANSACTION Termine a transa930 e tente
compromete-Ia
ABORT_TRANSACTION Elimine a transa930 e restaure
os valores antigos
READ Leia dados de um arquivo, tabela
ou de outra forma
WRITE Escreva dados para um arquivo,
tabela ou de outra forma
BEGIN_TRANSACTION e END_TRANSACTION
- usadas para delimitar 0 escopo de uma transa<;ao. As
<;6esentre elas formam 0 corpo da transa<;ao. 0 aspec-
caracteristico de uma transa<;ao e que todas essas opera-
sao executadas ou nenhuma e executada. Elas podem
:cr procedimentos de biblioteca, chamadas de sistema ou
-l lara<;6esentre parenteses em uma linguagem, dependen-
do cia implementa<;ao.
Essa propriedade tudo-ou-nada das transa<;6es e uma
quatro propriedades caracteristicas que elas tern. Mais
especificamente, transa<;6es sao:
1. Atomicas: para 0 mundo exterior, a transa<;ao acon-
tece como se fosse indivisivel.
2. Consistentes: a transa<;ao nao viola invariantes de
sistema.
3. Isoladas: transa<;6es concorrentes hao interferem
umas com as outras.
4. Duniveis: uma vez comprometida uma transa<;ao,
as altera<;6es sao permanentes.
Essas propriedades costumam ser citadas por suas
letras iniciais: ACID.
A primeira propriedade fundamental exibida par
rodas as transa<;6es e que elas sao atOmicas. Essa proprie-
dade garante que cada transa<;ao aconte<;a completamen-
re, ou nao aconte<;a; e, se acontecer, sera como uma unica
a<;ao indivisivel e instantfmea. Enquanto uma transa<;ao
esta em progresso, outros processos, estejam ou nao en-
volvidos em transa<;6es, nao podem ver nenhum dos esta-
dos intermediarios.
A segunda propriedade afirma que elas sao consis-
tentes. Isso quer dizer que, se 0 sistema tiver certos inva-
riantes que devem valer sempre, se eles forem validos
antes da transa<;ao, tambem 0 serao ap6s a transa<;ao. Par
exemplo, em urn sistema bancario, urn invariante funda-
mental e a lei da conserva<;ao do dinheiro. Ap6s toda
transferencia interna, a quantidade de dinheiro no banco
tern de ser a mesma que era antes da transferencia; contu-
do, por urn breve instante durante a transa<;ao, esse inva-
riante pode ser violado. Todavia, a viola<;ao nao e visivel
fora da transa<;ao.
A terceira propriedade diz que as transa<;6es sao iso-
ladas ou serializaveis. Isso significa que, se duas ou mais
transa<;6es sao executadas ao mesmo tempo, 0 resultado
final para cada uma del as e para outros processos se apre-
sentara como se todas as transa<;6es fossem executadas
em sequencia em certa ordem, dependente do sistema.
A quarta propriedade diz que as transa<;6es sao
duraveis. Refere-se ao fato de que, nao importa 0 que
aconte<;a, uma vez comprometida umatransa<;ao, ela con-
tinua, e os resultados tornam-se permanentes. Nenhuma
falha ap6s 0 comprometimento pode desfazer os resulta-
dos ou provocar sua perda.
A durabilidade sera discutida minuciosamente no
Capitulo 8.
Ate aqui, transa<;6es foram definidas em urn unico
banco de dados. Uma tranSal;aO aninhada e construida
com base em uma quantidade de subtransa<;6es, como
mostra a Figura 1.6. A transa<;ao do nivel mais alto pode
se ramificar e gerar 'filhos' que executam em paralelo uns
aos outros em maquinas diferentes para obter ganho de
desempenho ou simplificar a programa<;ao. Cada urn des-
ses filhos tambem pode executar uma ou mais subtransa-
<;6esou se ramificar e gerar seus pr6prios filhos.
Subtransa9aO I Subtransa9ao I
U U·
Bancos de d~dos da\ ( Bancos de dados do hotel
companhla aerea . \
Dois bancos de dados diferentes (independentes)
SUbtransa<;6esdao origem a urn problema sutil, porem
importante. Imagine que uma transa<;ao inicia varias sub-
transa<;6es em paralelo e uma delas se compromete, tornan-
do seus resultados visiveis a transa<;ao-pai. Ap6s mais com-
puta<;ao, a transa<;ao-pai e abortada, restaurando todo 0 sis-
tema ao estado em que estava antes que a transa<;ao do
nivel mais alto come<;asse. Por consequencia, os resultados
da subtransa<;ao que se comprometeu devem ser anulados.
Portanto, a permanencia que citamos anteriormente se apli-
ca somente as transa<;6es do nivel mais alto.
Visto que transa<;6es podem ser aninhadas ate uma
profundidade arbitraria, e preciso consideravel adminis-
tra<;aopara conseguir que tudo esteja correto. No entanto,
a semantica e clara. Quando qualquer transa<;ao ou sub-
transa<;ao come<;a, ela recebe, em termos conceituais, uma
c6pia privada de todos os dados presentes no sistema
inteiro, a qual pode manipular como desejar. Se ela abor-
tar, seu universo privado desaparece como se nunca tives-
se existido. Se ela se comprometer, seu universo privado
substitui 0 universo do pai. Assim, se uma subtransa<;ao
estiver comprometida e mais tarde for iniciada uma nova
sUbtransa<;ao, a segunda ve os resultados produzidos pela
primeira. Da mesma farma, se uma transa<;ao do nivel
mais alto abortar, todas as suas subtransa<;6es subjacentes
tambem tern de ser abortadas.
Transa<;6es aninhadas sao importantes em sistemas
distribuidos porque proporcionam urn modo natural de
distribuir uma transa<;ao por varias maquinas. Elas
seguem uma divisao 16gica do trabalho da transa<;ao ori-
ginal. Par exemplo, uma trans.a<;ao para 0 planejamento
de uma viagem pela qual e preciso reservar tres voos pode
ser subdividida logicamente em ate tres subtransa<;6es.
Cada uma dessas subtransa<;6es pode ser gerenciada em
separado e independentemente das outras duas.
Quando os sistemas de middleware empresarial co-
me9aram, 0 componente que manipulava transa90es dis-
tribuidas, ou aninhadas, formava 0 nueleo para a integra-
9ao de aplica90es no nivel do servidor ou do banco de
dados. Esse componente era denominado monitor de
processamento de transa~ao, ou, de forma abreviada,
monitor TP. Sua principal tarefa era permitir que uma
aplica9ao acessasse varios servidoresfbancos de dados
oferecendo a ela urn modelo de programa9ao transacio-
nal, como mostra a Figura 1.7.
Como ja mencionamos, quanta mais as aplica90es se
desvinculavam dos bancos de dados sobre os quais eram
construidas, mais evidente ficava que eram necessarias
facilidades para integrar aplica90es indepenqentemente
de seus bancos de dados. Em particular, componentes de
aplica9ao deveriam poder se comunicar diretamente uns
com os outros, e nao apenas par meio do comportamento
de requisi9ao/resposta que era suportado por sistemas de
processamento de transa90es.
Essa necessidade de comunica9ao entre aplica90es
resultou em muitos modelos diferentes de comunica9ao
que seriio discutidos minuciosamente neste livro - por
essa razao, por enquanto faremos aqui apenas uma breve
descri9ao. A principal ideia era que aplica90es existentes
pudessem trocar informa90es diretamente, como mostra
a Figura 1.8.
Aplicagao
c1iente
Existem varios tipos de middleware de comunica-
9ao. Com chamadas de procedimento remoto (Remote
Procedure Calls - RPC), urn componente de aplica9ao
pode efetivamente enviar uma requisi9ao a urn outro com-
ponente de aplica9ao executando uma chamada de proce-
dimento local, que resulta no empacotamento da requisi-
9ao como uma mensagem e em seu envio ao chamador.
Da mesma forma, 0 resultado sera enviado de volta e
devol vido a aplica9ao como 0 resultado da chamada de
procedimento.
A medida que a popularidade da tecnologia de obje-
to aumentava, foram desenvolvidas tecnicas que permitis-
sem chamadas a objetos remotos, 0 que resultou naquilo
que denominamos invoca~oes de metodo remoto
(Remote Method Invocations - RMI). Vma RMI e, em
essencia, 0 mesmo que uma RPC, exceto que fun cion a
com objetos em vez de com aplica90es.
A desvantagem da RPC e da RMI e que ambos, 0
chamador e 0 chamado, precisam estar ligados e em fun-
cionamento no momenta da comunica9ao. Alem disso,
eles precis am saber exatamente como se referir urn ao
outro. Esse forte acoplamento muitas vezes e percebido
como uma seria desvantagem e resultou no que conhece-
mos como middleware orientado a mensagem ou, sim-
plesmente, MOM (Message-oriented Middleware).
Nesse caso, as aplica90es apenas enviam mensagens a
pontos 16gicos de contato, que frequentemente sao descri-
tos por meio de urn sujeito. Da mesma forma, as aplica-
Aplicagao
c1iente
Aplicagao
cliente
Aplicagao
dolado
servidor
Aplicagao
dolado
servidor
Aplicagao
dolado
servidor
_- . podem indicar seu interesse por urn tipo especifico
nsagem, apos 0 que 0 middleware de comunica<;ao
, para que todas as mensagens sejam entregues a
- - aplicac;:6es. Esses sistemas, denominados publi-
subscrever, formam uma classe impOltante e em
ao de sistemas distribuidos. Nos os discutiremos
iosamente no Capitulo 13.
Sistemas distribuTdos pervasivos
o sistemas distribuidos que discutimos ate aqui sao,
grande parte, caracterizados por sua estabilidade: os
- _·-0 fixos e tern uma conexao mais ou menos perma-
~ e de aHa qualidade com uma rede. Ate certo ponto,
-- e tabilidade tern sido conseguida por meio de varias
- • <lS que sao discutidas neste livro e que visam a obter
-parencia de distribuic;:ao. Urn exemplo: a profusao de
• <lS para mascarar falhas e recuperac;:ao dani a
i::;;;;tm~ss;aode que as coisas podem dar errado apenas rara-
e. Da mesma maneira, conseguimos ocultar aspectos
_ cionados com a real localizac;:ao de urn no na rede, 0
__-z perrnite, efetivamente, que usuarios e aplicac;:6es acre-
- ~m que os nos continuam onde estao.
Contudo, a questao ficou muito diferente com a intro-
- .·0 de dispositivos de computac;:ao moveis e embutidos.
-~ente encontramos sistemas distribuidos nos quais a
-0 ilidade e 0 comportamento esperado. Nesses siste-
- que denominamos sistemas distribuidos pervasi-
o equipamentos costumam ser caracterizados por seu
- • enD tamanho, pela alimentac;:ao par bateria, por sua
ilidade e por terem somente uma conexao sem fio, se
que nem todas essas caracteristicas se aplicam a todos
. . positivos. Alem do mais, tais caracterfsticas nao pre-
er necessariamente interpretadas como restritivas,
o e ilustrado pelas possibilidades dos modernos smart
ne (Roussos et aI., 2005).
Como seu nome sugere, urn sistema distribuido per-
~-n·o e parte de nosso entorno; por isso, e, em geral, ine-
~ mente distribuido. Urn aspecto importante e a ausen-
_ . geral de controle administrativo humano. Na melhor
~ bipoteses, os dispositivos podem ser configurados por
proprietarios; porem, quanta ao mais, eles precis am
.: - obrir automaticamente seu ambiente e 'se encaixar' 0
-=lhor que puderem. Grimm et al. (2004) tornaram esse
=- aixar' mais exato pela formulac;:ao dos tres