• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Sistemas Distribuídos - Comunicação Distribuída - RMI
 

Sistemas Distribuídos - Comunicação Distribuída - RMI

on

  • 3,469 views

 

Statistics

Views

Total Views
3,469
Views on SlideShare
3,469
Embed Views
0

Actions

Likes
3
Downloads
132
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Sistemas Distribuídos - Comunicação Distribuída - RMI Sistemas Distribuídos - Comunicação Distribuída - RMI Presentation Transcript

    • Comunicação Distribuída - RMI Prof. Adriano Teixeira de Souza
    •  Estratégias diferentes que permitem a comunicação entre aplicações distribuídas. Tipos distintos de comunicação em um sistema distribuído: ◦ Sockets ◦ RMI - Remote Method Invocation ◦ CORBA – Commom Object Request Broker Architecture ◦ EJB – Enterprise Java Bean ◦ Web Services Prof. Adriano Teixeira de Souza
    • • RMI é um Midleware que fornece serviços para criação de aplicações Java Distribuídas.• Ele disponibiliza apenas um único serviço, o Serviço de Nomes• Entretanto, a principal função de RMI é permitir que métodos de objetos remotos sejam chamados de forma tão transparente como se os objetos estivessem localmente (tanto quanto possível)• Todas as características de uma chamada de método (nome, lista de parâmetros, valores de retorno e lista de exceções) são fornecidas por RMI• As chamadas de RMI são realizadas de forma síncrona Prof. Adriano Teixeira de Souza
    • • RMI utiliza Sockets Java por baixo dos panos• Visto que Sockets usam TCP, RMI utiliza TCP, se beneficiando de todas as qualidades do protocolo• Um cliente RMI utilizará um proxy da referencia remota para chamar os métodos• O proxy é chamado de STUB• O STUB não é codificado pelo programador• Usamos um aplicativo chamado rmic para criar o STUB Prof. Adriano Teixeira de Souza
    • • Toda classe que deverá ter métodos remotamente chamados por RMI, deverá ter um Stub• O cliente possuirá uma instância do Stub, a qual receberá as chamadas do cliente e as enviará pela rede (usando Marshaling e Unmarshaling) Prof. Adriano Teixeira de Souza
    •  São sistemas capazes de localizar um componente associado pelo nome desse componente. Exemplos de serviços de nomes são: ◦ DNS – Domain Name Service ◦ JNDI – Java Naming and Directory Interface ◦ RMIRegistry ◦ Corba Service Name Prof. Adriano Teixeira de Souza
    •  RMIRegistry é o serviço de nomes de RMI Utilizamos para localizar instâncias de objetos remotos Java numa rede Existem várias formas de iniciar o RMIRegistry, uma delas é utilizando o aplicativo rmiregistry.exe, do diretório bin do jdk Existem outras formas melhores, via programação, que utilizaremos Prof. Adriano Teixeira de Souza
    •  Definindo a Remote Interface Codificando Remote Class Gerando o Stub Criando o Remote Server Codificando o Cliente Executando todos os programas Prof. Adriano Teixeira de Souza
    •  Tudo que um cliente sabe do objeto remoto é a sua interface. Nós definimos uma interface com os métodos que queremos chamar remotamente Esta interface, que chamamos de Interface Remota, deverá extender a interfacejava.rmi.Remote Remote não possui métodos Todos os métodos da Interface que criamos (a Interface Remota) deverão declarar que lançamjava.rmi.RemoteException Os métodos da Interface Remota poderão lançar outras exceções, específicas do método Prof. Adriano Teixeira de Souza
    • Prof. Adriano Teixeira de Souza
    • • A classe da referência remota deverá implementa nossa Interface Remota• Além disso, deverá extenderjava.rmi.server. UnicastRemoteObject• Observe que o objeto remoto poderá ter outros métodos que não constem na Interface Remota• Logicamente, esses métodos não estarão disponíveis remotamente, mesmo que sejam public Prof. Adriano Teixeira de Souza
    • Prof. Adriano Teixeira de Souza
    •  Algumas vezes, nos deparamos com o seguinte warning:The serializable class Cliente does not declare a static final serialVersionUID field of type long O serialVersionUID é utilizado para validar se a classe que a JVM conhece é compatível com o objeto que vem serializado. Se os serialVersionUID forem diferentes, será lançada um java.io.InvalidClassException Toda classe serializável possui um serialVersionUID, que pode ser codificado pelo programador ou gerado pelo compilador Diferenças entre compiladores podem gerar serialVersionUID diferentes para a mesma classe Então java avisa para você que o melhor é você gerar um serialVersionUID Prof. Adriano Teixeira de Souza
    • • O QuickFix do Eclipse poderá ajudar a gerar um serialVersionUID para a classe Serializable Prof. Adriano Teixeira de Souza
    •  Como já foi dito, o STUB é o representante do objeto remoto É o STUB que receberá as chamadas de método do cliente, enviando elas para o objeto remoto, via rede, usando java sockets Entre outras coisas, o Stub é responsável por serializar os parâmentros, enviá-los via rede, receber o bytes com valores de retorno ou exceções lançadas e reestruturar tudo em objetos java, devolvendo para o cliente o resultado Codificar o Stub é uma tarefa ingrata, ainda bem que existe um programa chamado rmic que faz isso para o programador! Prof. Adriano Teixeira de Souza
    •  O rmic é um programa de linha de comando que fica na pasta bin do jdk. Um exemplo de chamada do rmic é:C:Documents and Settingsluiz carlosworkspace> C:Arquivos de programasJavajdk1.5.0_06binrmic jornada.server.ServidorClientes –v1.2 –keep Aonde o –v1.2 é uma flag para definir a versão do protocolo rmi utilzado e –keep é a flag para manter o código fonte do stub gerado Se tudo ocorrer corretamente, será criado no mesmo pacote de jornada.server.ServidorClientes um stub para ser utilizado por um cliente remoto chamadojornada.server.ServidorClientes_Stub Prof. Adriano Teixeira de Souza
    • • Entende-se como Remote Server a classe que irá instanciar e publicar o Remote Object, usando o RMIRegistry• É comum fazer com que a própria classe do RemoteObject tenha as responsabilidades do Remote Server• Por exemplo, codificando o método main: Prof. Adriano Teixeira de Souza
    • • A interface java.rmi.registry.Registry representa um objeto que possui métodos para armazenar e encontrar referencias remotas ligadas a nomes• Normalmente, usamos o método bind (ou rebind) para ligar um nome a uma referencia remota• A classe java.rmi.registry.LocateRegistry é utilizada para obtermos referencias para Registry´s• java.rmi.registry.LocateRegistry possui vários métodos para formas diferentes de se obter um Registry• O acesso a objetos remotos, incluindo Registry´s, pode ser dificultado por políticas de seguranças locais ou de redes. Prof. Adriano Teixeira de Souza
    • • O cliente é a classe que utilizará os métodos do objeto remoto• Antes de fazer isso, ele terá que obter a referência para o Stub do objeto remoto. Para isso, ele utilizará o serviço de nomes de RMI• No exemplo a seguir, utilizamos o método estático lookup da classe java.rmi.Naming para localizar o Stub• Observe que localhost aponta para a máquina local, se o serviço de nomes estiver sendo executado em outra máquina, será necessário substituir localhost pelo nome do host ou número IP Prof. Adriano Teixeira de Souza
    • • Após isso, o cliente poderá chamar os métodos do Objeto Remoto da mesma forma como eles fossem métodos de uma instância local: Prof. Adriano Teixeira de Souza
    • • Para executar o exemplo, basta executar os métodos main de cada classe (comece pelo servidor!) Prof. Adriano Teixeira de Souza