Objetos Distribuídos e Invocação Remota

39
1 Objetos Distribuídos e Invocação Remota Introdução

description

Objetos Distribuídos e Invocação Remota. Introdução. Introdução. RPC x RMI. Introdução. RPC – Remote procedure call Este termo é utilizado para aplicativos clientes que fazem normalmente chamadas a procedimentos remotos que estão em outro processo e hosts. RMI – Remote method invocation - PowerPoint PPT Presentation

Transcript of Objetos Distribuídos e Invocação Remota

1

Objetos Distribuídos e Invocação Remota

Introdução

2Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Introdução

RPC x RMI

3Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Introdução

RPC – Remote procedure call– Este termo é utilizado para aplicativos clientes que fazem

normalmente chamadas a procedimentos remotos que estão em outro processo e hosts.

RMI – Remote method invocation– O modelo baseado orientado a objeto utiliza este termo

para definir uma chamada a um método.

Eventos distribuídos– É capacidade de notificação que os SD tem de avisar a um

outro processo que um evento ocorreu.

4Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Introdução

Middleware– Software que providencia um modelo de

programação por blocos de processos pela passagem de mensagem

– Alguns middleware permitem que os processos sejam implementados em diferentes linguagem de programação

5Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Introdução

Características– Transparência de locação

o cliente não sabe se o procedimento ou método chamado está no mesmo processo ou num processo diferentes rodando em outra máquina. Ex: RPC, RMI, etc

– Protocolo de Comunicação Um middleware deve ser capaz de implementar o

processo de comunicação solicitação e resposta, em qualquer protocolo existente. Ex: TCP ou UDP

6Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Introdução

– Hardware O middleware implementa mecanismo para troca de

dados entre diferentes plataforma de hardware existentes. Ex: IDL

– Sistema Operacional O middleware deve ser capaz de oferecer alto nível de

abstração do S.O. que está sendo utilizado

– Independência de Linguagem de programação Alguns middlewares podem permitir transparência

quanto ao uso de diferentes linguagens de programação em seus processos. Ex: Corba, IDL

7Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Introdução

Applications

Middlewarelayers Request reply protocol

External data representation

Operating System

RMI, RPC and events

8Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Interfaces

Interfaces– Define como e quais objetos e variáveis estão

presentes na comunicação entre processos.– Não tem acesso direto as variáveis ou método– Define parâmetros de inputs e outputs– Não trabalha com ponteiros

9Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Interfaces

Service interfaces– Termo utilizado para definir as procedures ou serviços

oferecidos pelo servidor. Ex: FTP, procedimento de escrita e leitura de arquivo

Remote Interface– Especifica os métodos de um objeto que estão disponíveis

para inovocação por outros objetos de outros processos. Define: tipos de entrada e saída de cada objeto Passa também objetos como argumento ou resultado

10Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Interfaces

Interface Definition Languages – IDL– Permite criar uma notação universal para

interface de métodos e variáveis para serem utilizados entre diversas linguagem de programação.

11Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

IDL

Corba IDL

// In file Person.idlstruct Person {

string name; string place;long year;

} ;interface PersonList {

readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out Person p);long number();

};

12Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

IDL

Outras – Além do Corba IDL, temos:

OSF - C IDL DCOM - CDE IDL etc

13Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto

Referência de objetos– Usado para fazer referencia para qualquer chamada a um método

Interfaces– Define os métodos, tipos dos argumentos, tipos de retornos e exceções,

sem especificar sua implementação Ações

– É a ação existente necessária para providenciar a invocação do objeto, sua execução, devolvendo algum resultado ao cliente

Exceções– Permite definir as regras para tratamento de erros que podem ocorrer nos

processo Coleção de lixos

– Controle para liberação de espaços para os objetos não mais usados. Ex: Java

– Outras linguagens não fazem esse controle

14Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Objetos distribuídos

Cada processo contém objetos, alguns na qual podem receber chamadas remotas, outras somente local

– Objetos Remotos x Objetos Locais Objetos precisam conhecer a referência de objeto remoto de um

objeto em outro processo para poder invocar seus serviços. Como ele faz isso?

A interface Remota especifica como os métodos são acessados remotamente

invocation invocationremote

invocationremote

locallocal

localinvocation

invocationA B

C

D

E

F

15Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Existe dois conceitos fundamentais para um modelo de objetos distribuídos:– Referência de Objeto Remoto

É um identificador único que pode ser usado em um sistema distribuído para fazer referência a um particular objeto remoto

– Interface Remoto Define como os objetos remotos podem ser invocados,

contém a definição das estruturas de dados e métodos. Ex: Corba IDL e Java RMI.

16Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Objeto Remoto e Interface Remoto

interfaceremote

m1m2m3

m4m5m6

Data

implementation

remoteobject

{ of methods

17Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Desafios para projetos de RMI

Apesar de em Java a chamada remota ser uma questão de uma extensão a uma chamada local, ela ainda apresenta desafios:

– Numa chamada local, o método é executado apenas uma vez. No RMI nem sempre é verdade

– Nível de transparência nem sempre atinge o desejável

18Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Desafios para projetos de RMI

Diferentes formas de invocação– Retry request message– Duplicate filtering– Retransmission od results

Os problemas acima afetam na confiabilidade do método de convocação de um objeto remoto

19Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Semântica de Invocação

Fault tolerance measures Invocation semantics

Retransmit request message

Duplicate filtering

Re-execute procedure or retransmit reply

No

Yes

Yes

Not applicable

No

Yes

Not applicable

Re-execute procedure

Retransmit reply At-most-once

At-least-once

Maybe

20Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Maybe invocation semantics– Pode ocorrer quando o cliente invoca um objeto remoto,

mas sabe realmente se foi executado ou não Falha por omissão ( ex: perda de msg) Crash (Ex: o objeto presente no servidor falha)

– A falha pode ocorrer antes de executar o objeto, ou depois de ser executado

Perda da msg antes Perda da msg depois Time out

21Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

At-least-once invocation semantics:– Neste caso, o cliente que invoca conhece que um

determinado objeto foi executado pelo menos uma vez ou pelo menos é avisado que houve um erro

– Neste categoria os problemas podem advir de: Crash Falhas arbitrárias (erros podem ocorrer se a

retransmissão executar o objeto novamente)

22Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

At-most-once semantics:– O cliente que invoca sabe exatamente que o

método remoto foi chamado apenas uma vez ou não.

– Aplica e trata todas os tipos de falhas que podem ocorrer

– Ex: Java RMI, Corba– Corba aceita At-least-once para chamadas a

objetos que não retornem resultado

23Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Métodos de Chamada Remota

object A object Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

module modulereference module module

for B’s class& dispatcher

remoteclient server

24Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Implementação do RMI– Proxy– Bindind name – Objects references– Comunications

25Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Módulo de comunicação– Implementa um protocolo solicitação e resposta– Usa os 3 primeiros itens da estrutura de msg

messageTyperequestId

objectReferencemethodIdarguments

int (0=Request, 1= Reply)int

RemoteObjectRefint or Methodarray of bytes

26Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Módulo Referência Remota– É responsável entre a tradução da referência

local e a referência remota dos objetos– Cria o referência de objetos remotos– Cada processo possui uma tabela de referência

de objetos, que faz correspondência entre as informações dos objetos existentes nos processos locais e não locais

27Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Módulo Referência Remota– Tabela de referência de objetos

Mantêm todas as referências de objetos locais usadas pelo processo

Mantêm as referências para cada proxy local, correspondentes dos objetos remotos

28Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Acões do Módulo de Referência Remota– Quando um objeto remoto é passado como argumento ou

como resultado pela primeira vez, o módulo de referência remota é incentivado a criar uma referência de objeto remoto, na qual é adicionado a uma tabela

– Quando uma referência de objeto remoto chega em uma solicitação ou numa resposta de mensagem, o módulo de referência remota faz uma consulta para encontrar uma referência do objeto localmente, na qual pode referir-se para um proxy ou para um objeto remoto

– Caso a referência de objeto remoto não seja encontrado na tabela, o RMI cria um novo proxy e insere na tabela através do módulo de referência remota.

29Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

O software RMI– Consiste em uma camada de software entre a aplicação

baseada em objetos e a comunicação e o módulo de referência remota

Proxy – a função do proxy é providenciar um método transparente de invocação para o cliente, fazendo parecer que está invocando um objeto local. Mas em vez de executar alguma tarefa, ele transfere na forma de msg para o objeto remoto

– Esconde os detalhes de uma referência a objetos remotos, marshalling, unmarshalling e os processos de comunicações existentes

– Existe um proxy para cada Objeto remoto

30Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Dispatcher - Um servidor tem um dispatcher e um skeleton para cada representação de classe de objetos.

– O Dispatcher é responsável por receber as requisições vindas do módulo de comunicações.

– Usa o MethodId para selecionar o apropriado método no Skeleton– O Dispatcher e proxy usam a mesma alocação de methodId para

os métodos de interface remota

Skeleton – A classe de um objeto remoto possui um skeleton, onde é implementado os métodos dentro de uma interface remota

– É implementado um pouco diferente da interface original do objeto remoto

– Passa pelo processo de marshalling antes de invocar o objeto remoto e unmashalling para devolver a informação como resultado

31Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Geração de classes para proxies, dispatchers e skeleton

– São gerados automaticamente pela interface do compilador Corba

– São gerado a partir do arquivo IDL– Para o Servidor é gerado os proxys, dispatches e skeleton

de cada objeto remoto– Para o Cliente, os aplicativos deverão conter as classes

dos proxys de todos os objetos remotos– Exemplo de compiladores: Orbix (C++); Delphi

32Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Factory method– Interface de objetos remotos não possuem

construtores, portanto, os objetos remotos não podem ser construídos pela invocação remota de construtores

– Objetos remotos são construídos através de uma sessão de inicialização ou por um método remoto projetado para este propósito

33Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

O factory method – É usado para criar objetos remotos

O factory object – É o objeto criado pelo método factory (factory method)

Binders– É um serviço separado que mantém uma tabela contendo

uma mapeamento dos nomes textual sobre as referências de objetos remotos e é usado pelo servidor para registrar identificar os seus objetos remotos por nome e os seus clientes

34Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

O Modelo de Objeto Distribuído

Server Threads– É a capacidade de executar concorrência aos objetos remotos

Ativação de objetos remotos– Este processo permite controlar quando um determinado objeto

remoto está ativo ou disponível para ser invocado. Isto é feito porque não é pratico manter todos objetos remotos funcionando e disponíveis em dado tempo, além de não ser realmente necessário

– Este controle é feito pelo servidor que gerencia este processo automaticamente (ex: iniciado quando for envolvido no processo de marshalling)

Persistência de objetos– São geralmente providenciado pelo servidor e dão a capacidade

ao objeto remoto de manter seus estados mesmo após diversas ativações

35Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Modelo RPC

Remote Procedure Call– É similar ao RMI, mas neste caso, se refere a capacidade

de fazer chamadas a procedures que estão em outros processos

– Servidores podem ser clientes de outros processo servidores

– Possui como semântica de invocação: At-least-once At-most-once

– Usa também um protocolo de solicitação e resposta

36Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Modelo RPC

O RPC não utiliza módulos de referência remota, uma vez que não trabalha com objetos e métodos

O cliente utiliza um stub procedure, similar ao uso do proxy para as chamadas das procedures remotas

– Um stub procedure recebe a chamada, mas ao invés de executar algo, ele executa o processo de marshalling e transmite via msg a solicitação ao servidor com a procedure remota para a execução

– No recebimento da resposta, executa o processo de unmarshalling e apresenta o resultado para o invocador dentro do processo local

37Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Modelo RPC

Ex:

client

Request

Reply

CommunicationCommunication

module module dispatcher

service

client stub

server stubprocedure procedure

client process server process

procedureprogram

38Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Modelo RPC

No servidor– Contém um dispatcher que trabalha junto com um stub

procedure servidor e que liga a um serviço (procedure) existente para cada procedure existente na interface de serviços

– O dispatcher seleciona a procedure de acordo com identificação da procedure vinda da msg de solicitação

– O Server stub procedure funciona parecido com um skeleton, onde executa o processo de unmarshalling dos argumentos de entrada, executa a procedure implementada e faz o marshalling dos resultados para serem devolvidos através de uma msg.

39Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior Fucapi - CESF

Modelo de Objeto Distribuído

Ex: – SUN RPC– JAVA RMI