Sumrio

1 Introduo.................................................................................................................................................. 3
1.1 Caractersticas .................................................................................................................................... 4
1.1.1 Heterogeneidade ......................................................................................................................... 4
1.1.2 Segurana .................................................................................................................................... 4
1.1.3 Escalabilidade ............................................................................................................................. 4
1.1.4 Tolerncia a Falhas ..................................................................................................................... 4
1.1.5 Concorrncia ............................................................................................................................... 4
1.1.6 Transparncia .............................................................................................................................. 5
1.1.7 Flexibilidade ............................................................................................................................... 5
1.1.8 Confiabilidade............................................................................................................................. 5
1.1.9 Desempenho ............................................................................................................................... 5
1.2 Elementos bsicos de um SD ............................................................................................................. 6
1.2.1 Sistema de Nomes ....................................................................................................................... 6
1.2.2 Comunicao .............................................................................................................................. 6
1.2.4 Alocao de carga de trabalho .................................................................................................... 7
1.2.5 Manuteno de consistncia ....................................................................................................... 7
2 Modelos de Sistemas ................................................................................................................................. 8
2.1 Modelos de arquitetura ....................................................................................................................... 8
2.1.1 Elementos arquitetnicos ............................................................................................................ 8
2.1.2 Camadas de software ................................................................................................................ 10
2.1.3 Comunicao entre processos ................................................................................................... 11
2.1.4 Comunicao sncrona e assncrona ......................................................................................... 11
2.1.5 Comunicao em Grupo ........................................................................................................... 11
2.2 Modelos Fundamentais .................................................................................................................... 12
2.2.1 Modelo de Integrao ............................................................................................................... 12
2.2.2 Modelo de falha ........................................................................................................................ 12
2.2.3 Modelo de segurana ................................................................................................................ 13
3 Padres de Projetos Middleware ............................................................................................................. 14
3.1 Requestor ......................................................................................................................................... 14
3.2 Cliente Proxy ................................................................................................................................... 15
3.3 Invoker ............................................................................................................................................. 16
3.4 Client Request Handler .................................................................................................................... 17
3.5 Server Request Handler.................................................................................................................... 18
3.6 Marshaller ........................................................................................................................................ 19
3.7 Interface Description ........................................................................................................................ 20
3.8 Remoting Error ................................................................................................................................ 21

REFERENCIAS .............................................................................................................................................. 21

1 Introduo
Segundo Tanembaum,A. Um sistema distribudo um conjunto de computadores independentes
entre si que se apresenta a seus usurios como um sistema nico e coerente
Segundo Coulouris,G. Coleo de computadores autnomos interligados atravs de uma rede de
computadores e equipamentos com software que permita o compartilhamento dos recursos do sistema:
hardware, software e dados
Definimos um sistema distribudo como sendo aquele no qual os componentes de hardware ou
software, localizados em computadores interligados em rede, se comunicam e coordenam suas aes apenas
passando mensagens entre si. O compartilhamento de recursos um forte motivo para a construo de
sistemas distribudos. Os recursos podem ser gerenciados por servidores e acessados por clientes. Os
computadores conectados por meio de uma rede podem estar separados por qualquer distncia. Eles podem
estar em continentes separados, no mesmo prdio ou na mesma sala. A definio de SD tem as seguintes
consequncias importantes:
Concorrncia: em uma rede de computadores, a execuo concorrente de computadores a norma.
Posso fazer meu trabalho em meu computador, enquanto voc faz o seu em sua mquina, compartilhando
recursos como pginas web ou arquivos, quando necessrio.
Inexistncia de relgio global: quando os programas precisam cooperar, eles coordenam suas
aes trocando mensagens.
Falhas independentes: cada componente do sistema pode falhar independentemente, deixando os
outros ainda em funcionamento.
Como exemplo de sistemas distribudos tempos a internet, que atravs de um protocolo de
comunicao relativamente simples, possvel realizar trocas de arquivos como msica, vdeo e demais
tipos de dados com computadores localizados em vrias partes do planeta. Temos tambm os processadores
multincleo, basicamente distribuem as tarefas entre os vrios ncleos, o que dinamiza o processamento.
Temos tambm, rede de telefonia celular, rede de computadores em uma fbrica ou um grande banco com
muitas agncias, cada qual com computadores e caixas eletrnicos.
Os desafios advindos da construo de sistemas distribudos so a heterogeneidade de seus
componentes, ser um sistema aberto, o que permite que componentes sejam adicionados ou substitudos, a
segurana, a escalabilidade a capacidade de funcionar bem quando o nmero de usurios aumenta o
tratamento de falhas, a concorrncia de componentes e a transparncia.
Vantagens:

Economia: aproveita maquinas potencialmente ociosas, mais barato ter vrios processadores
interconectados do que ter um supercomputador;
Velocidade: a capacidade de interconectar processadores possibilita que se obtenham
performances que apenas um sistema composto capaz de atingir;
Distribuio inerente: mquinas espacialmente separadas;
Confiabilidade: se uma mquina falha, o sistema como um todo pode ainda sobreviver;
Crescimento incremental: poder computacional adicionado em incrementos;
Elasticidade.

Desvantagens:

Falta de software adequado: maior complexidade no desenvolvimento;

Falhas e saturao da rede: redes carregadas;
Segurana: comprometimento dos dados trafegados, vrias portas de acesso.

1.1 Caractersticas
1.1.1 Heterogeneidade
Principio da computao que permite hardware e software acessarem servios e executarem aplicativos por
meio de um conjunto heterogneo de computadores e redes. A heterogeneidade (isto , variedade de
diferena) se aplica aos seguintes aspectos:

Redes;
Hardware de Computadores;
Sistemas Operacionais;
Linguagens de Programao;
Implementao de diferentes desenvolvedores.

1.1.2 Segurana
A segurana de recursos de informao tem trs componentes: confiabilidade (proteo contra exposio
para pessoas no autorizadas), integridade (proteo contra alterao ou dano) e disponibilidade (proteo
contra interferncia com os meios de acesso aos recursos).
1.1.3 Escalabilidade
Um sistema dito escalvel se permanece eficiente quando h um aumento significativo no nmero de
recursos e no nmero de usurios. A internet um exemplo de um sistema distribudo no qual o nmero de
computadores e servios vem aumentando substancialmente. O projeto de sistemas distribudos, escalveis,
apresenta os seguintes desafios:

