Вы находитесь на странице: 1из 25

SISTEMAS DISTRIBUiDOS

~yt~c~~iO$

~CtrCt~igVVt,Ct$

2 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 Definiao de urn sistema distribuido
1.2 Metas
1.3 Tipos de sistemas distribufdos
1.4 Resumo

1
2
10
18

2.1
2.2
2.3
2.4

Estilos arquitet6nicos
Arquiteturas de sistemas.................................................................................................................................................................
Arquiteturas versus middleware
Autogerenciamento em sistemas distribufdos.:

20
22
32
35

3.1
3.2
3.3
3.4
3.5
3.6

Threads
Virtual izaao
Clientes
Servidores
Migraao de c6digo
Resumo

42
48
50
53
62
67

4.1
4.2
4.3
4.4
4.6

Fundamentos
Chamada de procedimento remoto
Comunicaao orientada a mensagem
Comunicaao orientada a fluxo
Resumo

69
75
84
95
105

5.1
5.2
5.3
5.4
5.5

Nomes, identificadores e endereos


Nomeaao simples
Nomeaao estruturada
Nomeaao baseada em atributo
Resumo

108
110
118
131
137

6.1
6.2
6.3
6.4
6.5
6.6

Sincronizaao de rel6gios
Re16gios 16gicos.......................................................................................................................
Exclusao mutua
Posicionamento global de n6s
Algoritmos de eleiao
Resumo

140
147
152
157
159
163

7.1
7.2
7.3
7.4
7.5
7.6

Introduao
Modelos de consistencia centrados em dados
Modelos de consistencia centrados no cliente
Gerenciamento de replicas
Protocolos de consistencia
Resumo

165
167
174
178
185
191

8.1 Introduao 11 tolerancia a falha


8.2 Resiliencia de processo

194
198

8.3
8.4
8.5
8.6
8.7

Comunicar;ao confiavel cliente-servidor


Comunicar;ao confiavel de grupo
Comprometimento distribuido
Recuperar;ao
Resumo

203
207
215
220
226

9.1
9.2
9.3
9.4
9.5

Introdur;ao 11 seguranr;a
Canais seguros
Controle de acesso
Gerenciamento da seguranr;a
Resumo

228
240
250
259
266

10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9

Arquitetura
Processos
Comunicar;ao
N omear;ao
Sincronizar;ao
Consistencia e replicar;ao
Tolerancia a falba
Seguranr;a
Resumo

11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
11.9

Arquitetura
Processos
Comunicar;ao
N omear;ao
Sincronizar;ao
Consistencia e replicar;ao
Tolerancia a falha
Seguranr;a
Resumo

12.1
12.2
12.3
12.4
12.5
12.6
12.7
12.8
12.9

Arquitetura
Process os
Comunicar;ao
Nomear;ao
Sincronizar;ao
Consistencia e replicar;ao
Tolerancia a falha
Seguranr;a
Resumo

13.1 Introdur;ao a modelos de coordenar;ao


13.2 Arquiteturas
13.3 Processos
13.4 Comunicar;ao
13.5 Nomear;ao
13.6 Sincronizar;ao
13.7 Consistencia e replicar;ao
13.8 Tolerancia a falha
13.9 Seguranr;a
13.10 Resumo

14.1 Sugest6es para leitura adicional..


14.2 Bibliografia em ordem a1fabetica

268
272
275
281
284
285
288
291
294

296
302
303
306
310
314
320
322
328

330
335
339
344
345
346
353
354
355

357
358
364
364
365
367
367
371
374
375

377
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<;ao reflete 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 on de 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 assuntos mais 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
o

'0

0 Companion Website desta edi<;ao (www.prenhall.com/tanenbaum_br)ofereceumconjuntocompleto


de apresenta<;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
em contato com um representante Pearson ou enviar urn e-mail parauniversitarios@pearsoned.com.

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 computadores eram grandes e caros. Mesmo os minicomputadores custavam no minimo dezenas de milhares de d6lares 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 independentemente uns dos outros.
Contudo, mais ou menos a partir de meados da decada de 1980, dois avanc;os tecnol6gicos comec;aram a mudar
es a situac;ao. 0 primeiro foi 0 desenvolvimento de microprocessadores 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 setore . 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/desempenho de 1013. Se os carros tivessem melhorado nessa proporc;ao no mesmo periodo de tempo, urn Rolls Royce custaria 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 conectadas de modo tal que pequenas quantidades de informac;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), permitem que milh6es de maquinas no mundo inteiro se
conectem a velocidades que variam de 64 Kbits/s a gigabits 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 computadores conectados por uma rede de alta velocidade.
Esses sistemas costumam ser denominados redes de computadores ou sistemas distribuidos, em comparac;ao com
os sistemas centralizados (ou sistemas monoprocessadores) anteriores, que consistem em urn unico computador, 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 acordo com nenhuma das outras. Para nossa finalidade, e suficiente dar uma caracterizac;ao sem ser muito especifica:

Um sistema distribufdo
um conjunto de computadores 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 componentes ,;to e, computadores) autonomos. Urn segundo
aspecto e que os usuarios, sejam pessoas ou programas,
acham que estao tratando com urn unico sistema. Isso significa 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 desempenho 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 importantes de sistemas distribuidos. Uma caracterfstica importante 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 uniforme, independentemente de onde a interac;ao ocorra.
Em principio, tambem deveria ser relativamente
facil expandir ou aumentar a escala de sistemas distribufdos. 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 usuarios e aplicac;6es, e uma camada subjacente, que consiste
em sistemas operacionais e facilidades basicas de comunicac;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 tambem 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 opera 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 computador 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 distribUldo para que valha a pen a 0 esforc;o. Urn sistema distribuldo 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 facilitar aos usuanos, e as aplica<;:6es, 0 acesso a recursos
remotos e seu compartilhamenro de maneira controlada e
eficiente. Os recursos podem ser muito abrangentes, mas
entre os exemplos tfpicos estao impressoras."computadores, 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 impressora direcionada a cada usuano. Do mesmo modo, em termos econornicos, faz sentido compartilhar recursos de
alto custo como supercomputadores, sistemas de armazenamento de alto desempenbo, images etters e outros perifericos caros.
Conectar usuarios e recursos tambem facilita a colaborac;ao e a troca de informac;6es, 0 que e claramente ilustrado pelo sucesso da Internet com seus protocolos simples 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 colaborativa, teleconferencia e assim por diante. Da mesma
maneira, a conecti idade da Internet possibilitou 0 comercio eletronico, que nos perrnite comprar 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 compartilhamento 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 comunicac;ao. Senhas e outras informac;6es sensfveis muitas
vezes sao enviadas como texto comum - isto e, nao criptografado - 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 soIicitada uma prova de que 0 cliente seja 0 proprietario do
cartao. No futuro, fazer pedidos desse modo s6 sera posslvel 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 rastreamento 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 usando filtros especiais de informa~6es que selecionam menagens 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 fisiamente distribufdos por varios computadores. Urn sistema 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, abordaremos 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.
Descri~ao

