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 inter-

relacionamentos 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.