Controlar o custo dos recursos fsicos: medida que a demanda por um recurso aumenta, deve ser
possvel, a um custo razovel, ampliar o sistema para atend-la;
Controlar a parda de desempenho: gerenciamento de um conjunto de dados, cujo tamanho
proporcional ao nmero de usurios ou recursos presentes no sistema;
Impedir que os recursos de softwares esgotem-se;
Evitar gargalos de desempenho.

1.1.4 Tolerncia a Falhas

As falhas em sistemas distribudos so parciais isto , alguns componentes falham, enquanto outros
continuam funcionando. Portanto o tratamento de falhas particularmente difcil. Os SDs fornecem um
alto grau de disponibilidade perante falhas de hardware. A disponibilidade de um sistema a medida da
proporo de tempo em que ele est pronto para uso. Quando um dos componentes de um SD falha, apenas
o trabalho que estava usando o componente defeituoso afetado. Um usurio pode passar para outro
computador, caso aquele que estava usando falhe; um processo servidor pode ser iniciado em outro
computador.

Recuperao de falhas: a recuperao envolve projetar software de modo que o estado dos dados
permanentes possa ser recuperado ou retrocedido, aps a falha de um servidor;
Redundncia: os servios podem se tornar tolerantes a falhas com o uso de componentes
redundantes. Exemplo: um BD pode ser replicado em vrios servidores, para garantir que os dados
permaneam acessveis aps a falha de qualquer servidor.

1.1.5 Concorrncia
Alteraes feitas por um cliente no devem interferir nas operaes de outros clientes, mesmo que esses
clientes estejam manipulando o mesmo arquivo. Essas operaes devem ser sincronizadas de tal maneira
que seus dados permaneam consistentes. Isso pode ser obtido atravs de tcnicas padro, como semforos,
que so disponveis na maioria dos SOs.

1.1.6 Transparncia
A transparncia definida como sendo a ocultao, para um usurio final ou para um programador de
aplicativos, da separao dos componentes em um SD de modo que o sistema seja percebido como um
todo, em vez de uma coleo de componentes independentes. Esconder do usurio e do programador de
aplicaes a separao de componentes em um SD, tal que este seja visto como um sistema centralizado.

Transparncia de acesso: permite que os recursos locais e remotos sejam acessados com o uso de
operaes idnticas;
Transparncia de localizao: permite que os recursos sejam acessados sem o conhecimento de
sua localizao fsica ou na rede;
Transparncia de concorrncia: permite que vrios processos operem concorrentemente, usando
recursos compartilhados sem interferncia entre eles;
Transparncia de replicao: permite que vrias instncias dos recursos sejam usadas para
aumentar a confiabilidade e o desempenho, sem conhecimento das rplicas por parte dos usurios
ou dos programadores de aplicativos;
Transparncia de falhas: permite a ocultao de falhas, possibilitando que usurios e programas
aplicativos concluam suas tarefas, a despeito da falha de componentes de HW e SW;
Transparncia de mobilidade: permite a movimentao de recursos e clientes dentro de um
sistema, sem afetar a operao de usurios ou programas;
Transparncia de desempenho: permite que o sistema seja reconfigurado para melhorar o
desempenho medida que as cargas variam;
Transparncia de escalabilidade: permite que o sistema e os aplicativos se expandam em escala
sem alterar a estrutura do sistema ou os algoritmos de aplicativo.

1.1.7 Flexibilidade
Com a grande quantidade de processadores trabalhando em conjunto devem existir mecanismos para
permitir adaptaes dinmicas durante a execuo do sistema. Quase sempre ocorrer situaes no
previstas gerando quebras no fluxo do sistema e o SD deve ser capaz de contornar isso de forma simples,
tambm deve ser fcil a incluso ou excluso de processadores do sistema sem que para isso seja
necessrio modificar todos os componentes ou parar o funcionamento do SD.
Ncleo monoltico: inclui gerenciamento de arquivos, diretrios e processos
Micro-ncleo:

Mecanismo para comunicao entre processos;

Gerenciamento bsico de memria;
Gerenciamento de processos a baixo nvel;
Operaes de entrada/sado a baixo nvel.

1.1.8 Confiabilidade
Os SD devem possuir a capacidade, pelo menos em tese, de que se uma de suas mquinas parar de
funcionar uma outra mquina dever assumir os servios que a mquina que parou fornecia. Alguns
aspectos relacionados a confiabilidade devem ser levados em considerao como:

Disponibilidade: O sistema est funcionando, chaves de hardware e software devem ser

replicados, de modo que se um deles falhar, os outros estaro aptos a tomar conta da tarefa;
Exatido: Replicao versus consistncia;
Segurana: Como um servidor pode verificar a origem de uma mensagem?
Tolerncia de falhas: replicao versus desempenho (descrito no tpico 1.1.4.).

1.1.9 Desempenho
Em geral, espera-se que uma aplicao distribuda apresente um desempenho melhor que aquele atribudo
a um sistema centralizado. O desempenho uma grandeza que pode ser avaliada de diferentes formas

dependendo do tipo de aplicao, uma vez este fator desempenho pode estar associado a diferentes
conceitos ou aspectos.
1.1.9.1 Mtricas de desempenho;
Tempo de resposta do servidor;
Throughput (tarefas / tempo);
Utilizao do sistema;
Quantidade consumida da capacidade da rede.
Um sistema com mltiplos processadores fracamente acoplados pode obter um desempenho que seria
impossvel em um sistema com um processador, uma vez que podem reunir uma quantidade superior de
processadores do que um sistema fortemente acoplado, mas raramente N processadores tem o
desempenho de N vezes maior que um processador (escalabilidade), uma vez que depende de troca de
mensagens.
Por outro lado, um sistema com N processadores custa menos que um processador com N vezes mais
velocidade, especialmente quando possvel aproveitar mquinas potencialmente ociosas e realizar
tarefas em paralelo, aumentando o throughput do sistema.
1.2 Elementos bsicos de um SD
1.2.1 Sistema de Nomes
Em sistemas distribudos, so usados nomes para fazer referncia a uma ampla variedade de recursos,
como computadores, servios, objetos remotos e arquivos, assim como usurios. A atribuio de nomes
um problema facilmente desprezado, mais com certeza fundamental no projeto de sistemas distribudos.
Os processos no podem compartilhar recursos em particular a no ser que possam atribuir nomes a eles
de forma consistente. Gerencia tabelas de nomes e funes do sistema. um elemento fundamental em
um Sistema Distribudo. As mquinas chamadas servidores de nome de domnio permitem estabelecer a
correspondncia entre o nome de domnio e o endereo IP das mquinas de uma rede, o mecanismo que
consiste em encontrar o endereo IP que corresponde ao nome da mquina que se quer conectar.

