Middle Ware

5/11/2018 Middle Ware - slidepdf.com

http://slidepdf.com/reader/full/middle-ware-55a230eb296aa 1/34

CENTRO FEDERAL DEEDUCAÇÃO TECNOLÓGICA

DE MINAS GERAISCurso: Engenharia de Controle e Automação

Disciplina: Redes e Sistemas DistribuídosProf. MSc. Christien Lana Rachid



O que são Objetos Remotos

Objetos remotos são objetos cujos métodospodem ser chamados remotamente, como se

fossem locais◦ Cliente precisa, de alguma forma, localizar eobter uma instância do objeto remoto(geralmente através de um proxy intermediário

gerado automaticamente)◦ Depois que o cliente tem a referência, fazchamadas nos métodos do objeto remoto(através do proxy) usando a mesma sintaxeque usaria se o objeto fosse local



O que são Objetos Remotos

Objetos remotos abstraem toda a complexidadeda comunicação em rede

◦ Estende o paradigma OOalém do domínio local

◦ Torna a rede transparente



RPC

Birrell, A.D. & Nelson, B.J. "Implementing RemoteProcedure Calls." ACM Transactions on Computer Systems2, 1 (Feb. 1984): 39-59.

A finalidade preliminar de nosso projeto RPC era fazer acomputação distribuída fácil. Previamente, observou-sedentro de nossa comunidade de pesquisa que a construçãode programas de comunicação era uma tarefa difícil,

compreendidas somente por membros de um grupo seletode peritos de comunicação. Mesmo os investigadores comexperiência substancial dos sistemas encontraram difíciladquirir a perícia especializada exigida para construirsistemas distribuídos com ferramentas existentes.

Invocação transparente de rotinas remotas, como setratassem de rotinas locais.



RPC: Idéia Básica

r= soma(x,y) float soma(x,y) {return x+y;

}

Cliente Servidor



RPC: Marshalling e Unmarshalling

Quando cliente A chama procedimentos de um servidor B:◦ Pode ser necessário passar como parâmetro (e receber como

resultado) estruturas mais complexas (objetos, vetores etc)

Cliente A:◦ Deve converter os parâmetros para um formato que possa ser

transmitido por um protocolo de transporte (TCP, por exemplo)

◦ Este processo é chamado de marshalling

Servidor B:◦ Deve converter mensagem recebida em uma estrutura de

dados

◦ Este processo é chamado de unmarhalling

Processo de marshalling/unmarshalling é tedioso e sujeitoa erros

Portanto, deve ser automatizado pela plataforma demiddleware



RPC: Stubs

Funcionamento interno baseado em módulos chamados destubs

Stubs: encapsulam detalhes de comunicação no cliente eservidor◦ Automatizam processo de marshalling e unmarshalling

◦ Automatizam comunicação com o processo remoto (interagindocom o protocolo de transporte)

Marshalling/unmarshalling realizado por stubs é chamado

de estático

Client Stub: Funciona como um proxy, reencaminhando achamada à rotina para o servidor que implementa a rotina.

Server Stub: Semelhante ao do cliente, mas implementa

a invocação do lado do servidor.



RPC: Arquitetura Interna

r= soma(x,y)

float soma(x,y) {

}

float soma(x,y) {return x+y;}

(1)

(2)

(3) (4)

(5)

(6)

Cliente

StubCliente

StubServidor

Servidor

Questão fundamental: Quem gera os stubs?Evidentemente, geração manual não faz sentido



RPC: Arquitetura Interna

Stubs são gerados automaticamente, por umcompilador de stubs

Entrada deste compilador: assinatura dosprocedimentos remotos, em uma linguagemchamada XDR (External Data Representation)◦ Genericamente, conhecida como linguagem para

definição de interfaces

Saída deste compilador: código fonte dos stubs

rpcgen

arquivo XDR

client_stub.c

server_stub.c



Sistemas de MiddlewareOrientados por Objetos

Extensão de RPC para o paradigma orientado por objetos

