Comunicação Inter-Processos com Middleware

Prévia do material em texto

Comunicação Inter-Processos
Eduardo Adilio Pelinson 
Alchieri
Middleware
 É uma camada de software cujo objetivo é mascarar a 
heterogeneidade e fornecer um modelo de programação 
conveniente para os programadores de aplicativos.
 É composto por um conjunto de processos ou objetos, em um 
grupo de computadores, que interagem entre si de forma a 
implementar comunicação e oferecer suporte para 
compartilhamento de recursos a aplicativos distribuídos.
 Ele simplifica as atividades de comunicação de programas 
aplicativos por meio do suporte de abstrações como a invocação 
a métodos remotos, a comunicação entre objetos de dados 
compartilhados entre computadores e replicação de objetos de 
dados compartilhados.
 Exemplo: CORBA, RMI Java, DCOM da Microsoft.
Middleware - Camadas
RPC, RMI
Plataforma
Aplicações, Serviços
MiddlewareProtocolo baseado em 
requisição-resposta e 
Representação Externa de 
Dados e Empacotamento
Middleware - Funções
 Provê transparência quanto à localidade
 Chamada a procedimento local = chamada a procedimento 
remoto
 O cliente não sabe onde o procedimento está
 Invocação de um objeto local = invocação de um objeto 
remoto
 O cliente não sabe onde o objeto está
 Provê independência com relação 
 Protocolos de comunicação
 Sistemas operacionais
 Hardware
Middleware no Contexto da 
Internet TCP/IP
Middleware
UDP e TCP
Aplicações, Serviços
Comunicação em Sistemas 
Distribuídos
 A passagem de mensagem entre um par de processos pode ser 
suportada por duas operações: send e receive;
 Para ter comunicação, um processo envia (send) uma 
mensagem para um destino, e o outro processo recebe (receive).
 Os remetentes fazem as mensagens serem adicionadas em filas 
remotas (buffers) e os processos destino removem mensagens de 
suas filas locais.
Origem Destino
Po Pd
1. send
2. receive
mensagem
Características da Comunicação - Primitivas 
Bloqueantes e Não-Bloqueantes
 As primitivas de troca de mensagens podem ser classificadas 
em:
Características da Comunicação - 
Comunicação Síncrona
 Se a primitiva é send bloqueante então o processo 
que está enviando fica bloqueado enquanto a 
mensagem estiver sendo enviada.
 A instrução seguinte à chamada send não será 
executada até que a mensagem tenha sido 
completamente enviada.
 De maneira similar, uma chamada para receive não 
retorna o controle até que a mensagem tenha sido 
realmente recebida e colocada no buffer de saída.
Características da Comunicação - 
Comunicação Assíncrona
 Operação send é não-bloqueante
 Processo de envio ocorre em paralelo à transmissão de 
mensagens
 Operação receive pode ser
 Não-bloqueante
 Parece ser mais eficiente, mas ela envolve uma complexidade 
extra no processo destino - a necessidade de ler uma 
mensagem recebida fora de seu fluxo normal de execução.
 Bloqueante
 Em sistemas que suportam múltiplas threads em um único 
processo, a operação não tem desvantagem, pois o 
recebimento pode ser feito por uma thread, enquanto outras 
threads continuam ativa.
Características da Comunicação - 
Comunicação Assíncrona
 Se send é não-bloqueante ele devolve o controle ao 
processo que chamou imediatamente, antes do envio 
da mensagem.
 A vantagem é que o processo que envia a mensagem 
pode continuar processando em paralelo com a 
transmissão da mensagem.
 Todavia, o transmissor não pode modificar o buffer 
até que a mensagem tenha sido enviada. 
Caracteristicas da Comunicação – 
Destino da Mensagem
 Um cliente deve conhecer o endereço de um servidor 
para enviar-lhe uma mensagem
 Existem diversas formas de endereçamento de 
processos:
– Indicar a máquina e o número do processo
– Deixar o processo escolher um número e 
localizá-lo através de um broadcast
– Procurar o endereço do processo através de um 
servidor de nomes
Caracteristicas da Comunicação – 
Destino da Mensagem
 Um cliente deve conhecer o endereço de um servidor 
para enviar-lhe uma mensagem
 Existem diversas formas de endereçamento de 