Nomes permitem que recursos sejam compartilhados;

Nomes de recursos devem ser independendentes de sua localizao;
O esquema de nomes deve escalar bem;
Um sistema de interpretao de nomes deve ser acessvel por programa.

1.2.2 Comunicao
O sucesso de um bom SD est na forma em que o sistema se comunica e transita suas mensagens tendo o
desempenho/confiabilidade.

1.2.3 Estrutura de software

SO fortemente acoplado para multiprocessadores e multicomputadores homogneos com o intuito de
esconder e gerenciar recursos de hardware.

Extensibilidade requer componentes de software com interfaces bem definidas;

Um servio um gerenciador de objetos de um certo tipo e sua interface um conjunto de
operaes;
Novos servios devem interoperar com servios existentes e no duplicar suas funes gerando
inconsistncia.

1.2.4 Alocao de carga de trabalho

Boa performance um requisito para a maior parte dos SD, tem impacto na efetividade com qual
os recursos de hardware de um SD so usados, e portanto, na performance total do sistema;
Computadores multiprocessadores de memria compartilhada so frequentemente usados para
tarefas intensivas de processador em SDs;
Melhor uso da capacidade de comunicao entre as mquinas, gerando menos trfego na rede.
1.2.5 Manuteno de consistncia
Consistncia de atualizao: Perde-se quando a escrita concorrente em dados compartilhados no
se realiza como uma nica transao atmica
Consistncia de rplica: Quando um conjunto de dados deve se manter replicado em vrias
estaes

Consistncia de cache: Modificaes em um cliente devem ser propagadas ao gerenciador e aos

demais clientes
Consistncia de falha: Deve-se evitar falhas mltiplas (em cascata); isolamento de falhas
Consistncia de relgio: Relgios fsicos (sincronizao aproximada) e relgios lgicos
(timestampings em mensagens)
Consistncia de interface de usurio: Em uma aplicao distribuda interativa, o usurio aperta
um boto e o resultado na tela no aparece de imediato, como se esperaria Pode ter havido um
retardo (de comunicao) maior do que o usurio suportaria para ter a impresso de dispor de um
sistema dedicado

2 Modelos de Sistemas
Cada modelo destinado a fornecer uma descrio abstrata e simplificada, mas consistente, de um aspecto
relevante do projeto de um sistema distribudo. So divididos entre modelos fsicos, modelos de arquitetura
e modelos fundamentais.

Modelos Fsicos: consideram os tipos de computadores e equipamentos que constituem um

sistema e sua interconectividade, sem os detalhes das tecnologias especficas.
Modelos de Arquitetura: define a forma pela qual os componentes dos sistemas interagem e a
maneira pela qual eles so mapeados em uma rede de computadores subjacentes.
Modelos Fundamentais: ajudam a revelar aspectos importantes para os projetistas de SD.

2.1 Modelos de arquitetura

A arquitetura de um sistema sua estrutura em termos de componentes especificados separadamente. O
objetivo global garantir que a estrutura atenda as demandas atuais e, provavelmente, as futuras impostas
sobre ela. As maiores preocupaes so tornar o sistema confivel, gerencivel, adaptvel e rentvel.
Primeiramente o modelo arquitetnico simplifica e abstrai as funes dos componentes individuais de um
SD e, em seguida, considera: o posicionamento dos componentes em uma rede de computadores e os interrelacionamentos entre os componentes.
2.1.1 Elementos arquitetnicos
Entidades de comunicao: definem o que est se comunicando e como se comunicam.

Objetos: os objetos foram introduzidos para permitir e estimular o uso de estratgias orientadas a
objetos nos sistemas distribudos (incluindo o projeto orientado a objeto e as linguagens de
programao orientadas a objeto). Os objetos so acessados por meio de interfaces, com uma
linguagem de definio de interface (IDL) associada fornecendo uma especificao dos mtodos
definidos nesse objeto.
Componentes: os componentes se parecem com objetos, pois oferecem abstraes voltadas ao
problema para a construo de sistemas distribudos e tambm so acessados por meio de
interfaces. A principal diferena que os componentes especificam um contrato mais completo
para a construo do sistema. Essa estratgia mais contratual estimula e permite o
desenvolvimento de componentes por terceiros e tambm promove uma abordagem de
composio mais pura para a construo de sistemas distribudos, por remover dependncias
ocultas.
Servio Web: so intimamente relacionados aos objetos e aos componentes, novamente adotando
uma estratgia baseada no encapsulamento de comportamento e no acesso por meio de interfaces.
Enquanto os objetos e componentes so usados para o desenvolvimento de aplicaes fortemente
acopladas, os servios web podem ser implementados por diferentes provedores e usar diferentes
tecnologias.

Paradigmas de comunicao: define como as entidades se comunicam em um SD.

Comunicao entre processos: se refere ao suporte de nvel relativamente baixo para comunicao entre
processos nos sistemas distribudos, incluindo primitivas de passagem de mensagens, acesso direto API
oferecida pelos protocolos Internet (programao de soquetes) e tambm o suporte para comunicao em
grupo (multicast).
Invocao remota: cobre uma variedade de tcnicas baseadas na troca bilateral entre as entidades que se
comunicam em um sistema distribudo e resultando na chamada de uma operao, um procedimento ou
mtodo remoto.

Protocolos de requisio-resposta: so efetivamente um padro imposto em um servio de