Idéia básica: objetos clientes podem chamar métodos deobjetos remotos com transparência de acesso (isto é, com a

mesma sintaxe de chamadas locais) Principal abstração: chamada remota de métodos (RMI)

Objetos remotos são manipulados usando-se referências derede

Sistemas: CORBA, Java RMI, DCOM, .NET Remoting etc

Servidor (de aplicação): instancia objeto remoto e o registrano servidor de nomes (registrar= dar um nome para o objeto)

Servidor de nomes: tabela (nome, referência de rede)

Cliente: consulta servidor de nomes (fornecendo o nome doobjeto), obtém uma referência de rede para o objeto remoto),usa essa referência para realizar chamadas remotas



Java RMI (Remote Method Invocation) pode serimplementado usando protocolos e infra-estrutura próprios do Java (JRMP e RMI Registry)ou usando IIOP e ORBs, próprios do CORBA

JRMP - Java Remote Method Protocol◦ Pacote java.rmi - RMI básico◦

Ideal para aplicações 100% Java.

IIOP - Internet Inter-ORB Protocol◦ Pacote javax.rmi - RMI sobre IIOP◦ Ideal para ambientes heterogêneos.

Java RMI



Java RMI

Middleware para programação distribuída em Java

Implementado como um pacote da linguagem

Ann Wollrath, Roger Riggs, Jim Waldo. A Distributed ObjectModel for the Java System. COOTS 1996

A chamada de métodos remotos permite que aplicaçõeschamem métodos de determinado objeto encontradosremotamente, compartilhando recursos e processando a

carga em outros computadores. A chamada de métodos remotos (RMI) facilita a chamada

de métodos entre diferentes máquinas virtuais (JVMs).

Os métodos podem até mesmo passar objetos que umaoutra máquina virtual nunca obteve antes, permitindo o

carregamento dinâmico de novas classes quandonecessário.



Java RMI

f1()

f2()

....fn()

RMI

Registry

bind(s,"foo");

s= lookup("server01.pucminas.br/foo")

s= new Server()

network reference

s.f1(); // remote method calls

........s.f2();

Client Server (server01.pucminas.br)



Considere o seguinte cenário

O desenvolvedor A escreve um serviço que

execute alguma função útil. Atualizaregularmente este serviço, adicionandocaracterísticas novas e melhorando seucomportamento.

O desenvolvedor B deseja usar o serviçofornecido pelo desenvolvedor A. Entretanto, éinconveniente para A, estar sempre fornecendopara B um update com a nova versão docomponente.



A arquitetura RMI é baseada em um importante princípio:a definição do comportamento e a implementação docomportamento são conceitos separados.

RMI permite que o código que define o comportamento e ocódigo que implementa o comportamento permaneceremseparados e rodarem em JVMs separadas.

Em RMI, a definição do serviço remoto é codificada usandouma interface Java.

A implementação do serviço remoto é codificada em umaclasse.

As interfaces definem o comportamento e as classesdefinem a implementação.

A classe que implementa o comportamento roda do lado do

servidor RMI.

Java RMI



RMI: Funcionamento

Um objeto remoto previamente registrado é obtido, atravésde servidor de nomes especial: RMI Registry.

◦ Permite que os objetos publicamente acessíveis atravésda rede sejam referenciados através de um nome.

Serviço de nomes: classe java.rmi.Naming

◦ Método Naming.lookup() consulta um servidor de nomesRMI e obtém uma instância de um objeto remoto

Exemplo (jogo de batalha naval):

Territorio mar =(Territorio)Naming.lookup("rmi://gamma/caspio");

Agora é possível chamar métodos remotos de mar:

tentativa[i] = mar.atira("C", 9);



Arquitetura do RMI

Uma aplicação distribuída com RMI tem acessotransparente ao objeto remoto através de sua InterfaceRemota

◦ A "Interface Remota" é uma interface que estende java.rmi.Remote

◦ A partir da Interface Remota e implementação do objetoremoto o sistema gera objetos (proxies) que realizamtodas as tarefas necessárias para viabilizar a

comunicação em rede



Padrões de projeto

