2Resumo cap.

2 Arquitetura (Livro Sistemas Distribudos princpios e

paradigmas)
A organizao de sistemas distribudos trata, em grande parte, dos
componentes de software que constituem o sistema. Essas arquiteturas de
software nos dizem como os vrios componentes de software devem ser
organizados e como devem interagir.
A realizao efetiva de um sistema distribudo implica que especifiquemos e
coloquemos componentes de software em mquinas reais. Para fazer isso,
h diferentes opes. A especificao final de uma arquitetura de software
tambm denominada arquitetura de sistema.
Tambm pode se conseguir a adaptabilidade em sistemas distribudos
fazendo o sistema monitorar seu prprio comportamento e tomar as
providncias adequadas quando necessrio. Esse modo de ver as coisas
resultou em uma classe que agora denominada sistemas autonmicos.
Esses sistema distribudos so frequentemente organizados sob a forma de
realimentaes de contato que formam um importante elemento
arquitetnico durante o projeto de um sistema.
2.1 Estilos Arquitetnicos
O estilo arquitetnico formulado em termos de componentes, do modo
como esses componentes esto conectados uns aos outros, dos dados
trocados entre componentes e, por fim, da maneira como esses elementos
so configurados em conjunto para formar um sistema. Um componente
uma unidade modular com interfaces requeridas e fornecidas bem definidas
que substituvel dentro de seu ambiente.
Uma questo importante sobe um componente para sistemas distribudos
que ele pode ser substitudo, contanto que respeitemos suas interfaces. Um
conceito um pouco mais difcil de entender o de um conector que, em
geral, descrito como um mecanismo que serve de mediador da
comunicao ou da cooperao entre componentes.
Usando componentes e conectores, podemos chegar a vrias configuraes
que, por sua vez, foram classificadas em estilo arquitetnicos. At agora j
foram identificados vrios estilos, os mais importantes sero citados a
seguir.
O estilo de arquitetura em camadas simples, os componentes so
organizados em camadas, e um componente na camada L_i tem permisso
de chamar componentes na camada subjacente L_(i-1), mas no o contrrio,
L_(i-1) no tem permisso de chamar componentes na camada L_i. O
controle flui de camada para camada: requisies descem pela hierarquia,
ao passo que resultados fluem para cima.

O estilo de arquitetura baseada em objetos uma arquitetura mais solta,

cada objeto corresponde a um componente, e esses componentes so
conectados por meio de uma chamada de procedimento.
Arquiteturas de entradas em dados se desenvolvem em torno da ideia de
que processos se comunicam por meio de um repositrio comum (passivo
ou ativo).
Em arquiteturas baseadas em eventos, os processos se comunicam, em
essncia, por meio da propagao de eventos que, opcionalmente, tambm
transportam dados. A ideia bsica que processos publiquem eventos aps
os quais o middleware assegura que somente os processos que se
subscreveram para esses eventos os recebero. A principal vantagem de
sistemas baseados em eventos que os processos so fracamente
acoplados.
2.2 Arquiteturas de sistemas
Decidir a respeito de componentes de software, sua interao e sua
colocao leva a um exemplo de uma arquitetura de software tambm
denominada arquitetura de sistema.
2.2.1 Arquiteturas centralizadas
Apesar da falta de consenso sobre muitas questes de sistemas
distribudos, h uma delas com a qual muitos pesquisadores e praticantes
concordam: pensar em termos de clientes que requisitam servios de
servidores nos ajuda a entender e gerenciar a complexidade de sistemas
distribudos.
No modelo cliente-servidor bsico, processos em um sistema distribudo so
divididos em dois grupos, com possvel sobreposio. Um servidor um
processo que implementa um servio especifico. Um cliente um processo
que requisita um servio de um servidor enviando-lhe uma requisio e, na
sequncia, esperando pela resposta do servidor.
Considerando que muitas aplicaes cliente-servidor visam a dar suporte ao
acesso de usurios a banco de dados, muitas pessoas defendem uma
distino entre os trs nveis, nvel de interface de usurio, nvel de
processamento e nvel de dados. Em essncia o estilo arquitetnico em
camadas.
O nvel de interface de usurio contm tudo que necessrio para fazer
interface diretamente com o usurio, como gerenciamento de exibio. O
nvel de processamento normalmente contm as aplicaes. O nvel de
dados gerencia os dados propriamente ditos sobre os quais est sendo
executada alguma ao.

A distino entre trs nveis lgicos, sugere vrias possibilidades para a

distribuio fsica de uma aplicao cliente-servidor por vrias mquinas. A
organizao mais simples ter s dois tipos de mquinas:
Uma mquina cliente que contm apenas os programas que implementam o
nvel de interface de usurio.
Uma mquina do servidor que contm o resto, ou seja, os programas que
implementam o nvel de processamento e de dados.
Nessa organizao, tudo manipulado pelo servidor, ao passo que, em
essncia, o cliente nada mais do que um terminal burro, possivelmente
com uma interface grfica bonitinha.
2.2.2 Arquiteturas descentralizadas
Arquiteturas cliente-servidor multidivididas so uma consequncia direta da
diviso de aplicaes em uma interface de usurio em componentes de
processamento e em um nvel de dados. As diferentes divises
correspondem diretamente organizao lgica das aplicaes. Em muitos
ambientes de negcios, processamento distribudo equivale a organizar uma
aplicao cliente-servidor como uma arquitetura multidivididas. Esse tipo de
distribuio denominada distribuio vertical. O aspecto caracterstico da
distribuio vertical que ela obtida ao se colocar componentes
logicamente diferentes em mquinas diferentes.
Na distribuio horizontal um cliente ou servidor pode ser fisicamente
subdividido em partes logicamente equivalentes, mas cada parte est
operando em sua prpria poro do conjunto completo de dados, o que
equilibra a carga.
Em uma arquitetura peer-to-peer estruturada, a rede de sobreposio
construda com a utilizao de um procedimento determinstico. O
procedimento mais usado , de longe organizar os processos por meio de
uma tabela de hash distribuda.
O ponto crucial de todo sistema baseado em DHT implementar um
esquema eficiente e determinstico que mapeie exclusivamente a chave de
um item de dado para o identificador de um n tendo como base somente
alguma distncia mtrica. O mais importante que, ao consultar um item
de dado, o endereo de rede do n responsvel por aquele item de dado
retornado.
Sistemas peer-to-peer no estruturados dependem, em grande parte, de
algoritmos aleatrios para construir uma rede de sobreposio. A ideia
principal que cada n mantenha uma lista de vizinhos, mas que essa lista
seja construda de modo mais ou menos aleatrio. Da mesma maneira,
admite-se que itens de dados sejam colocados aleatoriamente em ns. Por
consequncia, quando um n precisa localizar um item de dado especfico, a

nica coisa que ele efetivamente pode fazer inundar a rede com uma
consulta de busca.
Pode parecer que sistemas peer-to-peer estruturados e no estruturados
formem classes estritamente independentes, na verdade pode no ser esse
o caso. Uma observao fundamental que ao trocar e selecionar
cuidadosamente as entradas de vises parciais, possvel construir e
manter topologias especificas de redes de sobreposio.
Localizar itens de dados relevantes em sistemas peer-to-peer no
estruturados pode se tornar problemtico medida que a rede cresce.
Muitos sistemas peer-to-peer propuseram a utilizao de ns especiais que
mantenham um ndice de itens de dados. Esses ns em geral so chamados
superpares.
2.2.3 Arquiteturas hbridas
Uma classe importante de sistemas distribudos organizada segundo uma
arquitetura hbrida formada por sistemas de servidor de borda. Usurios
finais, ou clientes em geral, se conectam com a Internet por meio de um
servidor de borda. A principal finalidade do servidor de borda servir
contedo, possivelmente aps ter aplicado funes de filtragem e
transcodificao. Mais interessante o fato de que um conjunto de
servidores de borda pode ser usado para otimizar distribuio de contedo e
de aplicao.
Estruturas hibridas so disponibilizadas notavelmente em sistemas
distribudos colaborativos. A questo principal em muitos desses sistemas
conseguir dar a partida, para o que muitas vezes disponibilizado um
esquema cliente-servidor tradicional. To logo um n se junte ao sistema,
ele pode usar um esquema totalmente descentralizado para colaborao. A
ideia bsica que, quando um usurio final estiver procurando um arquivo,
ele transfira pores do arquivo de outros usurios at que as pores
transferidas possam ser montadas em conjunto, resultando no arquivo
completo.
2.3 Arquitetura versus Middleware
Moldar o middleware de acordo com um estilo arquitetnico especifico tem
como beneficio a simplificao do projeto de aplicaes. Contudo, uma
bvia desvantagem que o middleware pode no ser mais o ideal para
aquilo que um desenvolvedor de aplicao tinha em mente. Uma
abordagem em geral considerada melhor fazer sistemas de middleware de
modo que sejam simples de configurar, adaptar e personalizar conforme
necessrio para uma aplicao.
Um interceptador nada mais do que um constructo de software que
interromper o fluxo de controle usual e permitir que seja executado um
outro cdigo. Fazer com que interceptores sejam genricos p

ode exigir esforo substancial de implementao.

2.3.2 Abordagens gerais para o software adaptativo
O que os interceptadores realmente oferecem um meio de adaptar o
middleware. A necessidade de adaptao resulta do fato de que o ambiente
no qual as aplicaes distribudas so executadas est sempre mudando.
Em vez de fazer com que as aplicaes sejam responsveis por reagir
mudanas, essa tarefa colocada no middleware.
2.3.3 Discusso
Arquiteturas de software para sistemas distribudos, encontradas
consideravelmente como middleware, so volumosas e complexas. Em
grande parte, tal volume e complexidade
surgem da necessidade de ser geral no sentido de que preciso
proporcionar transparncia de distribuio. Ao mesmo tempo, aplicaes
tm requisitos extrafuncionais especficos que conflitam com a meta de
conseguir totalmente essa transparncia. Esses requisitos conflitantes para
generalidade e especializao resultaram em solues de middleware de
alta flexibilidade.
2.4 Autogerenciamento em sistemas distribudos
Sistemas distribudos e em especial seu middleware associado precisam
fornecer solues gerais de blindagem contra aspectos indesejveis
inerentes a redes, de modo que possam suportar o maior nmero possvel
de aplicaes. Por outro lado, a total transparncia de distribuio no
algo que, na verdade, a maioria das aplicaes quer, o que resulta em
solues especficas de aplicao que tambm precisam ser suportadas.
Quando a adaptao precisa ser automtica, observamos um forte
intercmbio entre arquiteturas e sistemas de software.
2.4.1 O modelo de realimentao de controle
H muitas vises diferentes sobre sistemas autogerenciadores, mas o que a
maioria deles tem em comum, explicita ou implicitamente, a premissa de
que as adaptaes ocorrem por meio de um ou mais laos de realimentao
de controle. De acordo com esse fato, sistemas organizados por meio
desses laos so denominados sistemas de realimentao de controle. O
ncleo de um sistema de realimentao de controle formado pelos
componentes que precisam ser gerenciados.