RMI (Remote Method Invocation)

 

Modelo RPC

 

O modelo RPc da Sun é baseado no modelo de chamada de procedimento remota, que por sua vez é similar ao modelo de chamada de procedimento local. No caso local, o objeto que realiza a chamada coloca os argumentos para o procedimento em uma localização específica. Então o controle é transferido ao procedimento e depois eventualmente ele ganha o controle novamente. Nesse ponto, os resultados do procedimento são extraídos da localização específica e o objeto continua sua execução.

O modelo de chamada a procedimento remoto é semelhante. Um thread de controle passa por dois processos. O processo que executa a chamada primeiro envia uma mensagem ao processo servidor e então espera por um mensagem de resposta. A mensagem de chamada inclui os parâmetros do procedimento e a mensagem de resposta inclui os resultados da chamada. Quando a resposta é recebida, os resultados são extraídos da mensagem e o processo que executou a chamada continua sua execução.

Do lado do servidor, existe um processo adormecido esperando por uma mensagem de chamada. Quando ela chega, o processo servidor extrai os parâmetros do procedimento, calcula os resultados, envia uma mensagem de resposta e volta a ficar adormecido esperando por outra mensagem de chamada.

Vale lembrar que a descrição acima é apenas uma das posssibilidades de implementação do modelo RPC, tendo em vista que o modelo RPc da Sun não faz restrições a outros modelos que apresentam a mesma funcionalidade. Por exemplo, em uma implementação as chamadas RPC podem ser assincronas, ou seja, o cliente pode executar outras tarefas enquanto espera pela resposta do servidor, outra possibilidade seria o servidor criar um processo separado só para processar as chamadas dos clientes, logo o servidor original ficaria livre para receber outras chamadas.

Existem algumas diferenças importantes entre os procedimentos locais e remotos, e esta são:

  • Tratamento de erros - falhas ocorridas no servidor remoto ou na rede devem ser tratadas.
  • Variáveis Globais e Efeitos Colaterais - tendo em vista que o servidor não tem acesso ao faixa de endereços do cliente, argumentos escondidos não podem ser passados como variáveis globais ou retonardos como efeitos colaterais.
  • Performance - procedimentos remotos em geral operam em velocidades algumas ordens de magnitude menores que chamadas a procedimentos locais.
  • Autenticação - a autenticação se faz necessária tendo em vista que chamadas a procedimentos remotos trafegam em redes inseguras.

A conclusão é que apesar de existirem ferramentas para automatizar a criação de bibliotecas de clientes e servidores para um determinado serviço, os protocolos devem ser projetados com muito cuidado e sempre observando as considerações acima.

 


[ Índice | Introdução | Modelo RPC | Funcionamento | Serialização ]
[ "Stubs" e "Skeletons" | Ativação | Segurança | Aplicações | Referências ]