APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar

Transcrição

1 - Aula 5 - PROGRAMAÇÃO DISTRIBUÍDA COM RMI 1 (Remote Method Invocation) 1. INTRODUÇÃO Sistemas distribuídos necessitam que aplicações, executando em vários espaços de endereçamento, normalmente em diferentes computadores, que sejam capazes de se comunicar. O endereçamento de equipamentos na Internet é baseado em um identificador que independe da tecnologia de rede envolvida, conhecido como endereço IP (Internet Protocol), cujo formato é o do exemplo a seguir: Este formato representa um número de 32 bits que, no modo normal de endereçamento da Internet, está associado a um único equipamento. Ele identifica a rede e o seu equipamento nela. Existe outro modo de endereçamento conhecido como multicasting, onde um endereço IP está associado a um grupo de computadores. O endereço IP permite apenas a localização de um dado equipamento na Internet. Para a localização de uma aplicação executando em um equipamento existe outro identificador conhecido como porta (Port). Esta localização é obtida através da associação da port com um dos protocolos de transporte Transmission Control Protocol (TCP) ou User Datagram Protocol (UDP). Essa tríade composta por endereço IP, número de port e protocolo de transporte é conhecida como socket (Cyclades Brasil, 1996). Apesar do socket ser flexível o suficiente para comunicação em geral, ele requer do cliente e do servidor o conhecimento dos protocolos para troca de mensagens, isto é, a codificação e decodificação destas mensagens. O projeto destes protocolos é sempre difícil e susceptível a erros. Assim, o Java suporta o conceito de invocação de método remoto (Remote Method Invocation - RMI) permitindo uma abstração maior ao desenvolvedor que não precisa se preocupar com o mecanismo de comunicação entre cliente e servidor. 2. RMI Basicamente o RMI é um RPC (Chamada de Procedimentos Remotos), que ao invés de realizar chamadas a procedimento remotos realiza chamadas a métodos de um objeto remoto. Um objeto remoto é aquele que se localiza em uma JVM (Java Virtual Machine) diferente daquela em que se encontra o cliente, potencialmente em outro computador. Um objeto remoto é descrito por uma ou mais interfaces escritas na própria linguagem de programação Java. Por se tratar de um objeto remoto estas interfaces são chamadas de interfaces remotas. A invocação de um método de um objeto remoto tem a mesma sintaxe que a invocação de um método de um objeto local. O cliente quando invoca um objeto não sabe se esse objeto é local ou remoto em relação a ele. O RMI providencia a: 1 RMI nada mais é que a Invocação de Métodos Remotamente, ou seja, permite a execução de chamadas remotas em aplicações desenvolvidas na linguagem Java. 1

2 Localização (binding) de um método de um objeto remoto. Comunicação através de uma conexão de rede confiável permitindo a transmissão de requisições e respostas, funcionando como um canal entre cliente e servidor. Interface com usuário convertendo uma chamada de método em um bloco de dados (mensagem) que possa trafegar através da conexão e remontando a mesma chamada de método no outro extremo (remoto) a partir desta mensagem. São necessários códigos nos pontos finais da conexão para deixar transparente o uso do RMI pelo usuário. No lado cliente, um stub tem a mesma assinatura (nome, argumentos e tipo de retorno) que o método remoto e sua função é empacotar os argumentos em uma mensagem para ser enviada através do canal de comunicação. Quando uma mensagem contendo os resultados enviados pelo servidor surgir neste canal, o stub extrai o valor de retorno antes de passá-lo para o código que chamou o método. O complemento do stub, localizado no lado do servidor, é chamado de skeleton. Sua função é converter as mensagens que chegam pelo canal de comunicação em argumentos e chamar as implementações dos métodos requisitados. Quando o método termina a execução, o valor de retorno é convertido em uma mensagem que é remetida ao stub do cliente. A arquitetura em que se baseia o RMI consiste de três camadas: Camada stub/skeleton Camada de referência remota (remote reference) Camada de transporte Elas são independentes entre si e podem ser substituídas por diferentes implementações sem que uma afete a outra. Por exemplo, pode-se substituir a camada de transporte implementada em TCP, usando socket Java, por outra baseada em UDP. 2

3 3. CAMADA STUB/SKELETON A camada stub/skeleton é a interface entre a aplicação e as outras camadas que compõem o RMI. Esta camada não trata do transporte em si, mas é responsável por transmitir os dados para a camada de referência remota como um stream de dados. Esse stream chamado de marshal stream emprega o mecanismo de serialização de objeto (object serialization). Este mecanismo permite que numa invocação (local ou remota) objetos Java possam ser passados como argumentos ou retornados como resultado da execução de métodos. Os objetos Java, transmitidos através deste sistema de serialização de objetos, são passados por cópia entre espaços de endereçamento diferentes, isto é, máquinas diferentes. Caso já sejam objetos remotos, eles serão repassados por referência, onde referência de um objeto remoto é a referência de uma instância desse objeto. A serialização de objeto é específica da linguagem Java, assim, tanto clientes quanto servidores devem estar escritos em Java (Albuquerque, 1998). Quando um cliente invoca um método de um objeto remoto, os parâmetros do método são convertidos em um bloco de dados (mensagem) pelo stub e esta mensagem é enviada a máquina remota utilizando o protocolo, por exemplo, TCP/IP. Quando a mensagem chega à máquina remota, o skeleton transforma esta mensagem em argumentos e chama a implementação do método convertendo o resultado em uma mensagem que é redirecionada a máquina cliente, cujo stub é responsável pela extração do valor de retorno. O stub que se localiza no lado cliente contém todas as interfaces suportadas pela implementação do objeto remoto, sendo responsável por (Java, 1999): Iniciar a chamada do objeto remoto (acionando a camada de referência remota). Fazer o marshaling dos argumentos, utilizando o mecanismo de serialização de objeto, que será enviado para a camada de referência remota. Informar à camada de referência remota que a chamada pode ser invocada. Fazer o unmarshaling do valor de retorno ou exceção obtido. Informar à camada de referência remota que a chamada foi completada. O skeleton que se localiza no lado servidor contém um método que envia as chamadas recebidas do cliente para a implementação do objeto remoto, sendo responsável por (Java, 1999): Fazer o unmarshaling dos argumentos recebidos. Realizar a chamada da implementação do objeto que executará o serviço requerido pelo cliente remoto. Fazer o marshaling do valor de retorno ou da situação de exceção, caso ocorra, utilizando o mecanismo de serialização de objeto que será enviado para a origem da chamada. As classes dos stubs e skeletons apropriadas são determinadas em tempo de execução e carregadas dinamicamente quando necessárias para atender uma requisição do cliente. 4. CAMADA DE REFERÊNCIA REMOTA A camada de referência remota lida com a interface de transporte de baixo nível por meio de um protocolo. Esse protocolo é independente do stub do cliente e skeleton do servidor. 3

4 O stub e skeleton desconhecem os diversos tipos de protocolo que um servidor pode utilizar. Existem vários protocolos que podem ser especificados e executados por esta camada, tais como (Java, 1999): Servidores suportam somente invocação ponto-a-ponto, onde um cliente interage com um único objeto. Servidores suportam replicação, onde um número de objetos remotos replicados precisam se manter sincronizados sempre que uma instância é modificada. Objetos remotos não estão continuamente ativos, sendo somente carregados do disco quando um cliente invoca um de seus métodos. Este protocolo pode ser selecionado pelo usuário que escolhe como a camada de referência será utilizada. Atualmente, a implementação da camada de referência está restrita a invocação ponto-a-ponto, onde um cliente interage com um único objeto (não replicado) cuja referência é somente válida quando o processo servidor está executando. A classe que implementa esse protocolo é a java.rmi.server.unicastremoteobject. 5. CAMADA DE TRANSPORTE A camada de transporte manipula os detalhes da conexão e providencia um canal de comunicação entre as JVM s executando o código cliente e código servidor. O lado cliente deve possuir a interface do objeto remoto para poder referenciá-lo, enquanto o lado servidor possui a implementação do mesmo. Em geral, esta camada é responsável por (Java, 1999): Estabelecer conexões entre espaços de endereçamentos remotos, isto é, entre JVM s diferentes. Gerenciar conexões. Monitorar conexões (se elas existem ou não (liveness)). Escutar chamadas que estejam sendo recebidas. Manter uma tabela que contém os objetos remotos residentes num determinado espaço de endereçamento. Estabelecer a conexão para as chamadas que estejam sendo recebidas. Localizar o alvo de uma chamada remota passando a conexão para quem a chamou. 6. APLICAÇÕES UTILIZANDO RMI O RMI utilizando a facilidade de nomeação (rmiregistry), implementa um objeto servidor de nomes que mantém registrados todos os objetos localizados num host com os seus respectivos nomes, tornando acessível a referência desses objetos ao cliente. Uma aplicação cliente típica para invocar métodos de um objeto remoto deve obter primeiro a referência desse objeto. Essa referência é passada ao servidor que localizará a implementação do objeto. O RMI trata os detalhes de comunicação entre cliente e servidor, assim, o cliente vê a invocação de um método de um objeto remoto como a de um objeto local. 4