Transparencia
cesso

Oculla diferengas na represenlagao


no modo de acesso a um recurso

de dados e

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

e replicado

Replicagao

Oculla que um recurso

Concorrencia

Oculla que um recurso pode ser comparlilhado


por diversos usuarios concorrenles

Falha

Oculla a falha e a recuperagao

Tabela 1.1

de um recurso

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 maquinas, 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 sistema distribuido pode ter sistemas de computac;ao que executam 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 recursos, 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 servidor Web da Prentice Hall. 0 URL tambem nao da nenhuma 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 acessados 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 usuario 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 usa10 quando vaG de urn lugar a outro sem sequer se desconectar temporariamente.
Como veremos, a replicac;ao desempenha urn papel
muito importante em sistemas distribuidos. Por exemplo,
recursos podem ser replicados para aumentar a disponibilidade 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 mesmo nome. Por conseqiiencia, urn sistema que suporta transparencia 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 sistemas distribufdos e perrnitir compartilhamento de recursos. Em muitos casos, esse compartilhamento e cooperativo, 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 independentes, 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 fenomeno 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 travas de acesso, 0 que da a cada usuario, urn por vez, acesso exclusivo ao recurso desejado. Urn mecanismo mais
refinado e utilizar transa~oes; porem, como veremos em
capftulos posteriores, e bastante diffcil implementar transa~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 descri~ao pontua uma outra questao importante no projeto de
sistemas distribufdos: como tratar falhas. Fazer com que
urn sistema distribufdo seja transparente a falha significa 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 sistemas distribufdos e ate mesmo impossfveis de se realizar
quando sao adotadas certas prernissas aparentemente realistas, como discutiremos no Capftulo 8. A principal dificuldade para mascarar falhas esta na incapacidade de distinguir entre urn recurso morto e urn recurso insuportavelmente lento. Por exemplo, quando contatamos urn servidor
Web ocupado, a certa altura 0 tempo do browser se esgotara 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 geralmente considerada preferfvel para qualquer sistema distribufdo, 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 eletronico 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 sistema distribufdo de longa distancia que conecta urn processo 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 computadores, isso levara varias centenas de rnilissegundos. A transrnissao 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 exemplo, muitas aplica~oes de Internet tentam contatar urn servidor 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 medida que sistemas distribufdos estao se expandindo para dispositivos que as pessoas carregam consigo, e a pr6pria
no~ao de localiza~ao e percep~ao de contexto esta se tornando 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 impressora ocupada que esta pr6xima do que a uma desocupada
localizada na sede corporativa em urn pafs diferente.
Tambem ha outros argumentos contra a transparencia 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 podemos alcan~a-la. Talvez seja muito melhor tornar a distribui<;ao explfcita, 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 comportamento, as vezes inesperado, de urn sistema distribufdo 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 facilidade de compreensao. Nem sempre vale a pen a tentar
conseguir total transparencia, pois 0 pre~o que se paga
por is so pode ser surpreendentemente alto.

Uma outra meta importante de sistemas distribufdos


e a abertura. Urn sistema distribuido aberto e urn sistema que oferece servi~os de acordo com regras padronizadas 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 sempre 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 especificac;6es sao sempre dadas de modo informal por meio de linguagem natural.
Se adequadamente especificada, uma definic;ao de
interface permite que urn processo arbitrario que necessita de certa interface se comunique com urn outro processo 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 exatamente 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 implementac;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.necedores 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 aplicac;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 distribufdo aberto e que deve ser facil configura-Io com base
em co~ponentes diferentes (possivelmente de desenvolvedores 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 extensfvel. Por exemplo, em urn sistema extensfvel, deve ser
relativamente facil adicionar partes que sao executadas
em urn sistema operacional diferente, ou ate mesmo substituir 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 distribufdos 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 devemos 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 sistemas 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, sistemas 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 fornece a polftica ideal para uma aplicac;ao ou usuario especffico. 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 parametros de cache, como 0 perfodo que urn documento pode
permanecer na cache, ou qual documento deve ser retirado 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 mecanismo. No caso de cache na Web, por exemplo, 0 ideal
seria que urn browser proporcionasse facilidades apenas
para armazenar documentos e, ao mesmo tempo, pennitisse 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 parametros 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 procedimentos dessa interface.

A conectividade mundial pela Internet esta rapidamente 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 adicionar 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 escalavel em termos administrativos, 0 que significa que ele
ainda pode ser facil de gerenciar, mesmo que abranja muitas organizac;6es administrativas diferentes. Infelizmente,
urn sistema escalavel em uma ou mais dessas dimens6es
muitas vezes apresenta perda na capacidade de qesempenho a medida que e ampliado.

Quando e necessario arnpliar urn sistema, e precise


resolver problemas de tipos muito diferentes. Em primeiro lugar, vamos considerar a escalabilidade em relac;ao ao tamanho. Se for precise suportar mais usuarios
ou recursos, freqiientemente deparamos com as limitac;6es de servic;os centralizados, dados e algoritmos (ver
Tabela 1.2). Por exemplo, muitos servic;os sac centralizados 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 amento e armazenagem praticamente ilimitadas, a comunicac;ao com aquele servidor acabara por impedir crescimento ulterior.
Infelizmente, as vezes e inevitavel usar apenas urn
unico servidor. Imagine que temos urn servic;o para gerenciar 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

Fazer roteamento com base em


informa90es com pi etas

centralizados

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 caracteres. Vma unica partic;ao de disco de 2,5 gigabytes proporcionaria armazenamento suficiente. Porem, mais uma vez,
nesse caso, ter urn unico banco de dados sem duvida saturaria 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 SystemDNS) ainda estivesse implementado como uma tabela
unica. 0 DNS mantem informac;6es de milh6es de computadores 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 informac;6es de entrada e saida tambem seria ma ideia porque
essas mensagens sobrecarregariam parte da rede. Na verdade, qualquer algoritmo que colha informac;6es de todos
os sites, envie-as a uma unica maquina para processamento e entao distribua os resultados para todos os sites deve
ser, de maneira geral, evitado. Somente algoritmos descentralizados devem ser utilizados. Em geral, esses algoritmos tern as seguintes caracteristicas, que os distinguem
dos algoritmos centralizados:
I. Nenhuma

