Semântica de Invocação

Propaganda
Comunicação Inter-Processos
-> RMI
-> RPC
-> TCP
-> UDP (Abstração de passagem de mensagem)
1
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
2
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 reexecução da operação
Não
Não Aplicável
Não Aplicável
Talvez
Sim
Não
Re-execução da
operação
Ao menos uma
vez
(operações
idempotentes)
Sim
Sim
Retransmitir resultado
No máximo
uma vez
3
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.
4
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.
5
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.
6
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.
7
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.
8
Download