passagem de mensagem para suportar comunicao cliente-servidor. Em particular, esses
protocolos normalmente envolvem uma troca por pares de mensagens do cliente para o servidor
e, ento, do servidor para o cliente. Esse paradigma bastante primitivo e utilizado somente em
sistemas em que o desempenho fundamental.
Chamada de procedimento remoto: uma tecnologia de comunicao entre processos que permite
a um programa de computador chamar um procedimento em outro espao de endereamento,
como se fossem procedimentos no espao de endereamento local. Uma CPR iniciada pelo
cliente enviando uma mensagem para um servidor remoto para executar um procedimento
especfico. Uma resposta retornada ao cliente. Uma diferena importante entre CPR e CPL
que, no primeiro caso, a chamada pode falhar por problemas de rede. Neste caso, no h nem
mesmo garantia de que o procedimento foi invocado.
Invocao de mtodo remoto: com essa estratgia, um objeto chamador pode invocar um mtodo
em um objeto potencialmente remoto, usando invocao de mtodo remoto. Assim como na CPR,
os detalhes subjacentes geralmente ficam ocultos do usurio. O funcionamento consiste
basicamente em dois programas, segundo a arquitetura cliente-servidor, onde um seria o cliente e
o outro servidor. O servidor instancia objetos remotos, o referencia com um nome e faz um
BIND dele numa porta, onde este objeto espera por clientes que invoquem seus mtodos. J o
cliente referencia remotamente um ou mais mtodos de um objeto remoto.

Comunicao indireta: a essncia da comunicao indireta se comunicar por meio de um intermedirio e,

assim, no ter qualquer acoplamento direto entre o remetente e um ou mais destinatrios. Neste caso, os
remetentes no precisam saber para quem esto enviando (desacoplamento espacial) e os remetentes e os
destinatrios no precisam existir ao mesmo tempo (desacoplamento temporal).

Comunicao em grupo: est relacionada entrega de mensagens para um conjunto de

destinatrios e, assim, um paradigma de comunicao de vrias partes, suportando, comunicao
de um para muitos.
Sistemas publicar-assinar: um sistema em que publicadores divulgam eventos estruturados para
um servio de evento e assinantes expressam interesse em eventos especficos por meio de
assinaturas, as quais podem ser padres arbitrrios sobre os eventos estruturados. O objetivo
principal combinar as assinaturas com os eventos publicados e garantir a entrega correta de
notificaes de evento.
Fila de mensagens: enquanto os sistemas publicar-assinar oferecem um estilo de comunicao de
um para muitos, as filas de mensagens oferecem um servio ponto a ponto por meio do qual os
processos produtores podem enviar mensagens para uma fila especificada e os processos
consumidores recebem mensagens da fila ou so notificados da chegada de novas mensagens na
fila. Portanto, as filas oferecem uma indireo entre os processos produtores e consumidores.
Espaos de tupla: modelo pelo qual os processos podem colocar itens de dados estruturados
arbitrrios chamados tuplas, em um espao de tupla persistente e outros processos podem ler ou
remover tais tuplas desse espao, especificando padres de interesse. Como o espao de tupla
persistente, os leitores e escritores no precisam existir ao mesmo tempo.
Memria compartilhada distribuda: fornecem uma abstrao para compartilhamento de dados
entre processos que no compartilham a memria fsica. Contudo, apresentada aos
programadores uma abstrao de leitura ou de escrita de estruturas de dados (compartilhadas)
conhecida, como se estivessem em seus prprios espaos de endereamento locais, apresentando,
assim, um alto nvel de transparncia de distribuio.

2.1.2 Camadas de software

O termo arquitetura de software se refere estruturao do software em camadas em um nico computador
e, mais recentemente, em termos de servios oferecidos e solicitados entre processos localizados em um
mesmo computador ou em computadores diferentes. Essa viso orientada para processo e servio pode ser
expressa em termos de camadas e servios. Um servidor um processo que aceita pedidos de outro
processo. Um cliente um processo que solicita algum servio a um ou vrios processos servidores.
As camadas de HW e SW de mais baixo nvel so frequentemente denominadas de plataforma para sistemas
e aplicativos distribudos. Essas camadas de mais baixo nvel fornecem servios para as camadas que esto
acima delas com o objetivo de levar a interface de programao do sistema a um nvel que facilita a
comunicao e a coordenao entre processos.
A camada chamada de middleware um programa de computador que faz a mediao entre SW e demais
aplicaes. utilizado para mover ou transportar informaes e dados entre programas de diferentes
protocolos de comunicao, plataformas e dependncias do SO. Tem como objetivo principal mascarar a
heterogeneidade e fornecer um modelo de programao conveniente para os programadores de aplicao.
Em particular, a camada middleware, simplifica as atividades de comunicao de programas aplicativos
por meio do suporte de abstrao como a invocao a mtodos remotos, a comunicao entre grupos de
processos, a notificao de eventos, o particionamento, posicionamento e recuperao de objetos de dados
compartilhados entre computadores, a replicao de objetos de dados compartilhados e a transmisso de
dados multimdia em tempo real.
A diviso de responsabilidades entre os componentes de um sistema (aplicativos, servidores e outros
processos) e a atribuio destes nos diversos computadores de uma rede talvez seja o aspecto mais evidente
de projeto de sistemas distribudos. Isso tem implicaes importantes no desempenho, na confiabilidade e
na segurana do sistema resultante. Os principais modelos de arquitetura para SDs so cliente-servidor e
peer-to-peer.
Cliente-servidor: historicamente est a arquitetura mais importante e continua sendo amplamente
empregada e a mais utilizada no meio dos SDs. Em particular, os processos clientes interagem com
processos servidores, localizados possivelmente em distintos computadores hospedeiros, para acessar os
recursos compartilhados que estes gerenciam. Funcionalidades como troca de e-mail, acesso internet ou
acesso a um banco de dados, so construdos como base no modelo cliente-servidor. Por exemplo, um
navegador web um programa cliente, em execuo no computador do usurio, que acede s informaes
armazenadas num servidor web na internet.
Peer-to-peer: uma arquitetura de redes de computadores onde cada um dos pontos ou ns da rede funciona
tanto como cliente quanto como servidor, permitindo compartilhamentos de servios e dados sem a
necessidade de um servidor central. Cada computador da rede um n e fica responsvel por uma parcela
dos recursos da rede, tais como armazenamento, poder de processamento e largura de banda. Os recursos
so divididos diretamente entre cada participante da rede sem a necessidade de uma coordenao central
de um servidor. Nesse modelo de rede, cada par de computadores so fornecedores e consumidores de
recursos, diferente do modelo cliente-servidor, onde o servidor alimenta toda rede e os clientes somente
consomem.