A implementação RMI é um exemplo do padrãode projeto chamado Proxy

Proxy é uma solução para situações onde oobjeto de interesse está inaccessíveldiretamente, mas o cliente precisa operar emuma interface idêntica◦ A solução oferecida por Proxy é criar uma classe que

tenha a mesma interface que o objeto de interesse(implemente a mesma interface Java) e que implemente,em seus métodos, a lógica de comunicação com o objetoinaccessível.

Em RMI, o proxy é o Stub geradoautomaticamente pelo ambiente de

desenvolvimento (rmic)



RMI em 10 passos

Nosso objetivo é oferecer apenas uma introduçãobásica a Java RMI . Isto será feito através de umexemplo simples

◦ 1. Definir a interface◦ 2. Implementar os objetos remotos◦ 3. Implementar um servidor para os objetos◦ 4. Compilar os objetos remotos◦ 5. Gerar stubs e skeletons com rmic *◦ 6. Escrever, compilar e instalar o(s) cliente(s)◦ 7. Instalar o stub no(s) cliente(s)◦ 8. Iniciar o RMI Registry no servidor ◦ 9. Iniciar o servidor de objetos◦

10. Iniciar os clientes informando o endereço doservidor.



1. Definir a Interface Remota

Declare todos os métodos que serão acessíveisremotamente em uma interface Java que

estenda java.rmi.Remote.◦ Todos os métodos devem declarar throws java.rmi.RemoteException.

Isto deve ser feito para cada objeto que seráacessível através da rede.

import java.rmi.Remote;import java.rmi.RemoteException;public interface Mensageiro extends Remote {public void EscreverMensagem(String str) throwsRemoteException;

public String LerMensagem() throws RemoteException;}



2. Implementar Objetos Remotos

Cada objeto remoto é uma classe que estende a classe java.rmi.server.UnicastRemoteObject e que implementa ainterface remota criada no passo 1.

Todos os métodos declaram causar java.rmi.RemoteException inclusive o construtor, mesmoque seja vazio.

import java.rmi.AlreadyBoundException;import java.rmi.RemoteException;public class MensageiroImpl extends RemoteException implements Mensageiro

{public static void main (String[] args) throws RemoteException, AlreadyBoundException{

new Servidor();}public void EscreverMensagem(String str) throws RemoteException {

System.out.println(str);}public String LerMensagem() throws RemoteException {

return "Sou Java";}

}



3. Estabelecer um Servidor

Crie uma classe que◦ a) Crie uma instância do objeto a ser servido e

◦

b) Registre-a (bind ou rebind) no serviço de nomes. import java.net.MalformedURLException;import java.rmi.AlreadyBoundException;import java.rmi.Naming;import java.rmi.RemoteException;public class Servidor {

public Servidor() throws RemoteException, AlreadyBoundException{

try{

Mensageiro m = new MensageiroImpl();Naming.rebind("//Localhost:1099/MensageiroServico", m);

}catch (Exception e){

System.out.println(e.getLocalizedMessage());

}}



4. Compilar os objetos remotos

Compile todas as interfaces e classesutilizadas para implementar as interfaces

Remote

javac Mensagem.java Javac MensagemImpl.java



5. Gerar Stubs e Skeletons

Use a ferramenta do J2SDK: rmic Será gerado um arquivo stub

◦ MensagemImpl_stub.classe um arquivo skeleton◦ MensagemImpl_skel.classpara cada objeto remoto (neste caso, apenasum)

RMIC = RMI Compiler◦ Execute o rmic sobre as implementações do objeto

remoto já compiladas:

> rmic MensagemImpl



6. Compilar e Instalar os Clientes

Escreva uma classe cliente que localize o(s)objeto(s) no serviço de nomes ( java.rmi.Naming)◦

a) Obtenha uma instância remota de cada objeto◦ b) Use o objeto, chamando seus métodos

