0070-rmi-rpc.ppt [modo de compatibilidade]tacla/espsd/aula4/0070-rmi-rpc.pdf · corba 2 b. jrmi c....

COMUNICAÇÃO INTER-PROCESSOSJAVA RMI e RPC

Prof. Cesar Augusto Tacla

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁPR

11Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla

Prof. Cesar Augusto Taclahttp://www.dainf.ct.utfpr.edu.br/~tacla

◊ 1. Conceitos Básicos� a. Invocação remota (RPC/RMI)� b. Semântica de invocação remota� c. Invocação remota de métodos (RMI)

◊ 2. Implementações de RMI/RPC� a. CORBA

22

� a. CORBA� b. JRMI� c. Referência a objeto remoto� d. Formato da mensagem de REQUEST-REPLY� e. Protocolo REQUEST-REPLY

Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla

Sumário

CONCEITOS BÁSICOS

1


Invocação Remota RPC/RMI

1 A


COMUNICAÇÃO INTERPROCESSOS DISTRIBUÍDOS

Processo

Modelos de invocação de operações remotas baseiam-se nos modelos locais:

• Procedural: Chamada de funções ⇒ chamada remota de funções (RPC)

• OO: Invocação de métodos ⇒ invocação remota de métodos (RMI)


Processo

ProcessoProcesso

Quem garante esta transparência?

Invocar função ou método

MIDDLEWARE

◊ RMI (JRMI), RPC, CORBA� provêm transparência de localização

◊ Invocação transparente de procedure/método� Transparente até certo ponto,

semântica invocação remota ≠ local


HARDWARE

PROTOCOLOSSIST. OPER.

MIDDLEWARE

APLICAÇÃO DISTRIBUÍDA

HARDWARE

PROTOCOLOSSIST. OPER.

PLATAFORMA

RMIRPCCORBA

sockets

Sumário

Semântica de invocação remota (RPC/RMI)

1 b


pular

SEMÂNTICA DA INVOCAÇÃO REMOTA

◊ Invocações remotas podem falhar!

◊ Opções de tratamento

Retransmitir Request

Filtrar requests Duplicados

Re-executar ou retransmitir resp.

Exceção OK


resp.

UM TIRO NÃO --x-- --x-- 0 ou 1 1

PELO -1 SIM NÃO RE-EXECUTAR 0 ou + 1 ou +

MÁX 1 SIM SIM RETRANSMITIR 0 ou 1 1

A coluna semântica devem ser interpretada do seguinte modo:Exceção: ao receber um erro, o método invocado foi executado ... vez(es)OK : ao receber um ok, o método invocado foi executado ... vez(es)


◊ UM TIRO� Ao receber uma resposta, o invocador tem certeza que o método

remoto foi executado somente uma vez� Ao receber exceção (resposta não chegou, logo timeout), o

invocador não saberá se o método foi executado ou não, pois:

� Falha do servidor


� Falha do servidor� Request chega, mas servidor cai antes ou durante a execução do

método (0)� Request chega, servidor executa o método e falha em seguida (1)

� Falha no canal de comunicação� Request não chega no servidor (0)� Resposta não chega: servidor executa o método, envia resposta,

mas resposta não chega no cliente ou chega depois do timeout (1)

SEMÂNTICA DA INVOCAÇÃO REMOTA◊ PELO MENOS UMA (1 ou +)

� Ao receber uma resposta, o invocador sabe que o método remoto foi executado ao menos uma vez, pois:

� Falha do canal de comunicação� Request chega, servidor executa o método e envia resposta.� Resposta não chega, request é retransmitido� Servidor executa o método e envia resposta, ... até que a resposta chegue! (1 ou +)

� Ao receber exceção, o invocador não saberá se o método foi executado ou não, pois:


pois:

� Falha do servidor� Request chega, mas servidor cai antes ou durante a execução do método,

retransmissões do request, ..., exceção! (0)� Request chega, servidor executa o método e falha em seguida, retransmissões do

request, ..., exceção! (1)

� Falha no canal de comunicação� Request não chega no servidor, retransmissões do request, ..., exceção! (0)� Resposta não chega: servidor executa o método, envia resposta, mas resposta não