2.1.3 Comunicao entre processos

A passagem de mensagem entre um par de processos pode ser suportada por duas operaes de
comunicao de mensagem: send e receive, definidas em termos de destinos e mensagens. Para que um
processo se comunique com outro, um deles envia (send) uma mensagem (uma sequncia de bytes) para
um destino e o outro processo, no destino, recebe (receive) a mensagem. Essa atividade envolve a
comunicao de dados do processo remetente para o processo destino e pode implicar na sincronizao dos
dois processos.
2.1.4 Comunicao sncrona e assncrona
Uma fila associada a cada destino de mensagem. Os processos remetentes fazem as mensagens serem
adicionadas em filas remotas e os processos destino removem mensagens de suas filas locais. A
comunicao entre os processos remetente e destino pode ser sncrona ou assncrona. Na forma sncrona de
comunicao, os processos remetente e destino so sincronizados a cada mensagem. Nesse caso, send e
receive so operaes que causam bloqueio. Quando um envio (send) feito, o processo remetente (ou
thread) bloqueado at que a recepo (receive) correspondente seja realizada. Quando uma recepo
executada, o processo bloqueado enquanto a mensagem no chega.
Na forma assncrona de comunicao, o uso da operao send no bloqueante, no sentido de que o
processo remetente pode prosseguir assim que a mensagem tenha sido copiada para um buffer local, e a
transmisso da mensagem ocorre em paralelo com o processo remetente.
Soquete: definido como um ponto de destino para comunicao entre processos. A comunicao entre
processos consiste em transmitir uma mensagem entre um soquete de um processo e um soquete de outro
processo. Para que um processo receba mensagens, seu soquete deve estar vinculado a uma porta local e a
um dos endereos IP do computador em que executado. As mensagens enviadas para um endereo IP e
um nmero de porta em particular s podem ser recebidas por um processo cujo soquete esteja associado a
esse endereo IP e a esse nmero de porta. Os processos podem usar o mesmo soquete para enviar e receber
mensagens.
2.1.5 Comunicao em Grupo
A troca de mensagem aos pares no o melhor modelo para a comunicao de um processo com um grupo
de outros processos, como o que ocorre, por exemplo, quando um servio implementado atravs de
diversos processos em computadores diferentes para fornecer tolerncia a falhas ou melhorar a
disponibilidade. Nesse caso o emprego do multicast mais apropriado trata-se de uma operao que
permite o envio de uma nica mensagem para cada um dos membros de um grupo de processos de tal forma
que membros participantes do grupo ficam totalmente transparentes para o remetente.
Multicast: permite que o remetente transmita um nico datagrama IP para o conjunto de computadores que
formam um grupo de multicast. O remetente no conhece as identidades dos destinatrios individuas nem
do tamanho do grupo. A participao como membro de grupos multicast dinmica, permitindo aos
computadores entrarem ou sarem a qualquer momento e participarem de um nmero arbitrrio de grupos.
possvel enviar datagramas para um grupo multicast sem ser membro.

2.2 Modelos Fundamentais

Esses modelos definem propriedades fundamentais que se preocupam com as caractersticas de
desempenho e confiabilidade dos processos, das redes de comunicao e com a segurana dos recursos
presentes no sistema. Geralmente um modelo contm apenas os ingredientes essenciais que precisamos
considerar para entender e raciocinar a respeito de certos aspectos do comportamento de um sistema. O
objetivo de um modelo :

Tornar explcitas todas as suposies relevantes sobre os sistemas que estamos modelando
Fazer generalizaes a respeito do que possvel ou impossvel

2.2.1 Modelo de Integrao

A computao feita por processos. Eles interagem passando mensagens, resultando na comunicao
(fluxo de informaes) e na coordenao (sincronizao e ordenao das atividades) entre eles. Na anlise
e no projeto de sistemas distribudos, preocupamo-nos especialmente com essas interaes. O modelo de
interao deve refletir o fato de que a comunicao ocorre com atrasos que, frequentemente, tm durao
considervel. A preciso com a qual processos independentes podem ser coordenados limitada pelos
atrasos de comunicao e pela dificuldade de se manter a mesma noo de tempo entre todos os
computadores de um sistema distribudo. Dessa forma, os processos interagem atravs de passagem de
mensagem para resolver um problema.
Os fatores que afetam significativamente a interao de processos em um sistema distribudo:

Latncia: o atraso entre o envio de uma mensagem por um processo e seu recebimento por outro
processo.
Largura de banda: a quantidade total de informao que pode ser transmitida sobre uma rede de
um dado tempo.
Jitter: variao em tempo para entregar uma srie de mensagens.

2.2.2 Modelo de falha

A operao correta de um sistema distribudo ameaada quando ocorre uma falha em qualquer um dos
computadores em que ele executado (incluindo falhas de software) ou na rede que os interliga. O modelo
de falhas define e classifica as falhas. Isso fornece uma base para a anlise de seus efeitos em potencial e
para projetar sistemas capazes de tolerar certos tipos de falhas e de continuar funcionando corretamente.

Falhas por omisso: se referem aos casos em que um processo ou canal de comunicao deixa de
executar as aes que deveria. Por exemplo: falhas por omisso de processo ou na comunicao.
Falhas arbitrrias: aquela em que ele omite arbitrariamente passos desejados do processamento
ou efetua processamento indesejado. Portanto, s falhas arbitrrias no podem ser detectadas
verificando-se se o processo responde s invocaes, pois ele poderia omitir arbitrariamente a
resposta.
Falhas de temporizao: so aplicveis aos sistemas distribudos sncronos em que limites so
estabelecidos para o tempo de execuo do processo, para o tempo de entrega de mensagens e para
a taxa de desvio do relgio.

2.2.3 Modelo de segurana