processos:
– Indicar a máquina e o número do processo
– Deixar o processo escolher um número e 
localizá-lo através de um broadcast
– Procurar o endereço do processo através de um 
servidor de nomes
Caracteristicas da Comunicação – 
Destino da Mensagem
 Nos protocolos internet as msgs são enviadas para destinos 
identificados pelo par: (endereço IP, porta local)
 Uma porta local é um destino de msg, especificado como um 
valor inteiro;
 Qualquer processo que saiba o número de uma porta pode 
enviar uma mensagem para ela;
 Geralmente, os servidores divulgam seus números de porta para 
os clientes acessarem;
 Se o cliente usa um endereço IP fixo para se referir a um 
serviço, então esse serviços sempre deve ser executado no 
mesmo computador para que seu endereço permaneça válido.
– Para proporcionar transparência de localização, pode-se 
utilizar um serviço de nomes.
Caracteristicas da Comunicação – 
Confiabilidade e Ordenação
 Comunicação confiável diz respeito a validade e integridade
 Quanto a validade:
– Um serviço de msg ponto a ponto pode ser descrito como 
confiável se houver garantia que as msgs são entregues, 
independente de um número razoável de pacotes que 
possam ter sido eliminados ou perdidos.
– Em contraste, um serviço de msg ponto a ponto pode ser 
descrito como não confiável se não houver garantia de que 
as mensagens são entregues.
 Quanto a integridade
– As msgs devem chegar não corrompidas e sem duplicação.
 Ordenação: 
– Garantia que as msgs sejam entregues na ordem de 
emissão
Comunicação através de sockets
● Socket é uma abstração que representa um ponto de destino 
para a comunicação entre processos.
● As duas formas de comunicação (UDP e TCP) usam socket.
● A comunicação consiste em transmitir uma mensagem entre um 
socket de um processo e um socket de outro processo.
● Para que um processo receba mensagens, seu socket deve 
estar vinculado a uma porta local e a um endereço IP do 
computador em que é executado.
● As msgs enviadas para um endereço IP e um número de porta 
em particular só podem ser recebidas por um processo cujo 
socket esteja associado a esse endereço e a esse número de 
porta.
Comunicação através de sockets
Origem Destino
mensagem
Outras portas
Porta conhecida
PP
socket
Porta cliente
socket
Comunicação através de sockets
 Diversos problemas devem ser resolvidos pelo programador;
– Representação de dados (heterogeneidade);
– Endereçamento (transparência da distribuição).
 Sockets são usados para dois processos (objetos) trocarem 
mensagens;
– Um computador é o SERVIDOR
 Abre o socket e escuta a espera de comunicações
– O outro computador é o CLIENTE
 Através de seu socket encaminha mensagem ao 
servidor para iniciar uma comunicação
Comunicação através de sockets
Device Driver e 
Hardware
IP
UDP TCP
socket
Aplicações
Comunicação através de sockets - 
UDP
● Datagramas UDP são transmitidos sem conexão e sem 
confiabilidade garantida
● Em caso de falhas, datagramas podem não chegar aos destinos
● Aspectos relevantes
● Tamanho da mensagem
● O processo destino precisa especificar um vetor de bytes de um tamanho 
específico para receber as mensagens.
● O protocolo IP permite datagramas de até 216 bytes (64KB)
● Entretanto, a maioria dos ambientes impõem uma restrição de 8KB.
● Aplicatico que exija msgs maiores do que o tamanho máximo, deve 
fragmentá-las em porções desse tamanho
● Bloqueio (comunicação assíncrona)
● Sockets UDP provêm send não-bloqueante e receive bloqueante
● Timeouts
● A recepção bloqueante é conveniente para servidores que estejam 
esperando por requisições dos seus clientes.
● Não é adequado esperar indefinidamente. Dar limites é uma boa estratégia.
Comunicação através de sockets 
– UDP – Modelo de Falhas
● Omissão
● Mensagens podem ser descartadas
● Pois pode ocorrer erros de soma de verificação (checksun) ou não 
haver espaço disponível no buffer, na origem ou destino
● Incluem omissão deenvio e omissão de recepção
● Ordenação
● Mensagens podem chegar fora da ordem
● Os aplicativos que usam datagramas UDP podem efetuar seus 
próprios controles para atingir a qualidade de comunicação 
confiável que suas finalidades exigem (Ex.uso de confirmação)
● Uso de UDP: 
● DNS (Domain Name Service) e VOIP (Voice Over IP)
Comunicação através de sockets 
– TCP
● Fluxos (streams) TCP são transmitidos com conexão e 
confiabilidade garantida.
● Aspectos relevantes
● Tamanhos de mensagens
● Quantidade de dados a tratar é definida dinamicamente pelo aplicativo.
● Mensagens perdidas
● TCP usa o esquema de confirmação (ACKs).
● Controle de fluxo
● Tenta combinar a velocidade dos processos que lêem e escrevem em um 
fluxo.
● Duplicação e ordenação de mensagens
● Identificadores são associados a cada mensagem.
● Destinos da mensagem
● Após o estabelecimento de conexão, os processos se comunicam sem a 
necessidade de endereços IP e portas.
Comunicação através de sockets 
– TCP
● A API para comunicação por fluxo pressupõe que, quando dois 
processos estão estabelecendo uma conexão, um deles 
desempenha o papel de cliente e o outro de servidor, mas daí em 
diante eles podem ser iguais.
● O papel de cliente envolve a criação de um socket de fluxo 
vinculado a qualquer porta e depois um pedido connect solicitando 
uma conexão a um servidor, em uma porta determinada.
● O servidor envolve a criação de um socket de “escuta”, vinculado a 
porta de serviço, para esperar que os clientes solicitem conexões.
● Quando o servidor aceita uma conexão, um novo socket de fluxo é 
criado para que o servidor se comunique com um cliente.
● Mantendo seu socket na porta de serviço para receber os pedidos 
de connect de outros clientes.
Comunicação através de sockets 
– TCP
● Quando um servidor aceita uma conexão, geralmente, 
uma nova thread é criada para a comunicação com o novo 
cliente
● O servidor pode bloquear quando estiver esperando dados, 
sem atrasar os outros clientes.
Origem Destino
connect
PP
socket
ServidorCliente
accept
Comunicação através de sockets 
– TCP – Modelo de Falhas
● Para garantir
● Integridade
● Somas de verificação para detectar e rejeitar pacotes corrompidos
● Número de seqüência para detectar e rejeitar pacotes duplicados
● Validade
● Timeouts e retransmissão para tratar com pacotes perdidos
● Em caso de queda da conexão
● Processos não distinguem entre falha na rede e falha no 
processo
● Processos não têm conhecimento se msgs recentes foram 
recebidas ou não.
● Uso de TCP:
● HTTP, FTP, SMTP e Telnet
Representação Externa de Dados 
e Empacotamento
● Informações armazenadas nos programas em execução são 
representadas como estruturas de dados
● Informações presentes nas mensagens são seqüências de 
bytes.
● Possibilidades para a representação de dados
● Valores convertidos para um formato externo, acordado entre as 
partes, e convertido para a forma local, na recepção.
● Valores transmitidos no formato da origem, junto com a informação 
do formato usado, e o destino converte os valores se necessário.
● Empacotamento (marshalling)
● Processo de pegar um conjunto de itens de dados e montá-los em 
uma forma conveniente para transmissão em uma mensagem.
● Compreende a tradução de itens de estruturas de dados e valores 
primitivos para uma representação externa de dados.
Representação Externa de Dados 
e Empacotamento
● CORBA CDR (Common Data Representation)
● Serialização de objetos em Java
● XML (eXtensible Markup Language)
RPC, RMI
Plataforma
Aplicações, Serviços
MiddlewareProtocolo baseado em 
requisição-resposta e 
Representação Externa de 
Dados e Empacotamento
Representação Externa de Dados 
e Empacotamento - CDR
● O CDR (Common Data Representation) do CORBA é a 
representação externa de dados definida pelo CORBA
● Os valores são transmitidos na ordem do remetente, que é 
especificada em cada mensagem.
● Se exigir uma ordem diferente, o destinatário a 
transforma.
● O empacotamento pode ser gerado automaticamente a 
partir da especificação dos tipos de ítens a serem 
transmitidos
● CORBA IDL (Interface Definition Language) descreve todos os 
tipos de estruturas de dados e de ítens de dados primitivos
Representação Externa de Dados 
e Empacotamento - Serialização
● Em Java RMI, tanto objetos como valores de dados primitivos 
podem ser passados como argumentos e resultados de 
invocações de método.
● Serialização em Java se refere à atividade de simplificar um 
objeto, ou um conjunto de objetos conectados, em uma forma 
seqüêncial conveniente para ser armazenada em disco ou 
transmitida numa mensagem.
● A desserialização consiste em restaurar o estado de um objeto 
ou conjunto de objetos a partir de sua forma serializada.
● Interface java.io.Serializable
● A serialização e a desserialização geralmente são executadas 
automaticamente pela camada de middleware, sem nenhuma 
participação do programador do aplicativo.
Representação Externa de Dados 
e Empacotamento - XML
● A XML (eXtensible Markup Languagem) é uma linguagem de 
marcação que foi definida pelo consórcio WWW para uso na 
web.
● O termo linguagem de marcação refere-se a uma codificação 
textual que representa um texto e os detalhes de sua estrutura 
ou de sua aparência.
● A linguagem XML é definida como o formato universal para 
dados estruturados na Web.
● A XML é usada para permitir que clientes se comuniquem com 
serviços web e para definir as interfaces e outras propriedades 
desses mesmos serviços;
● Usada também no arquivamento e na recuperação de sistemas;
● Embora um repositório XML possa ser maior que seu equivalente 
binário, ele tem a vantagem de poder ser lido em qualquer 
computador
Comunicação em Grupo
● Grupo: é um conjunto de processos que atuam juntos, de 
maneira especificada pelo sistema ou por um usuário;
● Os grupos geralmente são dinâmicos.
● Comunicação: Um-para-Muitos (Multicast ) ou Muitos-para-
Muitos (Broadcast)
● A comunicação em grupo é uma operação que permite o envio 
de uma mensagem para cada um dos membros de um grupo de 
processos;
● Assim, os membros participantes do grupo ficam totalmente 
transparentes para o remetente.
Comunicação em Grupo
● As mensagens em grupo fornecem uma infra-
estrutura útil para a construção de SD, com as 
características:
● Tolerância à falha baseada em serviços replicados;
● Localização dos servidores de descoberta na 
interligação em rede;
● Melhor desempenho através da replicação de dados;
● Propagação de notificações de evento.
Comunicação em Grupo
● Aspectos do Projeto
● Grupos Fechados x Grupos Abertos
● Grupos Igualitários x Hierárquicos
● Grupos Centralizado x Distribuído
Comunicação em Grupo
● Tipos de Grupos:
● Fechados: Somente os membros de um grupo podem enviar msg 
para o grupo.
● Abertos: Processos não pertencentes ao grupo podem enviar msg 
para o grupo.
● Estruturação Interna:
● Igualitário: Todos os processos são iguais. As decisões são tomadas 
coletivamente.
● Vantagem: Simétrico  nenhum ponto de falha;
● Desvantagem: A tomada de decisão é mais difícil.
● Hierárquico: Presença de um coordenador, cuja missão é dirigir o 
trabalho dos demais processos.
● Vantagem: Decisões rápidas;
● Desvantagem: Perda do coordenador para o grupo.
Comunicação em Grupo
● Controle dos Membros de um Grupo
● Deve existir algum método para criar e eliminar grupos, bem como 
para permitir que processos sejam incluídos ou excluídos de grupos:
● Centralizado
● Distribuído.
● Centralizado:
● Implementa um servidor de grupos, p/ o qual todas as solicitações 
devem ser enviadas.
● Servidor de Grupos:
● Cria e extingue grupos.
● Inclui e retira membros de grupos.
● Possui uma base de dados completa sobre todos os grupos e 
membros.
● Vantagem: Simples, eficiente e fácil de implementar;
● Desvantagem: Um único ponto de falha.
Comunicação em Grupo
● Distribuído:
● Todos os membros do grupo são responsáveis pela gerência.
● Para deixar um grupo, por exemplo, um membrosimplesmente envia uma mensagem a todos os demais 
membros do grupo.
● Vantagem: Não há um único ponto de falha, decisão mais 
democrática;
● Desvantagem: Maior complexidade na gerência, maior tempo 
nas tomadas de decisão.
Invocação Remota (resumo)
● RPC, Objetos Distribuídos e RMI
RPC: Remote Procedure Call
 Objetivos: 