maquina tern informac;6es completas


sobre 0 estado do sistema.
2. As maquinas tomam 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 importante. 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 sincronizac;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 problemas. Vma das principais raz6es por que hoje e diffcil
ampliar sistemas distribufdos existentes que foram originalmente 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, comumente, 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 distania e inerentemente nao confiavel e quase sempre ponto a
ponto. Por compara<;ao, redes locais em geral proporcionam 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. Somente 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 aconteceria 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 mundial e sejam capazes de atender a bilh6es de usuarios.
Voltaremos a abordar esses servi<;os no Capftulo 5.
A escalabilidade geografica esta forte mente relacionada com problemas de solu<;6es centralizadas que atrapalham a escalabilidade de tamanho. Se tivermos urn sistema com muitos componentes centralizados, e claro que
a escalabilidade geografica estara limitada pelos problemas de desempenho e confiabilidade resultantes da comunica<;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.primeiro 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 recursos, 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 ataques 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 usuarios estranhos. Em segundo lugar, 0 novo dominio tern de
se proteger contra ataques maliciosos do sistema distribufdo. 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 estranho 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 escalabilidade, surge a questao de como resolve-los de maneira geral.
Na maioria dos casos, problemas de escalabilidade em sistemas distribufdos aparecem como problemas de des empenho causados por capacidade limitada de servidores e
rede. Agora, ha basicamente apenas tres tecnicas para
ampliar sistemas: ocultar latencias de comunica<;ao, distribui<;ao e replica<;ao [ver tambem Neuman (1994)].
Ocultar latencias de comunica<;ao e importante para
conseguir escalabilidade geografica. A ideia basica e simples: tentar evitar, 0 quanta possfvel, esperar por respostas 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, is so significa construir
a aplica<;ao requisitante de modo tal que ela use s6 cornunica~ao assincrona. Quando chega uma resposta, a aplica<;aoe interrompida e urn manipulador especial e chamado para concluir a requisi<;ao emitida anteriormente.
A comunica<;ao asslncrona muitas vezes pode serusada
em sistemas de processamento de.lotes e em aplica<;6esparalelas, 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 alternativa, 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 requisi<;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 sintaxe antes de aceitar uma entrada.
Uma solu<;ao muito melhor e despachar para 0 cliente 0 c6digo para preencher 0 formulario e possivelmente
verificar as entradas, alem de fazer com que 0 cliente

Primeiro nome

IMAARTEN

Ultimo nome

IVAN STEEN

ISTEEN@CS.VU.NL

devolva urn formulario completo, como mostra a Figura


1.2(b). Essa abordagem de despacho de c6digo atualmente e amplamente suportada pela Web sob a forma de
applets Java e Javascript.
Uma outra tecnica irnportante de amplia<;ao e a distribui\;ao. A distribui<;ao envolve tomar urn componente, subdividi-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<;o de
nomes do DNS e organizado por hierarquia em uma arvore 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, primeiro ele e passado ao servidor de zona 21 (ver Figura 1.3),

[Q]
Verifique
formulario

IMAARTEN
IVAN STEEN
ISTEEN@CS.VU.NL

I
I
I
[Q]

..

I
'1f
,

Venflque
formulario

