Aquiles Burlamaqui
Luiz Eduardo
 Agenda
• Motivação
• História
• Objetivo
• Elementos
• Passo a Passo
 Motivação:
• Dificuldade em programar para Ambientes
distribuídos
• Desvantagem do socket
• Foco na aplicação
 História
• 1976 – Descrito na RFC 707
• 1981 – Uso Comercial Xerox
• Sun’s RPC para Unix(ONC RPC) – base para o
Sun NFS
• DCE/RPC para Unix, usada pela OSF
• Microsoft RPC adota o DCE/RPC
 Objetivo
• Tornar fácil a implementação de aplicações
distribuídas
• Permitir chamada de procedimento remoto
como se fosse local



Um processo A chama um procedimento p de um processo B,
entrando em estado de espera
O processo B passa a executar o procedimento p, e ao seu término
faz um reply para o processo A
O processo A volta à sua execução normal após ter recebido o
reply
 Dados
em programas são estruturados
enquanto que mensagens carregam
informação sequencial:
» Linearização/Restauração de dados
 Heterogeneidade
na representação de dados
em computadores:
» Uso de um formato externo comum
» Inclusão de uma identificação de arquitetura na
mensagem
 Marshalling:
• Linearização de uma coleção de itens de dados
estruturados
• Tradução dos dados em formato externo
 Unmarshalling:
• Tradução do formato externo para o local
• Restauração dos itens de dados de acordo com
sua estrutura
 Esconde
o código das chamadas a rede
em procedimentos chamados stubs.
• Stubs – procedimentos que contem código de
chamadas de rede
• Esconde detalhes como socket.
• XDR ( External Data Representation ) – padrão
IETF, RFC 4506
• RPCGEN é uma ferramenta utilizada para gerar
os stubs.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Criar aplicação convencional
Dividir o programa em duas partes
Criar uma especificação rpcgen
Executar o rpcgen
Criar servidor
Criar cliente
Compilar cliente
Compilar servidor
Executar servidor e cliente
 Rpcgen
IDL
Número do procedimento
Versão
Número do programa



Client stub
• intercepta a chamada
• empacota os parâmetros (marshalling)
• envia mensagem de request ao servidor
Server stub
• recebe a mensagem de request
• desempacota os parâmetros (unmarshalling)
• chama o procedimento, passando os parâmetros
• empacota o resultado
• envia mensagem de reply ao cliente
Client stub
• recebe a mensagem de reply
• desempacota o resultado
• passa o resultado para o cliente
Máquina do Cliente
0
1
cliente
11
Máquina do Servidor
2
empacota
parâmetros
4
desempacota
parâmetros
desempacota
resultados
10
empacota
resultados
8
Kernel
5
6
servidor
7
Kernel
3
9
transporte de mensagens
via rede
O
cliente não é capaz de localizar o servidor
 A mensagem de request do cliente para o
servidor é perdida
 A mensagem de reply do servidor para o
cliente é perdida
 O servidor pára após ter recebido a mensagem
de request
 O cliente pára após ter enviado a mensagem
de request
 Causas
• Servidor está fora do ar
• Cliente está usando versão antiga do servidor
 Soluções
• Variáveis com código de retorno indicando erro
• Exceções
 Causa
• Problema na rede
 Soluções
• Temporização para chegada da resposta ou
mensagem de reconhecimento
• Tempo expira – retransmissão da mensagem
 Causa
• Perda da solicitação
• Perda da resposta
• Servidor
 Soluções
• Fácil de tratar quando a operação é idempotente
• Atribuir número sequencial as solicitações
 Uma
maneira de fazer comunicação em
sistemas distribuídos de uma forma
transparente.
 Proposta por Birrel e Nelson em 1984.
• Birrell & Nelson 1984: A. D. Birrell and B. J. Nelson. ``Implementing
remote procedure calls.'' ACM Transactions on Computer Systems,
2(1):39-59
 Um
procedimento numa máquina A chama um
procedimento numa máquina B.
 Para o programador, tudo se parece como se os
dois procedimentos fizessem parte do mesmo
programa.
O
sistema (middleware) se encarrega da
comunicação entre as máquinas.
 Implementação popular: Sun rpcgen
desenvolvido no final dos anos 80.
 Desenvolvimentos da idéia de RPC:
• CORBA
• Java RMI
• DCOM
 Motivação
• Problemas com o RPC
 Necessidade de aprender uma linguagem IDL
 Suporte limitado para tipos de dados
 Fortalecimento das linguagens Orientadas a Objetos
 API
Java que permite a execução de chamadas
remotas no estilo RPC
 Permite objetos Java invocar
transparentemente métodos de outros objetos
(que podem estar em máquinas diferentes –
objetos remotos)
 Java RMI libera o programador de tratar de
detalhes como endereçamento e codificação/
decodificação de mensagens
 Seria
impraticável se para cada invocação de
método remoto fosse necessário incluir o par
(máquina,porta) para identificar onde se
encontra o objeto que contém o método
 RMI oferece um Serviço de Nomes (RMI
Registry) que oferece informações sobre a
localização de objetos remotos.
 rmiregistry executa em um endereço bem
conhecido.
ref_obj
Naming.lookup(“rmi://natalnet.br/servobjA”)
RMI Registry
Servidor
O
modelo RMI:
• O servidor define objetos que o cliente pode
usar remotamente
• Os clientes podem invocar métodos nesse
objeto remoto como se ele estivesse executando
localmente.
• RMI esconde o mecanismo subjacente de
transporte, via rede, de argumentos dos métodos
e valores de retorno.
 Definir
uma interface que declara os
métodos remotos
 O programa servidor
• deve incluir uma class que implementa essa
interface.
• deve criar um objeto remoto e registrá-lo no
serviço de nomes (rmi register)
O
programa cliente
• deve perguntar ao serviço de nomes pela
referência do objeto remoto.– deve invocar o
método sobre o objeto remoto
 Interface
• Similar a classe
• Não há implementação, apenas declaração de
métodos
 Tudo é público
 É uma API que pode ser implementada por uma
classe
 Servidor
• A interface definida pelo servidor deve declarar
que os métodos da interface serão invocados
por clientes remotos
• A interface deve estender a interface Java
Remote que o pacote java.rmi oferece
 Criar
uma classe que implementa a interface. A
classe deve estender UnicastRemoteObject
 O código main() deve:
• Criar um objeto remoto
• Registrar esse objeto no serviço de Nomes
A
classe precisa definir um construtor para
RemoteException !
 A classe será usada pelo compilador rmic
paracriar o código do stub e do skeleton.
 Uma
aplicação RMI distribuída usa o
"rmiregistry" para obter uma referência
ao objeto remoto.
1.
2.
3.
Defina a interface do servidor (estendendo a
interface java.rmi.remote)
Escreva o código do servidor que implementa a
interface (herdando da classe
java.rmi.UnicastRemoteObject)
Compile o servidor
1.
2.
4.
5.
Use o compilador javac para produzir o arquivo .class
Execute o compilador rmic para obter o stub e skeleton
Execute o programa servidor (o rmiregister tem de
estar executando antes)
Execute o cliente
 1)
Construir dois exemplos simples que
utilizem cada uma das tecnologias vistas
em aula(RPC e RMI)
• Com base na experiência adquirida fazer um
comparativo entre eles.
 http://en.wikipedia.org/wiki/Remote_pr
ocedure_call
 http://www.dimap.ufrn.br/~thais/
 www.ppgia.pucpr.br/~alcides
 www.cin.ufpe.br/~if677
 virtual01.lncc.br/~licht
 http://www.cs.cf.ac.uk/Dave/C/node33.
html