import java.net.MalformedURLException;public class Cliente {public static void main(String[] args) throws NotBoundException,MalformedURLException, IOException

{ try {Mensageiro m = (Mensageiro) Naming.lookup("//localhost:1099/MensageiroServico");

String x = m.LerMensagem();System.out.println(x);m.EscreverMensagem("Acessando e Enviando Mensagem");System.out.println(m.LerMensagem());

}

catch (RemoteException ex) {System.out.println(ex.getMessage());

} } }



7. Distribuir o Stub no(s) Cliente(s)

Distribua o cliente para as máquinas-cliente. A distribuição deve conter◦ Classe(s) que implementa(m) o cliente(Cliente.class)

◦ Os stubs (MensageiroImpl_stub.class)

◦ As interfaces Remote (Mensageiro.class)

• Em aplicações reais, os stubs podem ser mantidos no servidor

• O cliente faz download do stub quando quiser usá-lo

• Para isto é preciso definir algumas propriedades adicionais(omitidas no nosso exemplo simples) como Codebase(CLASSPATH distribuído), SecurityManager e políticas de

segurança (Policy)



8. Iniciar o RMI Registry no Servidor

No Windows

> start rmiregistry

(O RMI Registry fica "calado" quando estárodando)

Neste exemplo será preciso iniciar o RMIRegistryno diretório onde estão os stubs e interfaceRemote

◦ Isto é para que o RMIRegistry veja o mesmoCLASSPATH que o resto da aplicação

◦ Em aplicações RMI reais isto não é necessário,mas é preciso definir a propriedade

java.rmi.server.codebase contendo oscaminhos onde se pode localizar o código



9. Iniciar o servidor de objetos

O servidor é uma aplicação executável que registra osobjetos no RMIRegistry. Rode a aplicação:

◦

> java ServidorServidor no ar. Nome do objeto servido:mensagens

Neste exemplo será preciso iniciar o servidor nodiretório onde estão os stubs e interface Remote

◦ Isto é para que o RMIRegistry veja o mesmoCLASSPATH que o resto da aplicação

◦ Em aplicações RMI reais isto não é necessário, masé preciso definir a propriedade

java.rmi.server.codebase contendo os caminhosonde se pode localizar o código



10. Iniciar os Clientes

Rode o cliente ◦ Informe o endereço do servidor e objetos a

utilizar

> Java Cliente



Java RMI: Passagem deParâmetros

Objetos serializáveis são passador por valor:

◦ Classe do objeto deve implementar a interfaceSerializable

◦ Passa-se uma cópia do objeto (atributos + métodos)

Objetos remotos são passadas por referência:

◦ Passa-se a referência (e não o objeto), a qual podeser utilizada para realizar um callback no cliente

◦ Callback : servidor chama método do cliente◦ Usado, por exemplo, quando o servidor deseja

notificar o cliente sobre a ocorrência de algum evento



Exemplo de Callback

Cliente Servidor

void f (A a) {

a.g(); // callback

}

void g ()

{..... }

s

s.f(a);

A B

objeto remoto objeto remoto

a



Java RMI - Chat

Aplicação de chat usando Java RMI, coma seguinte interface:



Sistema de Chat em Java RMI33

void conecta(C c) { “adiciona c em conectados”

}

void envia (String s)

{ for (int i= 0; i < conectados.size; i++)

conectados[i].display(s); // callback }conectados

s.conecta(c);

......

s.envia(“Bom dia!”);

display (s)

c

remoto

remoto

s.conecta(c);

display (s)

c

remoto

s.conecta(c);

display (s)

c

remoto



CORBA

CORBA: Common Object Request Broker Architecture

◦ Padrão para desenvolvimento de aplicações distribuídaspara sistemas heterogêneos usando orientação por

objetos OMG: Object Management Group (http://www.omg.org)

◦ Consórcio de empresas responsável pela proposição emanutenção do padrão CORBA

◦ Criado em 1989, possui atualmente diversas empresas

OMA: Object Management Architecture

◦ Arquitetura para construção de aplicações distribuídas

◦ Primeira especificação importante da OMG

Objetivo da OMG: propor uma arquitetura e, em seguida,

propor padrões para os componentes da mesma

Middle Ware

Documents

Transcript of Middle Ware