O modelo de segurana define e classifica as formas que tais ataques podem assumir, dando uma base para
anlise das possveis ameaas a um sistema e, assim, guiando seu desenvolvimento de forma a ser capaz de
resistir a eles. A segurana de um sistema distribudo pode ser obtida tornando seguros os processos e os
canais usados por suas interaes e protegendo contra acesso no autorizado os objetos que encapsulam.

Canais de comunicao devem ser seguros quanto a escuta secreta e interferncia de contedo
Servidores devem poder verificar a identidade de seus clientes
Clientes devem poder verificar a autenticidade de servidores
A identidade do originador de uma mensagem deve poder ser verificada aps o envio da mensagem

Mtodos para garantir a segurana em sistemas distribudos:

Criptografia para permitir que um par de processos possa estabelecer um canal de comunicao
seguro baseado em uma chave.
Servio de autenticao para permitir que clientes e servidores possam fornecer, uns aos outros,
evidncias convincentes de suas identidades.

3 Padres de Projetos Middleware

3.1 Requestor
A invocao de objetos remotos exige que os parmetros de funcionamento sejam coletados e empacotados
em um fluxo de bytes, uma vez que as redes apenas permitam fluxos de bytes a serem enviados. Uma
conexo tambm precisa ser estabelecida e as informaes requisitadas so enviadas para o objeto remoto
alvo. Essas tarefas devem ser realizadas para cada objeto remoto acessado pelo cliente, e pode, portanto,
tornar-se tediosa para os desenvolvedores de clientes. Os clientes precisam realizar muitas operaes
recorrentes para cada invocao. Incluindo marshaling (empacotamento) de informaes invocadas,
gerenciamento da rede de conexo, a transmisso real de chamadas remotas atravs da rede, manipulao
do resultado de uma invocao e a manipulao dos erros.
Portanto, na aplicao do cliente utilizado o Requestor para acessar o objeto remoto. O Requestor
fornecido com a referncia do objeto absoluto, o nome da operao e seus argumentos. Ele constri uma
invocao remota a partir desses parmetros e envia a chamada para o objeto remoto. O Requestor esconde
os detalhes do lado do cliente em relao ao lado dos objetos distribudos. Para chamar uma operao de
um objeto remoto, o cliente passa os dados necessrios para invocar a operao para o solicitante, que em
seguida, envia est invocao atravs da rede para o objeto remoto. Ele lida com os detalhes de atravessar
o processo.
O Requestor, aceita parmetros passados a ele pelo cliente. E ento delega as tarefas de marshaling
(empacotamento) e de-marshaling (desempacotamento) de parmetros para o Marshaller. Em seguida, ele
comea a enviar o pedido e receber a resposta usando o Cliente Request Handler. Se necessrio, ele aciona
Invocation Interceptors.
O Requestor independente dos detalhes especficos de objetos remotos, tais como o tipo do objeto remoto
ou a assinatura da operao, tal como definido pela Interface Description. Ele constri invocaes
dinamicamente a partir da informao recebida do cliente. Para garantir segurana, abstraes estaticamente
tipadas, como os fornecidos por Cliente Proxy so utilizadas. Internamente eles utilizam o construtor de
invocao dinmica fornecido pelo Requestor. Uma vez que a interface de objeto remoto pode mudar sem
o Cliente Proxy perceber, a segurana minimizada, mas no completamente. Os tipos incompatveis e
falhas de despachos no lado do servidor so comunicados aos clientes pelo Requestor usando Remoting
Errors.

3.2 Cliente Proxy

Fornecer um Client Proxy para o desenvolvedor cliente que suporte a mesma interface que o objeto remoto.
Para invocaes remotas, clientes apenas interagem com o Client Proxy local. O Client Proxy traduz a
invocao local em parmetros para o Requestor, e desencadeia a invocao. O Client Proxy recebe o
resultado do Requestor e entrega ao cliente usando um valor de retorno comum.
O Client Proxy usa um Requestor para construir e enviar invocaes em toda a rede. Como o Client Proxy
especifico para o tipo de um objeto remoto, ele normalmente gerado a partir da interface de descrio
do objeto remoto.
Para estar disponvel no lado do cliente, o Client Proxy tem que ser implantado para o cliente de alguma
forma. No caso mais simples, o cdigo fonte do Cliente Proxy compilado com a aplicao cliente. Isto
tem a complicao que a cada mudana da implementao do Client Proxy, o cliente teria de ser
recompilados tambm. O cliente no deveria ter que mudar necessariamente por causa de qualquer mudana
no Client Proxy.
A distribuio de Client Proxies tambm pode ser feita como parte de uma pesquisa de processo. Este tem
a vantagem de Client Proxies podem ser trocados de modo transparente. s vezes isso necessrio nos
casos em que o Client Proxy participa de politicas de balanceamento de carga. O lado negativo desta
abordagem est na responsabilidade de entivar implementaes de Client Proxy em toda rede. Isto pode ser
evitado baixando ou enviando apenas a Interface Description para o cliente, o cliente gerando o Proxy de
ligao tardia do cliente a partir dessa interface em runtime.
Em alguns casos, at mesmo as interfaces de objetos remotos mudam durante o runtime. Tais alteraes
podem ser tratadas no lado do servidor apenas, para exemplo, no Invoker. Contudo, se isto no possvel
e o cliente precisa se alinhar com a mudana de interface, o uso do Client Proxy deve ser evitada, e os
clientes devem usar o solicitante diretamente para a construo de invocaes remotas de forma dinmica.
Ao fornecer diretamente a interface do objeto remoto e pelo que representa um objeto remoto especifico
diretamente no processo do cliente, um Client Proxy tipicamente mais fcil de usar do que um solicitante,
especialmente para desenvolvedores inexperientes.
No entanto, a consequncia que um Client Proxy menos flexvel que o Requestor. Porque um Client
Proxy usa um Requestor internamente, a soluo (um pouco) mais lenta e consome mais memria do que
a pura soluo do Requestor.

