Objetos Distribuídos e Invocação
Remota
Introdução
1
Introdução

RPC x RMI
2
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
Introdução

RPC – Remote procedure call
–

RMI – Remote method invocation
–

Este termo é utilizado para aplicativos clientes que fazem
normalmente chamadas a procedimentos remotos que
estão em outro processo e hosts.
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.
3
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
4
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
5
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
Introdução
–
Hardware

–
Sistema Operacional

–
O middleware implementa mecanismo para troca de
dados entre diferentes plataforma de hardware
existentes. Ex: IDL
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
6
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
Introdução
Applications
RMI, RPC and events
Request reply protocol
Middleware
layers
External data representation
Operating System
7
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
8
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
9
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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.
10
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
IDL

Corba IDL
// In file Person.idl
struct 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();
};
11
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
IDL

Outras
–
Além do Corba IDL, temos:



OSF - C IDL
DCOM - CDE IDL
etc
12
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto

Referência de objetos
–

Interfaces
–

É a ação existente necessária para providenciar a invocação do objeto,
sua execução, devolvendo algum resultado ao cliente
Exceções
–

Define os métodos, tipos dos argumentos, tipos de retornos e exceções,
sem especificar sua implementação
Ações
–

Usado para fazer referencia para qualquer chamada a um método
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
13
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
remote
invocation
A
14
Professor: Arlindo Tadayuki Noji
B
local
C
E
invocation local
invocation
local
invocation
D
remote
invocation
Instituto de Ensino Superior
F
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.
15
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto Distribuído

Objeto Remoto e Interface Remoto
remoteobject
remote
interface
{
Data
m1
m2
m3
implementation
of methods
m4
m5
m6
16
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
17
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
18
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto Distribuído

Semântica de Invocação
Invocation
semantics
Fault tolerance measures
Retransmit request
message
Duplicate
filtering
Re-execute procedure
or retransmit reply
No
Not applicable
Not applicable
Maybe
Yes
No
Re-execute procedure
At-least-once
Yes
Yes
Retransmit reply
At-most-once
19
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
20
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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)
21
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
22
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto Distribuído

Métodos de Chamada Remota
server
client
object A proxy for B
Request
skeleton
& dispatcher
for B’s class
remote
object B
Reply
Communication
Remote
reference module
module
Communication
module
Remote reference
module
23
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto Distribuído

Implementação do RMI
–
–
–
–
Proxy
Bindind name
Objects references
Comunications
24
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto Distribuído

Módulo de comunicação
–
–
25
Implementa um protocolo solicitação e resposta
Usa os 3 primeiros itens da estrutura de msg
messageType
requestId
objectReference
methodId
arguments
Professor: Arlindo Tadayuki Noji
int (0=Request, 1= Reply)
int
RemoteObjectRef
int or Method
array of bytes
Instituto de Ensino Superior
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
26
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
27
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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.
28
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
29
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
–
30
É 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
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
31
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
32
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto Distribuído

O factory method
–

O factory object
–

É usado para criar objetos remotos
É 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
33
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
O Modelo de Objeto Distribuído

Server Threads
–

Ativação de objetos remotos
–
–

É a capacidade de executar concorrência aos 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
34
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
35
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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
36
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
Modelo RPC

Ex:
client process
server process
Request
client stub
procedure
client
program
Communication
module
Reply
server stub
procedure
Communication
dispatcher
module
service
procedure
37
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
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.
38
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior
Modelo de Objeto Distribuído

Ex:
–
–
SUN RPC
JAVA RMI
39
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior