Comunicação Inter-Processos

Apresentação em tema: "Comunicação Inter-Processos"— Transcrição da apresentação:

1 Comunicação Inter-Processos
-> RMI -> RPC -> TCP -> UDP (Abstração de passagem de mensagem)

2 Características de Projeto para RMI
. Semântica de Invocação de RMI . Transparência da RMI -> Semântica de Invocação: Trata das diferentes formas de entrega das mensagens . Problemas a serem tratados: Retransmitir Mensagem de Requisição? Quando retransmissões são feitas, deve-se filtrar requisições duplicadas Retransmissão de resultados

3 Semântica de Invocação
Medidas de Tolerância à Falhas Semântica de Invocação Retransmissão da mensagem de requisição Filtrar Duplicatas Retransmissão de resultado ou re-execução da operação Não Não Aplicável Talvez Sim Re-execução da operação Ao menos uma vez (operações idempotentes) Retransmitir resultado No máximo uma vez

4 Transparência em RMI . Sintaxe para RMI deve ser diferente (sistema Argus) ou não (Java RMI e Corba)? . Qual semântica de invocação usar? O concenso atual é de que as invocações remotas devem ser transparentes em termos de sintaxe, mas a diferença entre objetos remotos e locais deve ser expressada em suas interfaces. Em Java RMI um objeto remoto deve implementar a interface Remote e deve lançar RemoteExceptions. . O conhecimento de que um objeto será acessado através de invocação remota tem outra implicação para o programador/projetista: este objeto deve manter seu estado consistente na presença de acesso concorrente por parte de múltiplos objetos.

5 . Módulo de Referência Remota
Implementação de RMI . Módulo de Comunicação Responsável pela troca de mensagens de request/reply (implementação da semântica de invocação) . Módulo de Referência Remota Armazena as referências de objetos remotos com a tradução para os objetos proxy.

6 O Software RMI . Proxy: É a representação local de um objeto remoto. Seu papel é tornar transparente a invocação remota de método. Fica com o cliente. Também chamado de Stub. Esconde os detalhes da referência de objeto remoto, enpacotamento e desempacotamento de resultados e referência de objeto remoto. . Dispatcher: O servidor tem um dispatcher e skeleton para cada classe representando um objeto remoto. O dispatcher recebe a mensagem de requisição do módulo de comunicação, seleciona o método apropriado no skeleton passando-o para o objeto implementado pelo servidor. . Skeleton: A classe de um objeto remoto tem um skeleton, que implementa os métodos da interface remota. Ele desempacota os argumentos da mensagem de requisição, invoca o método correspondente no objeto remoto. Aguarda a invocação completar e então empacota o resultado com as possíveis exceções, em uma mensagem de resposta para o proxy.

7 Geração de Classes para Proxies, Dispatchers e Skeletons
. São geradas automaticamente por um compilador de interface. . Em CORBA IDL pode-se gerar tais classes para C++ . Em Java RMI, o conjunto de métodos oferecidos por um objeto remoto é definido como uma interface Java, que deve ser implementada na classe do objeto remoto. O compilador Java RMI gera o proxy, dispatcher e skeleton.

8 Cliente e Servidor e Binder
. Servidor conterá o objeto remoto, skeleton e dispatcher. Deverá ter uma seção de inicialização responsável por instanciar o objeto remoto e registrá-lo no serviço de nomes. . Cliente obterá referência do objeto remoto no serviço de nomes. Deverá conter a classe do proxy. . Binder é o serviço de nomes do RMI. É responsável por registrar os objetos remotos do servidor para disponbilizá-los aos clientes tornando transparente a localização dos objetos remotos.