3.3 Invoker
O Requestor envia pedidos atravs da rede, contendo o ID do objeto remoto, nome da operao, parmetros
da operao, bem como outras informaes contextuais. O Invoker l os pedidos e demarshals
(desempacota) para obter o objeto com o ID em procura e o nome da operao. Em seguida, ele procura o
objeto local correto e sua implementao na operao, tal como descrito pela invocao remota, por fim
invoca-o.
O Invoker est localizado no lado do servidor dentro do processo do servidor de aplicao. Dependendo do
configurado Configuration Group, um ou mais instancias Invoker existem, j que ambos os conceitos so
relacionados. Um Server Request Handler associado trata do nvel mais baixo de comunicao. Isto inclui
a recepo de mensagens remotas, gerenciamento de threads, agrupamento de ligaes, bem como envio
de receptores.
Quando um pedido de mensagem foi recebido totalmente pelo Server Request Handler, o mesmo entrega a
invocao, contida na mensagem, para o Invoker. No caso de mltiplas solicitaes, a mensagem deve
conter informaes suficientes para permitir que o Server Request Handler entre em contato com o Invoker
correto. A mensagem portanto deve conter informaes sobre o Invoker, tal como nome do Invoker, ou ID.
Se necessrio, o ID Ivoker deve fazer parte do Absolute Object Reference.
Se ainda no tiver feito, o Invoker desempacota ainda mais a mensagem de solicitao para identificar o
objeto remoto alvo, o nome e os parmetros de operao. O verdadeiro demarshaling tratado por um
separador padro, o Marshaller.
Caso o objeto remoto no puder ser encontrado pelo Invoker, o Invoker pode delegar despachar a um
Location Forwarder. O Location Forwarder pode ser capaz de delegar para um objeto remoto em outro
servidor de aplicao. Essas abordagens so utilizadas nos casos em que objetos remotos foram movidos,
ou quando a carga equilibrada em vrios objetos remotos.
O Invoker no lado do servidor e o Requestor no lado do cliente tem que ser compatvel em respeito as
mensagens trocadas entre si. O Requestor tem que colocar todas as informaes exigidas pelo Invoker em
uma mensagem de solicitao, e o Invoker tem que enviar a resposta.
Usando um Invoker em vez de conexes de rede direta para objetos remotos reduz o nmero de entidades
endereveis de rede necessris. Ele tambm permite que o Server Request Handler eficientemente
compartilhe conexes para servidores que hospedam vrios objetos remotos.

3.4 Client Request Handler

O Client Request Handler responsvel por abrir e fechar as conexes de rede para aplicativos de servidor,
envio de pedidos, recebimento de respostas e envio de retorno para o Requestor apropriado. Alm disso, o
Client Request Handler lida com o tempo de espera e erros de invocao.
responsvel pela manipulao da rede dentro das aplicaes do cliente. Um identificador de conexo
usado para identificar as conexes e associar um Requestor. Tipicamente uma ligao a um servidor e a
uma porta de do servidor pode ser compartilhada com outras invocaes enviadas para o mesmo servidor
de aplicao. A tarefa real de envio da invocao de dados, especialmente em vrios contextos de
protocolos disponveis, feita usando o Protocol Plug-in.
O trabalho do Client Request Handler garantir a escalabilidade. Tem que ser concebida de tal maneira
que ele manipula concomitante solues de forma eficiente. Para fazer isso, o reator [SSRB00] padro
utilizado para desmultiplexar e enviar a mensagem de resposta. Um reator utiliza o identificador de conexo
para notificar os responsvel sobre o resultado disponvel. O resultado pode ser tratado da seguinte forma,
sncrona ou assncrona.

No caso de chamadas sncronas, o Client Request Handler tem que esperar o resultado da chamada.
Ou seja, ele bloqueado at que o resultado tenha chagado.
Para chamadas assncronas o Requestor e Client Request Handler tem que seguir um dos padres
de assncrona. No caso de um Result CallBack ou Pool Object respectivamente, ele despacha o
resultado para um objeto callback Poll Object respectivamente, em vez de entregar o resultado de
volta para a invocao do cliente sobre a pilha de chamadas.

Quando so lanados eventos timeouts, o Client Request Handler informa ao Requestor sobre tais eventos.
Para este efeito, o Cliente Request Handler registra para um timeout quando a invocao enviada para um
objeto remoto. Se a resposta no chegar dentro do perodo timeout, o Client Request Handler recebe o
evento de timeout e informa ao Requestor. Dependendo da configurao pode tentar , novamente, o envio
da uma invocao antes de levantar o erro Remoting Error. O Client Request Handler tambm deve detectar
outras condies de erro, tal como uma rede disponvel ou servidor de aplicao. Neste caso, ele tem que
levantar um Remoting Error e encaminhar para o Requestor.
Para muitas tarefas, Client e Server Client Handler tem que trabalhar em conjunto, especialmente para as
extenses de manipulao da solicitao como Invocation Interceptors, Invocation Constexts, Protocol
Plug-ins, ou outros servios. O Client Request Handler normalmente compartilhado entre mltiplos
Requestors. Cliente Request Handler esconde a conexo e a manipulao de mensagens complexas dos
Requestors.

3.5 Server Request Handler

O Server Request Handler lida com toda questo de comunicao do servidor de aplicao. Ele recebe
mensagens da rede, combina os fragmentos da mensagem para completa-las e despacha as mensagens para
o Invoker correto e posterior processamento. O Server Request Handler gerencia todos os recursos
necessrios como conexes e threads.
O Server Request Handler lida com mensagens, como elas so enviadas e recebidas atravs da rede,
enquanto que o Invoker lida com pedidos (requests) e como eles so expedidos e invocados. Quando
mltiplos Invokers esto presentes, o Server Request Handler desmarchals (desempacota) as mensagens at
o ponto em que decide que o Invoker enviar a mensagem.
Em alguns cenrios de aplicao, pode ser esperado que um cliente possa comunicar-se repetidamente com
objetos remotos no mesmo servidor de aplicao, enquanto que em outro cenrio isso pode no ser o caso.
Tm estratgias, diferentes para estabelecimentos de conexo. Por exemplo, uma nova ligao pode ser
aberta e fechada para cada mensagem enviada atravs da rede. De forma alternativa, a ligao pode ser
mantida aberta para um tempo especifico e depois reutilizada para ser mantida aberta por um tempo
especfico e por fim reutilizada para invocaes subsequentes. O ltimo tem a vantagem de evitar a
sobrecarga de estabelecer e destruir conexes para pedidos repetidos do cliente. No entanto, as conexes
que so mantidas abertas consomem recursos. A estratgia de estabelecimento de conexo do servidor de
aplicao executado pelo Server Request Handler.
Uma importante consequncia no uso do Server Request Handler que as redes de baixo nvel so
centralizadas em um nico sistema componente. Pools de conexo e de thread permitem que o Server
Request Handler seja altamente concorrente, evitando o risco de bloqueios.
Observe que existem algumas reas de aplicao em que vrias instncias Server Request Handler so teis,
como o caso da ligao direta de objetos remotos para portas de rede. Por exemplo, se h apenas alguns
objetos remotos, mas eles exigem alto desempenho, isso resulta em diferentes configuraes de canais de
comunicao e configuraes de simultaneidade para objeto remoto. difcil lidar com esse cenrio de
forma centralizada, utilizando apenas um Server Request Handler.