5 Na figura acima um cliente RMI (a) utiliza o sistema de registro para obter a referência de um objeto remoto, após obtida, invoca os seus métodos (b). Caso seja necessário o RMI pode, se o cliente autorizar, utilizar o servidor web para localizar e carregar objetos remotos, isto é, classes Java em bytecodes. Para o carregamento pode-se utilizar qualquer protocolo Uniform Resource Locator (URL) suportado pelo sistema Java, por exemplo, HTTP, FTP, file, etc. Essas classes podem ser carregadas para serem executadas no servidor ou no cliente. Em aplicações que utilizam RMI, o método é executado na máquina onde se encontra o objeto sobre o qual ele atua. O objeto pode estar tanto em uma máquina diferente daquela onde se encontra o cliente quanto na mesma máquina. 7. CARREGAMENTO DINÂMICO DE STUB Em sistemas onde se utiliza o RPC, o código do stub deve ser gerado e linkado junto ao cliente antes de sua execução. Este código pode ser linkado estaticamente ou linkado dinamicamente em tempo de execução, utilizando para isso bibliotecas disponíveis localmente ou na rede. Em ambos os casos, o código que realiza o RPC deve estar disponível, na forma compilada, na máquina do cliente. O RMI generaliza essa técnica de carregar o código do stub em tempo de execução. Essa generalização do carregamento dinâmico do stub (dynamic stub loading) utiliza-se da capacidade do Java de realizar downloading de código. Tipicamente, o stub é carregado dinamicamente do sistema de arquivos locais, neste caso, o gerenciador de segurança não apresenta restrições. Entretanto, quando ele é carregado da rede, suas classes passam pelo gerenciador de segurança, prevenindo, assim, problemas potenciais de segurança (Java, 1999). O carregamento do stub, de forma dinâmica, é utilizado somente quando um cliente necessita de um determinado stub não disponível. Neste esquema, o código do stub (lado cliente) suporta o mesmo conjunto de interfaces remotas da implementação da classe que o gerou. Esse código do stub, residente num servidor host ou em qualquer outra localização, será enviado ao cliente sob demanda (downloaded). Para uma implementação remota, esse código pode ser 5

6 gerado em tempo real (on-the-fly) no lado remoto e enviado para o cliente ou pode ser gerado no lado cliente através de uma lista de interfaces suportadas pela implementação remota. O carregamento dinâmico do stub emprega o carregador de classes do Java, o gerenciador de segurança e a serialização de objeto (Java, 1999). Quando a referência de um objeto remoto for passada como parâmetro ou como resultado de uma chamada de método, o marshal stream, que transmite essa referência, incluirá também a informação de onde carregar a classe do stub para o objeto remoto (o URL, se ele for conhecido). Assim, quando a referência de objeto remoto for unmarshaled no destino, o marshal stream poderá localizar e carregar o código do stub (via carregador de classe e verificado pelo gerenciador de segurança) de tal forma que o cliente tenha disponibilizado o stub correto. 8. COMUNICAÇÃO DE OBJETOS DISTRIBUÍDOS 1. O objeto A faz a chamada do método desejado no Stub; 2. O Stub converte a chamada em protocolo RMI e envia pela Rede; 3. A requisição é enviada pela rede 4. O Skeleton recebe a requisição em RMI e reconhece qual método deve ser chamado; 5. Chama o método desejado no Objeto B; 6. Recebe o retorno do método; 7. Envia a o objeto de Retorno para o Cliente; 8. O Stub recebe o retorno; 9. O Stub repassa o retorno para o Objeto A; 9. PROCEDIMENTOS DE PROGRAMAÇÃO 1. Escrever Interface remota; 2. Implementar a Interface; 3. Implementar Servidor que contém a Implementação da interface remota; 4. Gerar Stub e Skeleton da Interface; 5. Registrar Servidor e Disparar Servidor; 6. Escrever Cliente que utiliza métodos da Interface; 6

7 10. IMPLEMENTAÇÃO a. Escrevendo a Interface Remota import java.rmi.remote; import java.rmi.remoteexception; public interface Hello extends java.rmi.remote { public String msg() throws RemoteException; b. Implementando a Interface import java.rmi.*; import java.rmi.server.unicastremoteobject; public class HelloImpl extends UnicastRemoteObject implements Hello { private String message; public HelloImpl (String msg) throws java.rmi.remoteexception { super(); message = msg; public String msg() throws RemoteException { return message; c. Implementando o Servidor que contém a Implementação da interface remota import java.rmi.*; public class Server { public static void main (String[] argv) { try { Naming.rebind("Hello", new HelloImpl ("Hello world!")); System. out.println ("Hello Servidor está funcionando"); catch (Exception e) { System.out.println ("Hello Server failed: " + e); e.printstacktrace(); d. Gerando Stub e Skeleton da Interface javac *.java rmic v1.1 HelloImpl 7

8 e. Registrando e Disparando o Servidor rmiregistry (linux) start rmiregistry (windows) (porta default = 1099) java Server (executar o servidor) f. Escrevendo o Cliente que utiliza os métodos da Interface import java.rmi.*; public class Cliente { public static void main(string[] argv) { try { Hello hello = (Hello) Naming.lookup("//localhost/Hello"); System.out.println(hello.msg()); catch (Exception e) { System.out.println("HelloClient exception: " + e); g. Gerando e Executando o Cliente javac Cliente.java java Cliente 7. REFERÊNCIAS Tutorial RMI. < Andleigh, P. K.; Gretzinger, M. R. Distributed object-oriented data-systems design. New Jersey: Prentice-Hall, Cyclades Brasil. Guia Internet de conectividade. São Paulo, DEITEL, H. M.; Deitel, P. J. Java how to program. New Jersey: Prentice-Hall, COSTA, Samira Rachid da. Objetos distribuídos: conceitos e padrões. Dissertação de Mestrado