– Permitir que os clientes chamem procedimentos localizados 
em outras máquinas (servidores);
 Fazer com que uma chamada remota se pareça tanto 
quanto possível com uma chamada local;
 Mascarar as diferenças de representação de dados
– Nenhuma operação de troca de mensagem ou de entrada/ 
saída deve ser visível ao programador (transparência).
 Serviço: 
– Pode ser visto como um módulo com uma interface que 
exporta um conjunto de procedimentos apropriados para 
operar sobre qualquer estrutura de dados ou recursos;
Modelo Básico
 Linguagem de Definição de Interface
– Características dos procedimentos: nome dos procedimentos, tipos 
de seus argumentos e valores de retorno.
– Compiladores de interfaces geram para diferentes linguagens alvo:
 Stubs: tratam cada procedimento definido na interface.
 Concretizam operações de serialização e deserialização dos 
dados.
Especificação do Serviço - IDL
Compilador
STUB
do Cliente
STUB
do Cliente
STUB
do Servidor
STUB
do Servidor
RPC: Remote Procedure Call
 Características das Interfaces IDL de RPCs
– Passagem de Parâmetros: passagens por valor e 
por referência em chamadas locais não são de 
todo muito apropriadas em SD: 
 Ponteiros não podem ser passados como 
argumento porque não tem sentido em espaços 
de endereçamentos diferentes.
– A definição de uma interface de servidor descreve 
parâmetros de entrada in e de saída out ou, às 
vezes, e com duplo sentido inout;
RPC em uma Aplicação Distribuída
Cliente
Ch
am
ada
Retorno
Servidor
Deserializaçãoreceive
Chamada
Re
tor
noSerialização Deserialização
sendreceive
REDE
Stub do
Cliente
Stub do
servidor
Serialização 
send
protocolo
request/reply
Despachante
Programa cliente chama o stub como uma chamada localStub do cliente constrói a mensagem que será enviada – 
marshaling dos argumentos, adiciona um identificador
Módulo de comunicação envia a mensagemDespachante: de acordo com o identificador seleciona um dos 
procedimentos da stub do servidor
Stub do servidor deserializa os argumentos e
chama o procedimento do servidor.
Servidor executa o procedimento e retorna o resultado para o stub
Stub do servidor serializa os argumentos de saída (out)
da resposta (reply).
Módulo de comunicação envia a mensagemStub do cliente deserializa a resposta e entrega ao cliente
Programação da Aplicação Distribuída
CompiladorCompilador CompiladorCompilador
Definições
em
Comum
Especificação do Serviço - IDLEspecificação do Serviço - IDLPrograma
Cliente
Programa
Servidor
(procedimentos)
STUB
do Cliente
STUB do 
Servidor
CompiladorCompilador
Servidor Executável
Cliente
Executável
Instalação e Funcionamento do RPC
 A instalação e funcionamento do RPC têm três fases básicas:
– Processamento da Interface: integrar os mecanismos de 
RPC com os programas cliente e servidor em uma 
linguagem convencional;
– Binding (ligação): localizar um servidor para um serviço 
particular;
– Serviço de Nomes onde os servidores se registram
– Comunicação: a comunicação entre programa cliente e 
programa servidor, usando Stubs que executam os 
marshaling e unmarshaling formando as 
requisições/respostas (modelo cliente/servidor) em nível 
mais baixo sobre protocolos de comunicação (rede);
RPC em uma Aplicação Distribuída
 RPC: Não é possível (ou não faz sentido) 
passar referencias de objetos como 
parâmetros;
 Solução:
– RMI: No modelo objeto distribuído temos então 
uma interface remota que especifica métodos de 
um objeto distribuído.
– A grande diferença da interface que usa RMI de 
um RPC é que objetos podem ser passados como 
argumentos e resultados de métodos.
– Referência remota de objetos.
RMI: Remote Method Invocation
Modelo Objeto
 Objetos: conjunto de métodos (operações) e dados que interagem 
entre si invocando métodos, passando argumentos e recebendo 
resultados.
– Para invocar um método, uma referência e o nome de um método 
devem ser apresentados, juntos com os argumentos necessários.
 Uma interface: define assinaturas de métodos (que são os tipos de 
seus argumentos, de seus valores de retorno e exceções) sem 
especificar suas implementações. 
– Uma classe pode suportar mais de uma interface.
 O estado de um objeto corresponde aos valores de suas variáveis de 
instância. No paradigma OO, o estado de um programa é particionado 
em estados de seus objetos. 
– A distribuição de objetos em hosts de um sistema distribuído é uma 
extensão natural ao modelo OO.
Conceitos base para RMI
 Remote Object Reference: Para chamar métodos (acessar) de um 