3.6 Marshaller
Use Marshallers compativeis no lado do cliente e servidor que serialize as informaes invocadas.
Dependendo do ambiente, a serializao pode ser fornecida pelos prprios tipos de dados. As referncias a
objetos remotos so serializados como Absolute Object References. Um Marshaller converte invocaes
remotas em fluxos de bytes. Ele fornece um mecanismo genrico que no especifico para qualquer
determinado tipo de objeto remoto.
O Requestor, Invoker e Request Handlers usam o Marshaller para recuperar as informaes de invocao
contidas no fluxo da mensagem de byte. Para os tipos de dados complexos Marshaller l recursivamente
sua hierarquia de tipos. Identidades dos objetos so tratadas como tipos de dados especiais, mas so
empacotados de uma maneira similar aos tipos de dados complexos. As referncias a outros objetos remotos
so convertidas em Absolute Object References.
Objeto local que contm muitos elementos de dados usados pelo objeto remoto invocado no deve ser
referenciado remotamente, mas empacotado por valor, porque consultando os dados nesses objetos
remotamente provavelmente requerem uma srie de invocaes remotas subsequentes, desperdiando rede
e baixo desempenho. Um formato de transporte genrico necessrio para transportar algum tipo de dados
atravs da rede. A serializao de um tipo complexo pode ser realizada de vrias formas:

A linguagem de programao pode fornecer um tipo genrico, para facilitar a serializao. Este
o caso das linguagens Java ou .NET que podem usar Reflection para serializao estrutural dos
tipos.
As ferramentas podem ser usadas para gerar o cdigo de serializao diretamente a partir da
Interface Description, supondo que a estrutura de tais tipos est expressa na Interface Description.
Os desenvolvedores podem ter que fornecer funcionalidades de serializao. Neste caso, o
desenvolvedor geralmente tem de implementar uma interface adequada que declara operaes de
serializao e desserializao.

O formato concreto dos dados dentro de um fluxo de bytes depende do middleware de objetos distribudos
usado. Tudo um fluxo de bytes quando so transportados para toda a rede. Para representar estruturas de
dados complexas, aconselhvel a utilizao de um formato estruturado, como XML e CDR.
Um formato de marshaling genrico nunca pode ser o ideal para todas as estruturas de dados ou cenrios.
Dependendo do caso de uso, alguns formatos de serializao so melhores que outros. XML ideal para
vrios casos, mas muito ineficiente no que diz respeito ao uso de largura de banda para alguns domnios,
tais como o domnio de sistemas embarcados. CDR um formato binrio e padronizado, o que significa
que muitas ferramentas esto disponveis para seu uso.

3.7 Interface Description

A Interface Description serve como o contrato entre Client Proxy e Invoker. Ambos utilizam tanto tcnicas
de gerao de cdigo ou de configurao de tempo de execuo para aderir a esse contrato. Usando a
Interface Description em um arquivo separado, um gerador de cdigo gera um cdigo para o Client Proxy
e Invoker. O Client Proxy utilizado pelo cliente adere a um mesmo contrato como o Invoker, que despacha
a invocao ao objeto remoto. Desta forma, os detalhes necessrios para garantir a segurana de tipos esto
escondidos do cliente e os objetos remotos.
Normalmente, uma Interface Description contm especificaes de interface que incluem suas operaes e
assinaturas, bem como a definio de tipos complexos definidos pelo usurio. A descrio de interface em
si pode existir em vrias formas:

Linguagem de definio de interface: a Interface Description separada do texto do programa, por

exemplo, em um arquivo fornecido pelo objeto remoto. Uma linguagem de definio de interface
define a sintaxe e semntica das declaraes.
Repositrio de interface: A Interface Descripton fornecida aos clientes em tempo de execuo
usando um repositrio de interface exposto pelo aplicativo de servidor, ou alguma outra entidade.
O repositrio de interface usado para a construo de Client Proxies em tempo de compilao,
assim como na variante de linguagem de descrio de interface acima. Alm disso, um repositrio
de interface pode ser utilizado para chamadas dinamicamente construdas, a fornecer informaes
sobre a interface remotamente acessvel em tempo de execuo. O Invoker tem opes
semelhantes.
Interfaces de reflexo: a Interface Description fornecida por meio de reflexo, seja oferecida,
atravs da linguagem de programao do lado do servidor ou usando o padro de reflexo. Para
os clientes ao fazer uso de reflexo, o aplicativo do servidor tem que fornecer alguns meios para
permitir que essa informao seja consultada remotamente.

Em Middleware de objetos distribudos que suporta mais de uma linguagem de programao, as Interface
Description devem ser disponibilizada em uma sintaxe independente da linguagem de programao. Isso
requer ferramentas que traduzam a Interface Description em diferentes linguagens. Interface Description
so um meio importante para a construo de sistemas distribudos interoperveis. O objeto middleware
distribudo fornece ligao de uma lngua, alm das descries de interfaces, para definir regras de
converso de genricas para/de uma linguagem de programao.

3.8 Remoting Error

REFERENCIAS
Sistemas Distribudos - Conceitos e Projeto - 5 Ed. 2013 - George Coulouris, Tim Kindberg, Jean
Dollimore
Sistemas Distribudos - Princpios e Paradgmas - 2 Ed. 2008 - Tanenbaum, AndrewVan Steen, Maarten
Silberchatz, Abraham. Operation System Concepts. 5 eth AddisonWesley. November 1998.