chega no cliente, retransmissão do request, servidor executa método, envia resposta, mas resposta não chega ... exceção! (1 ou +)


◊ NO MÁXIMO UMA (0 ou 1)� Ao receber uma resposta, o invocador sabe que o método foi executado

uma só vez, pois:

� Falha do canal de comunicação� Request chega no servidor� Servidor executa o método� Servidor envia resposta. � Resposta não chega...� Retransmissão do request


� Retransmissão do request� Servidor detecta que o request já foi executado e retorna a resposta com

resultado anterior� Se a resposta chegar no cliente

� Método terá sido executado uma só vez� Se não

� Após um certo número de retransmissões, uma exceção será gerada

� Ao receber exceção, o invocador sabe que o método não foi executado ou foi executado somente uma vez

� Semântica utilizada em JRMI e CORBA

Sumário

Remote Method Invocation (RMI)

1 c


REMOTE METHOD INVOCATION: RMI

Invocaçãoremota

remote

local

local

localA B

C

D

E

F

objetoObjeto remoto


◊ Invocação remota de métodos = RMI

◊ Objeto remoto: pode ser invocado a distância (ex. B)

(Coulouris et al., 2001)

INTERFACE REMOTA

Invocaçãoremota

A

métodos

dados

B

métodos

dados

métodos

dados


métodos

Método 1Método 2Método 3

Interface remota de B

separação entre interface e implementação

métodos

EXEMPLO DE DECLARAÇÃO INTERFACE

◊ IDL (CORBA)� c-like

module banco {

enum TipoConta{CORRENTE,POUPANCA

};

struct Conta { tipos


Método 1Método 2Método 3

Interface remota de B

struct Conta {string id;string senha;TipoConta tc;

};

interface Operacao {long getSaldo(in Conta conta);void retirar(in Conta conta, in long valor);void depositar(in Conta conta, in long valor);void transferir(in Conta orig, in Conta dest, in long valor);

};};

LIMITES DA INTERFACE REMOTA

◊ Limites de uma interface(em relação ao processamento local)

� Não permite acessar diretamente variáveis de outros módulos

� Não é possível fazer passagem de argumentos por referência


� Não é possível fazer passagem de argumentos por referência� para modificar os argumentos na origem

� Ponteiros não podem ser utilizados como argumentos de chamadas

TRANSPARÊNCIA

◊ As implementações de RMI preocupam-se:� Com os limites das interfaces� Com a semântica das invocações� Com a transparência das invocações

� Fazê-las similares às invocações locais: sintaticamente e semanticamente (difícil!)


� Semântica:� Da invocação local: exatamente uma vez� Da invocação remota: várias possibilidades

� Tempo de execução de uma invocação remota é maior � A gama de exceções também é maior: falhas de comunicação,

do servidor e problemas de concorrência!

TRANSPARÊNCIA DA API

Há autores que dizem que a sintaxe das invocações remotas deve ser distinta das invocações locais para expressar claramente suas diferenças ao programador.

O programador de uma aplicação distribuída deve levar em conta:• falhas de comunicação,


• falhas de comunicação, • indisponibilidade do serviço e, também, • ter consciência que os métodos de um objeto remoto podem ser

acessados de forma concorrente levando aos problemas de race condition e falta de vivacidade.

Sumário

IMPLEMENTAÇÕES DE RMI/RPC

2


Sumário

CORBA

2 a


CORBA

◊CORBA� OMG: Object Management Group� http://www.omg.org� CORBA = Common Object Request Broker Architecture

CORBA é uma especificação (OMG) de um padrão para um ambienteheterogêneo de computação orientado a objetos distribuídos.


heterogêneo de computação orientado a objetos distribuídos.

Parte desta especificação define a IDL, Interface Definition Language. Toda implementação CORBA padrão deve suportar IDL, ou seja, implementar todas as capacidades definidas na IDL utilizando uma linguagem e uma plataforma específicas.

CORBA

◊CORBA (OMG: http://www.omg.org)

◊ Invocações remotas

◊ Heterogeneidade


◊ Heterogeneidade� Programas escritos em linguagens e/ou paradigmas diferentes� orientado a objetos ou procedurais� C, Java, C++

� Processos rodam em plataformas diferentes

FUNCIONAMENTO CORBA

CLIENTE

STUB

SERVIDOR

SKELETON

Interface IDL

<<realizes>> <<realizes>><<realizes>>


STUB

ORB

SKELETON

ORBIIOP

Internet Inter-ORB Protocol

request(un)marshall (un)marshall

IIOP: Internet Inter-ORB Protocol ORB=Object Request Broker

Sumário

JRMI

2 b


JRMI

◊ JRMI: Java Remote Method Invocation

◊ objetos distribuídos em Java

◊ Transparência� Utiliza mesma sintaxe da invocação local� Verificação de tipos de dados é idêntica a local


� Verificação de tipos de dados é idêntica a local� Não há necessidade de aprender uma IDL específica (como em CORBA)� Faz garbage collection distribuído

◊ Porém...� Há consciência (da parte do programador) que a invocação é de um

método remoto, pois ele deve:� tratar RemoteExceptions

� implementar a interface Remote

SUPORTE PARA JRMI

◊ Pacote java.rmi� API para implementação de objetos clientes, servidores e

interfaces� API para utilizar os serviços de runtime

◊ Serviços de runtime� Registro de objetos remotos (permite localizá-los)


� Registro de objetos remotos (permite localizá-los)

◊ Ferramentas� JRMI: Primeira aparição: JDK 1.1� Até JDK 1.4: compilador rmic para gerar stubs� Após: Stubs podem ser gerados automaticamente pela JVM (a partir

de JDK 1.5)

IMPLEMENTAÇÃO RMI

A: CLIENTE

métodos

dadosB1: SERV

métodos

dados

Interfaceremota

da classe Binvoca

return

return

métodos

dados

B2: SERVA tem referência de B1


STUB B1Skeleton &

Dispatcher paraa classe de B

reply requestrequest

Invoca b1.met()

reply

Módulo de comunicação


Módulo dereferência

Módulo dereferência

Request/reply Request/replyJRMP

Stub monta request(marshall)

Mapeia ref.remota<->local

MENSAGEM REQUEST-REPLY

◊ Mensagem de invocação requer referência ao objeto remoto

Tipo de mensagem

Id do request

Referência ao obj. remoto

Int (0=request 1=reply)

int

Ver adiante


Id do método

argumentos

Int ou método

Bytes (marshalled)

REFERÊNCIA A OBJETO REMOTO

◊ Quando é utilizada:� Quando um objeto invoca um método de um objeto remoto� Referências também podem ser passadas como argumentos ou

como respostas de métodos remotos

◊ Referência única no sistema distribuído� No espaço de nomes


� No espaço de nomes� No tempo (referências antigas)

32 bits 32 bits 32 bits 32 bits

IP porta Hora e data de criação

Número seqüencial

Interface

MÓDULO DE REFERÊNCIA A OBJ REMOTO

◊ Dois tipos de entrada na tabela:� Uma entrada para cada objeto

remoto do processo

� Uma entrada para cada stub local:

Ex. no lado do cliente Ex. no lado do servidor


Ex. no lado do cliente

<ref. remota de B1>, <ref. local de B1> ⇒⇒⇒⇒ referência local se refere a um stub

Ex. no lado do servidor

<ref. remota de B1>, <ref. local de B1>

<ref. remota de B2>, <ref. local de B2>

BINDER

◊ Cenário� Objeto A necessita de um serviço de B, mas não conhece a

referência remota, somente o nome de B� O objeto A pergunta a quem?


FUNCIONAMENTO TÍPICO

CLIENTE

REGISTRO

1. registra objetos3. Comunica-se diretocom o obj. servidor


SERVIDOR

Funcionamento típico

A:Cliente B:Servidorrmiregistry:Binder

Lookup(“Alo”)

rebind(“Alo”, stub )

Cria stublocate rmiregistry

Locate rmiregistry

stub


Executa ométodo

stub.digaAlo()

"Alo, mundo!"

EXEMPLO HELLO WORLD

import java.rmi.Remote;

import java.rmi.RemoteException;

public interface AloInt extends Remote {

DEFINIÇÃO DA INTERFACE DO SERVIÇO


public interface AloInt extends Remote {

String digaAlo() throws RemoteException;

}

EXEMPLO HELLO WORLD

public class AloImpl implements AloInt {

public String digaAlo() {

return "Alo, mundo!";

}

public static void main(String args[]) {

try {

AloImpl alo = new AloImpl();

// Exporta o objeto remoto colocando-o em listening para receber

// request numa porta anonima TCP - retorna o stub do objeto servidor

AloInt aloStub = (AloInt)UnicastRemoteObject.exportObject(alo, 0);

IMPLEMENTAÇÃO DO SERVIÇO


// Tenta localizar o rmiregistry no host local e na porta default (1099)

// Caso nao encontre, retorna erro: RemoteException

Registry registro = LocateRegistry.getRegistry();

// Registra o OBJ servidor: nome "Alo" e interface aloStub

// Se “Alo” ja estiver associado a outro objeto remoto, ocorre uma excecao

registro.rebind("Alo", aloStub);

} catch (Exception e) {

System.out.println("! Erro no servidor: " + e.getMessage());

}

}

}

EXEMPLO HELLO WORLD

public class AloCli {

public static void main(String[] args) {

// se host = null, pega o host local no getRegistry

String host = (args.length < 1) ? null : args[0];

try {

// localiza o registro

Registry registry = LocateRegistry.getRegistry(host);

// localiza o serviço registrado como Alo

AloInt stub = (AloInt) registry.lookup("Alo");

IMPLEMENTAÇÃO DO CLIENTE


AloInt stub = (AloInt) registry.lookup("Alo");

// faz invocacao remota do digaAlo()

String resposta = stub.digaAlo();

System.out.println("* Resposta: " + resposta);

} catch (Exception e) {

System.err.println("! Erro no cliente: " + e.toString());

e.printStackTrace();

}

}

}

EXERCÍCIO 1: Hello em JRMI

◊ Visitar http://www.dainf.ct.utfpr.edu.br/~tacla/JAVARepositorio/JRMI/JRMIHello2/

◊ Observar no diretório build só há arquivos .class� AloImpl: servidor

� AloInt: interface remota

� AloCli: cliente que utiliza o serviço

� O stub e skeleton são automaticamente gerados em tempo de execução


◊ Passo 1: Download e compilação1. Crie um projeto NetBeans num diretório <home> qualquer

2. Faça o download dos arquivos .java em <home>/src/

3. Compile o projeto

(é possível baixar todo o projeto, inclusive os .class. Neste caso não é necessário recompilar)


◊ PASSO 1: DOWNLOAD1. Crie um projeto NetBeans num diretório <home> qualquer

2. Faça o download dos arquivos .java em <home>/src/

3. Compile o projeto

(é possível baixar todo o projeto, inclusive os .class. Neste caso não é necessário recompilar)


não é necessário recompilar)


◊ PASSO 2: RODAR O RMIREGISTRY� Incluir o diretório <home>/build/classes/ no classpath (ver slide

seguinte) � Executar o command prompt e nele fazer start (2x)

� Executar o rmiregistry a partir de qualquer ponto da árvore de diretórios

◊ Observações


◊ Observações� Isto é necessário, pois o rmiregistry precisa saber onde encontrar os

arquivos .class � RMI REGISTRY é um serviço TCP que aguarda solicitações na porta

bem conhecida 1099


◊ Para setar o classpath do faça:

� Linux

� echo $CLASSPATH (verifica classpath atual)� export CLASSPATH=$CLASSPATH:<home>/build/classes/

� Windows


� Windows

� set classpath (verifica classpath atual)� set classpath=%classpath%;<home>/build/classes/


◊ PASSO 3: EXECUTAR

◊ Executar AloImpl (servidor)� Em um dos command prompt aberto pelo start

� Posicionar-se no <home>/build/classes/� Executar java AloImpl


◊ Executar AloCli (cliente)� Em um dos command prompt aberto pelo start

� Posicionar-se em <home>/build/classes/� Executar java AloCli <ip rmiRegistry>

� O argumento é a localização do RMI Registry. Não precisa ser colocado se estiver rodando na mesma máquina

EXERCÍCIO 2: CALCULADORA

◊ Utilizando o JRMIHello2 como exemplo faça um serviço remoto que implemente a seguinte interface:� double Somar(double a, double b) retorna a + b� double Subtrair(double a, double b) retorna a – b� double dividir(double a, double b) retorna a/b� Double multi(double a, double b) retorn a*b


◊ Faça um cliente que:� Localize o serviço no registro� Invoque os quatro métodos acima

PRÁTICA: QUADRO BRANCO

◊ PASSO 1: EXECUTAR� BAIXAR O CÓDIGO DE

http://www.dainf.ct.utfpr.edu.br/~tacla/JAVARepositorio/JRMI/JRMIQuadroBranco/

� Editor gráfico estilo quadro branco compartilhado por vários usuários (Coulouris, 2001). A implementação não possui interface gráfica, porém tem todo o esqueleto!

� Ao executar o cliente, o usuário pode fazerjava Cliente escrever para “desenhar” um retângulo


� java Cliente escrever para “desenhar” um retângulo

� java Cliente ler para ler todas as formas desenhadas

� java Cliente ler <n> para ler todas as formas desenhadas a partir da versão n (n é um inteiro)

� O servidor mantém o estado do desenho:� Cliente pode buscar formas desenhadas fazendo polling no servidor� O servidor guarda um número de versão junto com cada forma (evita

que um cliente recupere formas já recuperadas)

PRÁTICA: QUADRO BRANCO

◊ PASSO 3: OBSERVAR OS PONTOS ABAIXO� Os objetos que são passados por valor (ObjetoGrafico) devem ser

serializáveis (equivale ao marshalling no Java)

� Download de classes pela JVM� Quando um cliente recebe uma resposta contendo um objeto

passado por valor


passado por valor� Quando uma referência remota aponta para um proxy que não

existe localmente

� Dinamicidade

� Mudar o código do ObjetoGráfico e mostrar que funciona

EXERCÍCIO 3

◊ Implementar uma interface gráfica nos clientes do quadro branco (vide slides anteriores) de maneira que todos possam editar um desenho de forma cooperativa.


EXERCÍCIO 4

◊ Implementar o avaliador de respostas de questionários (o mesmo feito em UDP e TCP) com JRMI


RESUMO DE RMI

◊ RMI� Cada objeto do SD tem uma referência remota e uma interface

remota que especifica quais operações podem ser invocadas remotamente.

� Invocações de métodos locais possuem semântica de execução “exatamente uma vez”


“exatamente uma vez”

� RMI somente garante “no máximo uma vez”

� Os componentes do middleware components (proxies, skeletons e dispatchers) escondem do programador os detalhes de marshalling, envio de mensagens e localização dos objetos.

RPC


Remote Procedure Call

RPC

◊ Remote Procedure Call� Chamada de procedures remotas

◊ Similar à RMI◊ Permite cadeia de invocações

◊ Uma implementação de RPC também implementa uma


◊ Uma implementação de RPC também implementa uma ou mais semânticas de invocação� Talvez� Pelo menos uma� No máximo uma

◊ Mais simples que RMI� não tem o módulo de referência a objeto remoto

IMPLEMENTAÇÃO RPC

A: CLIENTE

programa

invocareturn

return

Procedure 1

Procedure2

PROXYSKELETON


STUB PROC 1

DISPATCHER

reply requestrequest

Invoca procedure 1

reply



Request/reply Request/reply

STUB PROC 1. STUP PROC 2PROXY

CONCLUSÃO

◊ CORBA x JRMI� Use Corba se o sistema distribuído tiver programas escritos em

linguagens ou paradigmas diferentes� Use Corba se futuramente o sistema interoperar com outros

sistemas escritos em linguagens ou paradigmas diferentes� Se tudo for e será Java, use JRMI


◊ Java oferece várias formas de realizar distribuição� Sockets: menor abstração, mensagens ou stream

� CORBA: abstração invocação� JRMI: abstração maior, objetos

0070-rmi-rpc.ppt [modo de compatibilidade]tacla/espsd/aula4/0070-rmi-rpc.pdf · corba 2 b. jrmi c....

Documents