objeto remoto é necessária a referência do objeto remoto. 
– Encapsula todos os dados necessários para acessar o objeto.
– Referências remotas de objetos podem ser passadas como argumentos e 
resultados de invocações de métodos. 
 Interfaces Remotas: Interface que especifica métodos que podem ser 
invocados de um objeto remoto.
– Objetos locais e remotos podem chamar métodos de uma interface 
especificada como remota. 
– Interfaces não possuem construtores.
 CORBA possui uma IDL própria. 
 No JavaRMI interfaces remotas estendem a uma interface Remote. 
 Interfaces CORBA e Java suportam herança de interfaces. 
Modelo RMI
Cliente Servidor
Rede
Proxy
Objeto
Estado
Métodos
Mesma Interface
Skeleton
Invoca método X
Skeleton invoca
o método X no 
Objeto.
Passagem de Parâmetros (referências)
Máquina A
Objeto Local O1
Mensagem a ser enviada
para servidor C
Máquina B
Objeto Remoto O2
Máquina C
Nova referencia local
Cópia de O1
Invocação remota
com L1 e R1
referencia local L1
referencia remota R1
Cópia de R1 para O2
Estudo de caso: JavaRMI
 Estende o modelo de objetos Java fornecendo suporte para 
objetos distribuídos em Java. 
– Objetos invocam métodos em objetos remotos (RMI) usando 
a mesma sintaxe como em chamadas locais.
– Verificações de tipos e outras propriedades da linguagem 
são também verificadas em chamadas remotas como em 
locais.
 Uma chamada remota é perfeitamente identificada porque este 
deve manusear exceções remotas (RemoteExceptions).
 Interfaces remotas são definidas como extensão de uma 
interface Remote fornecida pelo pacote java.rmi.
Estudo de caso: JavaRMI
 Todas as assinaturas de métodos de uma interface 
possuem declarados RemoteException. 
– Todos os método remotos podem gerar esta exceção;
 Problemas com a conexão.
 Interfaces são compartilhadas entre clientes e servidores
interface Product extends Remote {
public String getDescription() throws 
RemoteException;
}
Estudo de caso: JavaRMI
 No lado do cliente para que a comunicação seja concretizada um stub 
(referência de objeto remoto) deve ser adiquirida:
Product p = ...;
String d = p.getDescription();
 No lado do servidor a classe que implementa a interface está presente:
public class ProductImpl extends UnicastRemoteObject 
Implements Product {
public ProductImpl (String d) throws RemoteException{
 descr = d;}
public String getDescription() throws RemoteException {
return “I am “ + descr + “. Buy me!”;}
 Classe UnicastRemoteObject usa TCP/IP e herda classe superior 
RemoteServer
– Mecanismos para comunicação entre objetos servidores e stubs 
remotos. 
Estudo de caso: JavaRMI
RMIregistry: binder para o Java RMI. 
– Instâncias do RMIregistry devem se executar sobre cada 
computador servidor que hospeda objetos remotos. 
 Este serviço não é um binder global que atenda toda a 
dimensão de um sistema: os clientes fazem seus lookups 
nos hosts dos serviços desejados.
– Mantém uma tabela mapeando nomes textuais em 
referências de objetos remotos sobre o computador. 
– Esta tabela é acessada por métodos da classe Naming,que 
possuem como argumentos uma URL da forma:
//computerName:port/objectName 
Estudo de caso: JavaRMI
 Servidor precisa se registrar se quiser exportar interfaces:
//servidor
ProductImpl p1 = new ProductImpl(“microondas”);
Naming.bind(“microondas”, p1)
 O código do cliente obtém o stub para acessar:
Product p =(Product) 
Naming.lookup(“rmi://seuservidor.com:1099/microondas”)
 As URLs de RMI começam com rmi:// e são seguidos de um 
endereço de servidor, um número de porta opcional (usa padrão 
1099), outra barra e o nome do objeto.
Servidor.java
rmic
Escreve servidor
Escreve interface
javac
Servidor_Proxy.class Servidor.class
RMIregistry
java Servidor
ServidorCliente
Servidor_Proxy.class
Escreve cliente
Cliente.java
javac
Cliente.class
java Cliente
Cliente Servidor
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53