Processe
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 servitJaIa Z2 retomara 0 enderec;o do servidor para a zona Z3,
e paz de manipular a ultima parte do nome e retomaenderec;o do hospedeiro associado.
E e exemplo ilustra como 0 servi({o de nomea({iio

ecido pelo DNS

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 documo 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 componenpor 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 desempenho. 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 comreender 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 demanda, 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 escalabilidade. 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, tambem ha muitos casos em que e preciso cumprir fortes garantias 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 exigida a atualizac;ao de cada c6pia na mesma ordem.
Situac;6es como essa em geral requerem algum mecanismo de sincronizac;ao global. Infelizmente, e extremamente diffcil ou ate impossivel implementar esses mecanismos de modo escalavel porque as leis da fisica insistem
em que os f6tons e os sinais eletricos obedec;am a um limite 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 escalabilidade 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 organizac;6es e colaborac;ao humana). Nao obstante, houve progresso nessa area simplesmente ignorando dominios
administrativos. A introduc;ao, e agora a utilizac;ao, disseminada de tecnologia peer-to-peer demonstra 0 que pode
ser conseguido se os usuanos finais sirnplesmente tomarem 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 administrativa. Mas, em algum momento, teremos de tratar dela.

Agora ja deve estar claro que desenvolver sistemas


distribuidos pode ser uma tarefa dificflima. Como veremos 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, seguindo 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 dispersos por uma rede. Nao levaf" essa dispersao em conta
durante 0 projeto e 0 que toma tantos sistemas desnecessariamente complexos e resulta em erros que precisam ser
consertados mais tarde. Peter Deutsch, que, na epoca, trabalhava na Sun Microsystems, formulou esses erros como

as seguintes premissas falsas que todos ado tam ao desenvolver uma aplica~ao distribufda pela primeira vez:
1.
2.
3.
4.
5.

A rede e confiavel.
A rede e segura.
A rede e homogenea.
A topologia nao muda.
A latencia e zero.
6. A largura de banda e infinita.
7. 0 custo de transporte e zero.
B. Ha so urn administrador.

1.3.1 Sistemas de computacao distribuTdos

Observe como essas premissas se referem a propriedades exclusivas de sistemas distribufdos: confiabilidade,
seguran~a, heterogeneidade e topologia da rede; latencia
e largura de banda; custos de transporte e,por fim, domfnios administrativos. No desenvolvimento de aplica~6es
nao distribufdas, e provavel que a maioria dessas quest6es
nem 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 falsas. Por exemplo, redes confiaveis simples mente nao
.existem, 0 que leva a impossibilidade de conseguir transparencia a falha. Dedicaremos urn capftulo inteiro para
tratar do fato de que a comunica~ao por rede e inerentemente insegura. Ja discutimos que sistemas distribufdos
precisam levar em conta a heterogeneidade. N a mesma
toada, quando discutimos replica~ao para resolver problemas de escalabilidade, estamos, em essencia, atacando
problemas de latencia e largura de banda. Tambem abordaremos 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 sistemas distribufdos, vamos examinar com maior aten~ao
os varios tipos de sistemas distribufdos. A seguir faremos

Aplicac;:ao de
gerenciamento

Rede de
acesso remoto

a distin~ao entre sistemas de computa~ao distribufdos,


sistemas de informa~ao distribufdos e sistemas embutidos distribufdos.

Componente
da
aplicac;:ao
paralela

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 trabalho ou PCs semelhantes, conectados por meio de uma
rede local de aHa velocidade. Alem disso, cada no executa 0 mesmo sistema operacional.
A situa~ao fica bem diferente no caso da computal;ao em grade. Esse subgrupo consiste em sistemas distribufdos que costumam ser montados como federa~ao de
computadores, na qual cada sistema pode cair sob urn
domfnio administrativo diferente, e pode ser muito diferente 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 computadores 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 computadores relativamente simples a uma rede de aHa velocidade. Em quase todos os casos, a computa~ao de cluster e
usada para programa~ao paralela na qual urn unico programa, 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 computa~ao controlados e acessados por meio de urn unico no
mestre. As tarefas tfpicas do mestre sao manipular a aloca~ao de nos a urn determinado programa paralelo, manter uma fila de jobs apresentados e proporcionar uma

Componente
da
aplicac;:ao
paralela

Componente
da
aplicac;:ao .
paralela

- - -e para as usuarios do sistema. Assim, na verdade,


executa a middleware necessaria para a execurogramas 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~3oo de programas paralelos.
discutiremos no Capitulo 4, na realidade, muitas desliotecas fomecem somente facilidades avan~adas de
-calf3.opor mensagem, mas n300SaGcapazes de maniseguran~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 propara1 irnagem sob todas as circunstancias. No caso do
_ ~ six .. 0 alto grau de transparencia e conseguido com a
p=:CIl15- ;S3oO
de 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 heterogeneidac:~: nenhuma premissa e adotada em rela~ao a hardware,
-.-=-Dmas operacionais, 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~3oo virtual tern direitos de acesso 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 armazenamenta e bancos de dados. Alem disso, tambem podem ser
oferecidos equipamentos especiais em rede, como telescapias, sensores e outros.
Dada a sua natureza, grande parte do software para
realizar computa~3oo em grade e desenvolvida com a finalidade 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 arquitetura. 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~3oo para suportar transa~5es da grade que abranjam 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 localiza~3ooremota. Alem disso, a camada de conectividade contera protocolos de seguran~a para autenticar usumos e
recursos. Observe que, em muitos casas, usumos humanos
n300sao autenticados; em vez disso, S300autenticados programas 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 conectividade. Daremos mais detalhes sabre a delega~3ooquando
discutirmos seguran~a em sistemas distribuidos.
A camada de recursos e responsavel pelo gerenciamento 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 recurso especffico ou, em geral, para realizar operar;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 autenticar;ao realizada como parte da camada de conectividade.
A camada seguinte na hierarquia e a camada coletiva. 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 multipIos recursos, replicar;ao de dados e assim por diante.
Diferentemente das camadas de conectividade e de recursos, que consistem em urn conjunto padronizado e relativamente 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 aplicar;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 conjunto, 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 enfatizada pela tendencia gradual a migrar;ao para uma arquitetura orientada a servi"os na qual sites oferer;am acesso as vacias camadas por meio de urn conjunto de servir;os
Web (Joseph et aI., 2004).
A essa altura, is so nos levou a definir;ao de uma arquitetura 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 encontrados em Foster et al. (2005).

1.3.2 Sistem~sde inform~c~o distribuldos


Vma outra classe importante de sistemas distribuidos 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 resultado 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 consistia 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 servidores, em uma unica requisir;ao maior, e as enviassem para
execur;ao como uma transa"ao distribuida. A ideia fundamental era que todas as - ou nenhuma das - requisir;oes
seriam executadas.
A medida que as aplicar;oes se tornavam mais sofisticadas e eram gradualmente separadas em componentes independentes, 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 transar;oes requer prirnitivas especiais que devem ser fornecidas 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 objetos 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. Declarar;oes ordinarias, chamadas de procedimento e assim par
diante, tambem saG perrnitidas dentro de uma transar;ao.
Em particular, mencionamos que chamadas a procedimentos remotos (Remote Procedure Calls - RPCs), isto e,
chamadas de procedimento em servidores remotos, tambem 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 aspeccaracteristico de uma transa<;ao e que todas essas operasao executadas ou nenhuma e executada. Elas podem
:cr procedimentos de biblioteca, chamadas de sistema ou
-l
lara<;6esentre parenteses em uma linguagem, dependendo 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 acontece 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 propriedade garante que cada transa<;ao aconte<;a completamenre, 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 envolvidos em transa<;6es, nao podem ver nenhum dos estados intermediarios.
A segunda propriedade afirma que elas sao consistentes. Isso quer dizer que, se 0 sistema tiver certos invariantes 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 fundamental 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; contudo, por urn breve instante durante a transa<;ao, esse invariante pode ser violado. Todavia, a viola<;ao nao e visivel
fora da transa<;ao.
A terceira propriedade diz que as transa<;6es sao isoladas 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 apresentara 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 uma transa<;ao, ela continua, e os resultados tornam-se permanentes. Nenhuma
falha ap6s 0 comprometimento pode desfazer os resultados 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 desses filhos tambem pode executar uma ou mais subtransa<;6es ou se ramificar e gerar seus pr6prios filhos.

Subtransa9aO

Subtransa9ao

U U
Bancos de d~dos da\
companhla aerea
.

Bancos de dados do hotel

Dois bancos de dados diferentes

(independentes)

SUbtransa<;6es dao origem a urn problema sutil, porem


importante. Imagine que uma transa<;ao inicia varias subtransa<;6es em paralelo e uma delas se compromete, tornando seus resultados visiveis a transa<;ao-pai. Ap6s mais computa<;ao, a transa<;ao-pai e abortada, restaurando todo 0 sistema 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 aplica somente as transa<;6es do nivel mais alto.
Visto que transa<;6es podem ser aninhadas ate uma
profundidade arbitraria, e preciso consideravel administra<;ao para conseguir que tudo esteja correto. No entanto,
a semantica e clara. Quando qualquer transa<;ao ou subtransa<;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 abortar, seu universo privado desaparece como se nunca tivesse 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 original. 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 come9aram, 0 componente que manipulava transa90es distribuidas, ou aninhadas, formava 0 nueleo para a integra9ao 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 transacional, 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.

Existem varios tipos de middleware de comunica9ao. Com chamadas de procedimento remoto (Remote
Procedure Calls - RPC), urn componente de aplica9ao
pode efetivamente enviar uma requisi9ao a urn outro componente de aplica9ao executando uma chamada de procedimento local, que resulta no empacotamento da requisi9ao 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 objeto aumentava, foram desenvolvidas tecnicas que permitissem 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 funcionamento 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 conhecemos como middleware orientado a mensagem ou, simplesmente, MOM (Message-oriented
Middleware).
Nesse caso, as aplica90es apenas enviam mensagens a
pontos 16gicos de contato, que frequentemente sao descritos por meio de urn sujeito. Da mesma forma, as aplica-

Aplicagao
c1iente

Aplicagao
c1iente

Aplicagao
dolado
servidor

Aplicagao
cliente

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 publisubscrever, 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;ao
de que as coisas podem dar errado apenas rarae. 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
ilidade e 0 comportamento esperado. Nesses siste- que denominamos sistemas distribuidos pervasio 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 preer 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~-no 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 requisitos
aplicac;:6es pervasivas apresentados a seguir:
-0

1. Adotar mudanc;:as contextuais.


2. Incentivar composic;:ao ad hoc.
3. Reconhecer compartilhamento como padrao.

Adotar mudanc;:as contextuais significa que urn dis- -itivo deve estar continuamente ciente do fato de que
_0::1 ambiente po de mudar 0 tempo todo. Uma das mudan~.- mais simples e descobrir que uma rede nao esta mais
-sponlvel porque urn usuario esta se movimentando
estac;:6es-bases. Nesse caso, a aplicac;:ao deve reagir,

possivelmente conectando-se a uma outra rede, ou tomando outras providencias adequadas.


Incentivar composi<;ao ad hoc refere-se ao fato de que
muitos dispositivos em sistemas pervasivos serao utilizados
de modos muito diferentes por usuarios diferentes. 0 resultado e que a configurac;:ao do conjunto de aplicac;:6es que
executa em urn dispositivo, seja pelo usuario, seja por interposic;:aoautomatizada, porem control ada, tern de ser facil.
Urn aspecto muito importante de sistemas pervasivos
e que, em geral, os dispositivos se juntam ao sistema para
acessar - e possivelmente fornecer - informac;:6es. Isso
requer meios para ler, armazenar, gerenciar e compartiIhar informac;:ao com facilidade. A luz da conectividade
interrnitente e em constante mutac;:ao dos dispositivos, e
muito provavel que 0 espac;:ono qual res idem informac;:6es
acessiveis mudara 0 tempo todo.
Mascolo et al. (2004) bem como Niemela e Latvakoski
(2004) chegaram a conclus6es semelhantes: na presenc;:ade
mobilidade, dispositivos devem suportar a adaptac;:ao facil
e dependente de aplica<;ao a seu ambiente local. Tambem
devem ser capazes de descobl1r servic;:oscom eficiencia e
reagir de acordo. Considerando esses requisitos, a esta altura ja ficou claro que, na realidade, nao existe transparencia
de distribuic;:aoem sistemas pervasivos. De fato, a distribui<;aode dados, process os e controle e inerente a esses sistemas, razao par que talvez seja melhor tao-somente expor a
distribui<;ao, em vez de oculta-Ia. Vamos estudar, agora,
alguns exemplos concretos de sistemas pervasivos.

Urn tipo cada vez mais popular de sistema pervasivo, mas que talvez seja 0 menos restrito, sao sistemas
montados ao redor de redes domesticas. Em geral, esses
sistemas sao compostos de urn ou mais computadores
pessoais. Porem, 0 mais importante e que integram eletronicos de consumo tipicos como aparelhos de TV, equipamentos de audio e video, dispositivos parajogos, smart
phones, PDAs e outros equipamentos de uso pessoal em
urn tinico sistema. Alem disso, podemos esperar que
todos os tipos de dispositivos, como eletrodomesticos de
cozinha, camaras de vigiHincia, relogios, controladores
de iluminac;:ao e assim por diante, serao conectados a urn
tinico sistema distribuido.
Da perspectiva de sistema, ha varios desafios que precisam ser enfrentados antes que os sistemas pervasivos
domesticos se tornem realidade. Urn desafio importante e
que tal sistema deve ser completamente autoconfiguravel
e autogerenciavel. Nao se pode esperar que usuarios finais
estejam dispostos ou sejam capazes de manter urn sistema
distribuido domestico ligado e em funcionamento se seus
componentes forem propensos a erros, como acontece
com muitos dos dispositivos existentes hoje.
Muito ja foi conseguido por meio dos padr6es
Universal Plug and Play (UPnP), pelos quais dispositivos
obtem automaticamente enderec;:osIF, pod em descobrir uns

os dispositivos pessoais fIcarao repletos de inforrnac,;6es


dimas necessmas, mas sua capacidade de armazenamento nunca se esgotara.
Contudo, ter armazenamento sufIciente nao resolve
o problema do gerenciamento de espac,;os pessoais. Ser
capaz de armazenar enormes quantidades de dados muda
o problema para 0 armazenamento de dados relevantes e
para a capacidade de acha-Ios mais tarde. Cada vez mais
veremos sistemas pervasivos, como redes domesticas,
equipados com 0 que denorninamos recomendadores,
programas que consultam 0 que os outros usuarios armazenaram, de modo a identifIcar gostos semelhantes e, na
sequencia, deduzir qual conteudo colocar no espac,;opessoal de alguem. Vma observac,;ao interessante e que a
quantidade de informac,;6es de que os programas recomendadores necessitam para fazer seu trabalho costuma
ser pequena 0 sufIciente para permitir que sejam executados em PDAs (Miller et aI., 2004).

aos outros e assim por diante (UPnP Forum, 2003). Contudo, e precise mais. Por exemplo, nao esta claro como 0
software e 0 fIrmware presentes em dispositivos podem ser
atualizados com facilidade sem intervenc,;ao manual, ou
quando ocorrem as atualizac,;6es, de modo que a compatibilidade com outros dispositivos nao seja violada.
Vma outra questao premente e 0 gerenciamento daquilo que e conhecido como urn espafo pessoal. Reconhecendo que urn sistema domestico consiste em muitos
dispositivos compartilhados, bem como pessoais, e que os
dados em urn sistema domestico tambem estao sujeitos a
restric,;6es de compartilhamento, muita atenc,;aoe dedicada
a percepc,;ao desses espac,;os pessoais. Por exemplo, parte
do espac,;opessoal de Alice pode consistir em sua agenda,
fotos da familia, urn diario, musicas e videos que ela comprou etc. Esses ativos pessoais devem ser armazenados de
maneira que Alice tenha acesso a eles sempre que desejar.
Alem disso, partes desse espac,;o pessoal devem estar temporariamente - acessiveis a outros, como no caso de
ela precisar participar de uma reuniao de neg6cios.
Felizmente, as coisas podem fIcar mais simples. Ha
muito tempo considera-se que espac,;ospessoais relacionados com sistcmas domestic os sac inerentemente distribuidos por varios dispositivos. E 6bvio que tal dispersao
podera resultar facilmente em problemas de sincronizac,;ao. Todavia, esses problemas podem ser amenizados
devido ao rapido crescimento da capacidade de discos
rigidos, aliado a reduc,;aode seu tamanho. ConfIgurar uma
unidade de armazenamento de varios terabytes para urn
computador pessoal nao e, realmente, urn problema.
Da mesma maneira, discos rfgidos port::iteis com
capacidade de centenas de gigabytes estao sendo colocados dentro de reprodutores de midia port::iteis relativamente pequenos. Com 0 crescimento continuo dessas capacidades, e possivel que logo vejamos sistemas pervasivos
domestic os adotarem uma arquitetura na qual uma unica
maquina funcionara como mestra (e fIcara escondida em
algum lugar do porao, perto do aquecimentocentral)
e
todos os outros dispositivos fIxos sirnplesmente oferecerao
uma interface conveniente para os seres humanos. Entao,

,,

Sensor de inclira9ao

\
\
I

PDA
\
\

Figura 1.9

I
I
I

,,

/
/

Armazenamento
"

I
\

Sensor do ECG

"

'\\

I
\

de movimento

,,

I
I

Sensores

Vma outra classe de sistemas pervasivos importante e


que esta comec,;ando a fazer sucesso e a relacionada ao tratamento eletronico (pessoal) de saude. Com 0 aumento do
custo do tratamento medico, estao sendo desenvolvidos
novos dispositivos para monitorar 0 bem-estar de individuos e entrar automaticamente em contato com medicos
quando necessario. Em muitos desses sistemas, uma meta
importante e evitar que as pessoas sejam hospitalizadas.
Sistemas para tratamentos de saude costumam ser
equipados com varios sensores organizados em uma rede
de area corporal (Body-area Network - BAN), de preferencia sem fIo. Vma questao importante e que, na pior das
hip6teses, tal rede deve incomodar uma pessoa 0 minimo
possiveI. Com essa fInalidade em vista, a rede deve ser
capaz de funcionar quando a pessoa estiver em movimento, sem que esta precise estar presa por fIos eletricos a dispositivos irn6veis.
Esse requisito resulta em duas organizac,;6es 6bvias,
como mostra a Figura 1.9. Na primeira, urn hub central e
parte da BAN e colhe dados conforrne necessario. Esses

externo

Transmissor

) ~PRS/UM;S

\
I

\
\

,,
,

I
/
/
/

Monitorac;:ao de uma pessoa em um sistema eletronico pervasivo de tratamento


um hub local

OU

[b) uma conexao continua sem fio.

de saude utiJizando (a)

- - 30 descarregados periodicamente em urn disposiarmazenamento de maior capacidade. A vantagem


e quema e que 0 hub tambem pode gerenciar a
~ --...-. :\a segunda, a BAN esta ligada continuamente a
rede externa, mais uma vez por uma coneX30 sem
.:=
_

qual envia dados monitorados.

Sera precise disponi-

tecnicas separadas para gerenciar a BAN. Claro


= rambem poderao existir mais conex6es com urn mediom outras pessoas.
Da perspectiva do sistema distribufdo, deparamos
.aramente com quest6es como:
l Onde e como os dados monitorados

devedo ser
armazenados?
2.. Como podemos evitar a perda de dados cruciais?
Qual e a infra-estrutura necessaria para gerar e
transmitir sinais de alerta?
.. Como os medicos podem dar retorno on-line?
Como po de ser alcan~ada a extrema robustez do
sistema de monitora~ao?
Quais saG as quest6es de seguran~a e como as
polfticas adequadas podem ser impostas?
Diferentemente dos sistemas domesticos, nao podee: perar que a arquitetura de sistemas pervasivos de
ento de saude tenda a passar para sistemas de urn
-~o ervidor e que seus dispositivos de monitora~ao
:::erem com funcionalidade mfnima. Ao contnirio: por
:!Zae de eficiencia, os dispositivos e redes de areas cor~ _. tedo de suportar processamento de dados na
e. 0 que significa que os dados de monitora~ao terao
-= er agregados antes de ser armazenados permanentete ou enviados a urn medico. Diferentemente do caso
2: temas de informa~ao distribufdos, ainda nao ha uma
-=s ta clara para essas quest6es.

_ osso ultimo exemplo de sistemas pervasivos saG as


_~e de sensores. Em muitos casos, essas redes saG parte
...2. t nologia que habilita a pervasividade, e veremos que
.as solu~6es para redes de sensores saG aproveitadas
aplica~6es pervasivas. 0 que torna as redes de senso_- interessantes da perspectiva de sistema distribufdo e
em praticamente todos os casos elas saG usadas para
e:ssar informa~6es. Nesse senti do, elas fazem mais do
apenas fornecer servi~os de comunica~ao, que e 0
-~etivo principal das redes de computadores tradicionais.
Akyildiz et aI. (2002) dao uma visao geral de acordo
rom a perspectiva de rede. Zhao e Guibas (2004) dao uma
0...
odu~ao as redes de sensores orientadas a sistemas.
:="'treitamente relacionadas com as redes de sensores saG
- redes em malha, que, em essencia, formam urn con~:m[Q de nos (fixos) que se comunicam
por meio de liga;Oe: sem fio. Essas redes podem formar a base para muia> istemas distribufdos de medio porte. Akyildiz et aI.
_DOS) dao uma visao geral dessas redes.

Normalmente, uma rede de sensores consiste em


dezenas a centenas de milhares de nos relativamente
pequenos, cada urn equipado com urn dispositivo de sensoriamento. A maioria das redes de sensores usa comunica~ao sem fio, e os nos com frequencia saG alimentados
por bateria. Seus recursos limitados, sua capacidade restrita de comunica~ao e demand a reprimida de consumo de
energia exigem que a eficiencia ocupe urn dos primeiros
lugares da lista de criterios de projeto.
A rela~ao com sistemas distribufdos pode ser esclarecida considerando redes de sensores como bancos de
dados distribufdos. Essa visao e bastante comum e facil
de entender quando se percebe que muitas redes de sensores saG montadas para aplica~6es de medi~ao e vigilancia (Bonnet et aI., 2002). Nesses casos, urn operador gostaria de extrair informa~6es de (uma parte de) uma rede
simples mente emitindo consultas como "Qual e a carga
de trafego na direc;ao norte na Rodovia I?". Essas consultas saG parecidas com as consultas tradicionais em bancos
de dados. Nesse caso, e provavel que a resposta tenha de
ser dada por meio da colabora~ao de muitos sensores
localizados ao longo da Rodovia 1, deixando, ao mesmo
tempo, os outros sensores intactos.
Para organizar uma rede de sensores como urn banco
de dados distribufdo ha, em essencia, dois extremos,
como mostra a Figura 1.10. No primeiro, os sensores nao
cooperam; simplesmente enviam seus dados a urn banco
de dados centralizado, localizado no site do operador. No
outro extremo, as consultas saG repassadas a sensores
relevantes e permite-se que cada urn processe uma resposta, 0 que requer que 0 operador agregue, de modo sensato, as respostas devol vidas.
Nenhuma dessas soluc;6es e muito atraente. A primeira requer que os sensores enviem pela rede todos os
seus dados medidos, 0 que pode desperdi~ar recursos de
rede e energia. A segunda solu~ao tambem pode ser perdularia, porque despreza as capacidades de agrega~ao dos
sensores que permitiriam 0 retorno de uma quantidade
muito menor de dados ao operador. Portanto, e preciso
facilidades para processamento de dados na rede, como
encontramos tambem em sistemas pervasivos de tratamento de saude.
o processamento de dados na rede pode ser feito de
varias maneiras. Vma obvia e repassar uma consulta a todos os nos sensores ao longo de uma arvore que abranja
todos os nos e, na sequencia, agregar os resultados a medida que saG propagados de volta a raiz em que esta localizado 0 iniciador. A agrega~ao ocorrera onde dois ou mais
ramos da arvore se encontrarem. Pode ate parecer que esse
sistema e simples, mas ele introduz quest6es diffceis:
1. Como montar (dinamicamente)

uma arvore eficiente em uma rede de sensores?


2. Como ocorre a agrega~ao de resultados? Ela pode
ser controlada?
3. 0 que acontece quando enlaces de rede falham?

Lado do operador

EJI~

sensores
sao enviados
diretamente
ao operador

Cada sensor
pode processar e
armazenar dados
Site do operador

[]
Figura 1.10

Organizando

:~nsore:<
enviam
somente
respostas

um banco de dados de rede de sensores e, ao mesmo tempo, armazenando

e processando dados (a) somente no site do operador ou (b) somente nos sensores.

Essas quest6es sao parcialmente resolvidas pelo


TinyDB, que implementa uma interface declarativa
(banco de dados) com redes de sensores sem fio. Em
essencia, 0 TinyDB pode usar qualquer algoritmo de
roteamento baseado em arvore. Urn no intermediario
colhera e agregara os resultados de seus filhos, junto com
suas proprias constata<;6es, e os enviara em dire<;ao a raiz.
Para dar eficiencia ao sistema, as consultas abrangem urn
periodo que leva em conta 0 cuidadoso escalonamento
das opera<;6es, de modo que 0 consumo de recursos da
rede e de energia seja otimo, Se quiser mais detalhes, consulte Madden et al. (2005).
Contudo, quando consultas podem ser iniciadas em
diferentes pontos da rede, usar arvores de umaunica raiz,
como no TinyDB, pode nao ser suficientemente eficiente.
Como alternativa, redes de sensores podem ser equipadas
com nos especiais para os quais sao repassados resultados, bem como as consultas relacionadas a esses resultados. Para dar urn exemplo simples, consultas e resultados
relacionados a leituras de temperatura sao colhidos em
urn lugar diferente dos relacionados as medi<;6es de umidade. Essa abordagem corresponde diretamente a no<;ao
de sistemas publicar/subscrever, que discutiremos minuciosamente no Capitulo 13.

Sistemas distribufdos consistem em computadores.


aut6nomos que trabalham juntos para dar a aparencia de
urn unico sistema coerente. Uma importante vantagem e

que eles facilitam a integra<;ao em um unico sistema de


diferentes aplica<;6es que executam em computadores
diferentes. Uma outra vantagem importante e que, quando adequadamente
projetados, sistemas distribufdos
podem ser ampliados com facilidade em rela<;ao ao tamanho da rede subjacente, Muitas vezes essas vantagens
vem a custa de software mais complexo, degrada<;ao do
desempenho e, tambem, freqiientemente, de men or seguran<;a. Nao obstante, ha consideravel interesse mundial na
constru<;ao e instala<;ao de sistemas distribufdos.
Sistemas distribufdos costumam ter como meta ocultar grande parte das complexidades relacionadas a distribui<;ao de processos, dados e controle, Contudo, essa
transparencia de distribui<;ao nao e apenas conseguida a
custa do desempenho, mas, em situa<;6es praticas, ela
nunca pode ser totalmente alcan<;ada, 0 fato de ser necessario estabelecer compromissos de modo a obter varias
formas de transparencia de distribui<;ao e inerente ao projeto de sistemas distribufdos, e e facil que elas compliquem a sua compreensao.
As coisas ficam ainda mais complicadas porque muitos desenvolvedores adotam premissas iniciais sobre a rede
subjacente que estao fundamentalmente erradas. Mais
tarde, quando essas premissas sao abandonadas, pode ficar
diffcil mascarar comportamentos indesejaveis. Urn exemplo tfpico e adotar como premissa que a latencia da rede
nao e significativa. Mais tarde, quando chega a hora de
transferir um sistema existente para uma rede de long a distancia, as latencias ocultas podem afetar profundamente 0
projeto original do sistema. Outras ciladas incluem admitir
que a rede e confiavel, estatica, segura e homogenea.

em tipos diferentes de sistemas distribufdos que

:= lassificados como orientados a suporte de


- . processamento de informac;6es e pervasivi~~ .::era!, sistemas de computac;ao distribuidos sao
: - para aplicac;6es de alto desempenho que muitas
~ originaram do campo da computac;ao paralela.
e classe de sistemas distribuidos pode ser
em ambientes tradicionais de escrit6rio, nos
- ancos de dados desempenham importante papel.
almente, sistemas de processamento de transautilizados nesses ambientes. Por fim, ha uma
~ ~orgente de sistemas distribuidos na qual os com-es ao pequenos e a sistema e composto ad hoc;
a ima de tudo, eles nao sao mais gerenciados por
urn administrador de sistemas. Essa ultima clasomo representantes tipicos os ambientes de com- ubiquos.

6. Par que nem sempre e uma boa ideia visar a implementac;ao do mais alto grau de transparencia possivel?
7. 0 que e urn sistema distribuido aberto e quais sao as
beneficios que a abertura proporciona?
B. Descreva, com exatidao,
escalcivel.

que quer dizer sistema

9. Pode-se conseguir escalabilidade pela aplicac;ao de


diferentes tecnicas. Quais sao essas tecnicas?
10. Explique 0 que significa organizariio virtual e de uma
sugestao para uma possivel implementac;ao dessas
organizac;6es.
11. Dissemos

que, quando uma transac;ao e abortada, 0


mundo e restaurado a seu estado anterior, como se a
transac;ao nunca tivesse acontecido. Mentimos. De urn
exemplo no qual restaurar 0 mundo e impossivel.

12. Executar transac;6es aninhadas requer certo tipo de


coordenac;ao. Explique 0 que urn coordenador deveria
realmente fazer.
~-ma definic;ao alternativa para urn sistema distribuido
'" que ele e urn conjunto de computadores independenque da a impressao de ser urn sistema unico, isto e,
fata de haver vaDas computadores fica completaente oculto para os usuarios. De urn exemplo para a
qual essa visao viria muito a calhar.
Qual e
uido?

papel do middleware em urn sistema distri-

_ 1uitos sistemas em rede sao organizados em termos


de uma retaguarda e de uma vanguarda. Como as
organizac;6es se ajustam a visao coerente que exigimos para urn sistema distribuido?
Explique 0 que quer dizer transparencia (de distribuic;ao) e de exemplos de diferentes tipos de transparencia.
Par que as vezes e tao dificil ocultar a ocorrencia e a
recuperac;ao de falhas em urn sistema distribuido?

13. Argumentamos que a transparencia de distribuic;ao


pode nao estar presente em sistemas pervasivos. Essa
declarac;ao nao vale para todos as tipos de transparencias. De urn exemplo.
14. Ia demos alguns exemplos de sistemas distribuidos
pervasivos: sistemas domesticos, sistemas eletronicos
para tratamento de saude e redes de sensores. Amplie
essa lista com mais exemplos.
IS. (Tarefa de laboratorio) Esboce urn projeto para urn
sistema domestico composto de urn servidor de rnidia
em separado, que leva em conta a ligac;ao com urn
cliente sem fio. Esse ultimo esta conectado a urn equipamento (anal6gico) de audio e video e transforma as
seqiiencias de midia digital em saida anal6gica. 0 servidor executa em uma maquina separada, possivelmente conectada a Internet, mas nao ha nenhum tecla-.
do nem monitor conectado a ela.

Вам также может понравиться