5.1 Programação com objetos distribuídos

Na programação distribuída usando a arquitetura cliente-servidor, clientes e servidores podem ser implementados usando qualquer paradigma de programação. Assim, é possível que um serviço específico seja executado por um método de algum objeto. No entanto, mesmo que o cliente também tenha sido desenvolvido orientação a objetos, na comunicação entre o cliente e o servidor esse paradigma deve ser esquecido, devendo ser utilizado algum protocolo pré-estabelecido de troca de mensagens para a solicitação e resposta ao serviço.

Um sistema de objetos distribuídos é aquele que permite a operação com objetos remotos. Dessa forma é possível, a partir de uma aplicação cliente orientada a objetos, obter uma referência para um objeto que oferece o serviço desejado e, através dessa referência, invocar métodos desse objeto — mesmo que a instância desse objeto esteja em uma máquina diferente daquela do objeto cliente.

O conceito básico que suporta plataformas de objetos distribuídos é o conceito de arquiteturas de objetos. Essencialmente, uma arquitetura orientada a objetos estabelece as regras, diretrizes e convenções definindo como as aplicações podem se comunicar e inter-operar. Dessa forma, o foco da arquitetura não é em como a implementação é realizada, mas sim na infra-estrutura e na interface entre os componentes da arquitetura.

Na plataforma Java, dois mecanismos são oferecidos para o desenvolvimento de aplicações usan- do o conceito de objetos distribuídos: Java RMI e Java IDL. RMI (invocação remota de métodos) é um mecanismo para desenvolver aplicações com objetos distribuídos que opera exclusivamente com objetos Java. Java IDL utiliza a arquitetura padrão CORBA para integração de aplicações Java a aplicações desenvolvidas em outras linguagens.

5.1.1Arquiteturas de objetos distribuídos

No paradigma de arquiteturas de objetos, há três elementos principais. A arquitetura OO forne- ce uma descrição abstrata do software — que categorias de objetos serão utilizadas, como estarão particionados e como interagirão. As interfaces distribuídas são as descrições detalhadas das fun- cionalidades do software. Finalmente, a implementação é composta por módulos de software que suportam as funcionalidades especificadas nas interfaces distribuídas.

O uso de interfaces distribuídas permite isolar a arquitetura de um sistema de sua implementa- ção. Dessa forma, o sistema pode ser construído com um alto grau de independência em relação às implementações específicas de suas funcionalidades, ou seja, é possível substituir implementações específicas com pequeno impacto sobre o sistema como um todo.

A adoção do paradigma de arquitetura de objetos permite também atingir um alto grau de inter- operabilidade através da adoção de uma infra-estrutura padronizada de comunicação entre objetos através das interfaces. Assim, cada componente da arquitetura deve se preocupar apenas em como se dará sua comunicação com a infra-estrutura de comunicação, estabelecida através de um objeto wrapper. Sem essa padronização, seria necessário estabelecer os mecanismos de comunicação com todos os demais componentes do sistema.

Em uma arquitetura de objetos, alguma forma deve ser estabelecida para que clientes possam localizar serviços que estão sendo oferecidos. Isso é usualmente oferecido na forma de um serviço básico da plataforma de objetos distribuídos. Do ponto de vista de quem oferece o serviço, é preciso habilitar o objeto para que seus métodos possam ser invocados remotamente. Isto é realizado através das seguintes atividades:

Descrever o serviço. Na arquitetura de objetos, a descrição ou especificação de serviços é determi- nada através das interfaces. Em Java, isto é realizado através da especificação oferecida por uma interface.

Implementar o serviço. Isto é realizado através do desenvolvimento de uma classe Java que imple- mente a interface especificada.

Anunciar o serviço. Quando um objeto que implementa o serviço torna-se ativo, é preciso que ele seja registrado em um “diretório de serviços” de forma que potenciais clientes possam localizá- lo.

Sob o ponto de vista do objeto cliente, que vai usar o serviço do objeto remoto, é preciso localizar o serviço, o que é feito acessando o registro de serviços. Portanto, é necessário que servidores e clientes estejam de acordo com o local (a máquina) onde o registro é realizado. Como resultado dessa tarefa, obtém-se uma referência ao objeto remoto que pode ser utilizada como se fosse uma referência para o objeto local.

A utilização desse mecanismo de localizar o serviço através de um diretório ou registro permite que as máquinas clientes ignorem totalmente em que máquinas os serviços solicitados estão operando

— uma facilidade conhecida como transparência de localização.

Um dos principais objetivos em uma plataforma de objetos distribuídos é atingir transparência de localização, tornando uniforme a forma de utilização de objetos independentemente desses objetos estarem na máquina local da aplicação ou em máquinas distintas.

A fim de que se atinja transparência de localização, as seguintes funcionalidades devem ser ofe- recidas:

1. Localizar e carregar classes remotas;

2. Localizar e obter referências a objetos remotos; e

3. Habilitar a invocação de métodos de objetos remotos.

A primeira funcionalidade, não muito diferente do que ocorre em sistemas com objetos locais, é necessária para que a aplicação conheça as facilidades oferecidas pelo objeto remoto.

Referências a objetos também são utilizadas em sistemas com objetos locais, porém com diferen- ças significativas. Em um sistema local, as referências a objetos são tipicamente manipuladores com especificação de endereços de memória. No caso de objetos remotos, esses endereços da memória de outra máquina não têm validade na máquina local. Assim, é preciso oferecer mecanismos que traduzam essas referências entre máquinas de forma transparente para o programador.

Para a invocação de métodos de um objeto remoto, além da necessidade de se localizar a refe- rência ao método é preciso oferecer mecanismos para tornar transparente a passagem de argumentos para e o retorno de valores desde o método.

Além dessas funcionalidades, a comunicação de falhas no oferecimento da transparência de loca- lização ao programador é essencial. Assim, funcionalidades para comunicar exceções entre máquinas também dever ser suportadas pela plataforma de objetos distribuídos.

5.1.2Java RMI

RMI (Remote Method Invocation) é uma das abordagens da tecnologia Java para prover as funci- onalidades de uma plataforma de objetos distribuídos. Esse sistema de objetos distribuídos faz parte do núcleo básico de Java desde a versão JDK 1.1, com sua API sendo especificada através do pacote java.rmi e seus subpacotes.

Através da utilização da arquitetura RMI, é possível que um objeto ativo em uma máquina virtual

Java possa interagir com objetos de outras máquinas virtuais Java, independentemente da localização dessas máquinas virtuais.

A arquitetura RMI oferece a transparência de localização através da organização de três camadas entre os objetos cliente e servidor:

1. A camada de stub/skeleton oferece as interfaces que os objetos da aplicação usam para interagir entre si;

2. A camada de referência remota é o middleware entre a camada de stub/skeleton e o protocolo de transporte. É nesta camada que são criadas e gerenciadas as referências remotas aos objetos;

3. A camada do protocolo de transporte oferece o protocolo de dados binários que envia as soli- citações aos objetos remotos pela rede.

Desenvolvimento da aplicação RMI

No desenvolvimento de uma aplicação cliente-servidor usando Java RMI, como para qualquer plataforma de objetos distribuídos, é essencial que seja definida a interface de serviços que serão oferecidos pelo objeto servidor.

A especificação de uma interface remota é equivalente à definição de qualquer interface em Java, a não ser pelos seguintes detalhes: a interface deverá, direta ou indiretamente, estender a interface Remote; e todo método da interface deverá declarar que a exceção RemoteException (ou uma de suas superclasses) pode ser gerada na execução do método.

Esse exemplo ilustra a definição de uma interface remota para um objeto que contém um contador inteiro:

1. import java.rmi.*;

2. public interface Count extends Remote {

3. void set(int val) throws RemoteException;

4. void reset() throws RemoteException;

5. int get() throws RemoteException;

6. int increment() throws RemoteException;

7       }

Esse contador é manipulado por quatro métodos: set(), para definir um valor inicial para o conta- dor; reset(), para reiniciar o contador com o valor 0; get(), para consultar o valor do contador sem alterá-lo; e increment(), que lê o valor atual do contador e incrementa-o.

Os serviços especificados pela interface RMI deverão ser implementados através de uma clas- se Java. Nessa implementação dos serviços é preciso indicar que objetos dessa classe poderão ser acessados remotamente.

A implementação do serviço se dá através da definição de uma classe que implementa a inter- face especificada. No entanto, além de implementar a interface especificada, é preciso incluir as funcionalidades para que um objeto dessa classe possa ser acessado remotamente como um servidor. A implementação da interface remota se dá da mesma forma que para qualquer classe imple- mentando uma interface Java, ou seja, a classe fornece implementação para cada um dos métodos

especificados na interface.

As funcionalidades de um servidor remoto são especificadas na classe abstrata RemoteServer, do pacote java.rmi.server. Um objeto servidor RMI deverá estender essa classe ou, mais especificamente, uma de suas subclasses. Uma subclasse concreta de RemoteServer oferecida no mesmo pacote é UnicastRemoteObject, que permite representar um objeto que tem uma única implementação em um servidor (ou seja, não é replicado em vários servidores) e mantém uma conexão ponto-a-ponto com cada cliente que o referencia.

Tipicamente, a declaração de uma classe que implementa um servidor remoto RMI terá a forma

public class ... extends UnicastRemoteObject implements ... {

...

}

Esse exemplo oferece uma possível implementação para a interface remota previamente especi- ficada:

1

import java.rmi.*;

2

import java.rmi.server.UnicastRemoteObject;

3

public class CountImpl extends UnicastRemoteObject

4

implements Count {

5

private int sum;

6

public CountImpl() throws RemoteException  {

7

}

8

public  void set(int val) throws RemoteException

{

9

sum = val;

10

}

11

public  void reset() throws RemoteException {

12

sum = 0;

13

}

14

public int get() throws RemoteException {

15

return sum;

16

}

17

public int increment() throws RemoteException {

18

return sum++;

19

}

20

}

Clientes e servidores RMI

Uma vez que a interface remota esteja definida e a classe que implementa o serviço remoto tenha sido criada, o próximo passo no desenvolvimento da aplicação distribuída é desenvolver o servidor

RMI, uma classe que crie o objeto que implementa o serviço e cadastre esse serviço na plataforma de objetos distribuídos.

Um objeto servidor RMI simples deve realizar as seguintes tarefas: criar uma instância do objeto que implementa o serviço; e disponibilizar o serviço através do mecanismo de registro.

O desenvolvimento de um cliente RMI requer essencialmente a obtenção de uma referência remo- ta para o objeto que implementa o serviço, o que ocorre através do cadastro realizado pelo servidor. Uma vez obtida essa referência, a operação com o objeto remoto é indistingüível da operação com um objeto local.

Usando o serviço de nomes

O aplicativo rmiregistry faz parte da distribuição básica de Java. Tipicamente, esse aplica- tivo é executado como um processo de fundo (em background) que fica aguardando solicitações em uma porta, que pode ser especificada como argumento na linha de comando. Se nenhum argumento for especificado, a porta 1099 é usada como padrão.

O aplicativo rmiregistry é uma implementação de um serviço de nomes para RMI. O serviço de nomes é uma espécie de diretório, onde cada serviço disponibilizado na plataforma é registrado através de um nome do serviço, uma string única para cada objeto que implementa serviços em RMI. Para ter acesso ao serviço de nomes a partir de uma classe Java, são oferecidos dois mecanismos básicos. O primeiro utiliza a classe Naming, do pacote java.rmi. O segundo mecanismo utiliza

as facilidades oferecidas através das classes no pacote java.rmi.registry.

A classe Naming permite a realização da busca de um serviço pelo nome (lookup) usando o método estático lookup(String nome), que retorna uma referência para o objeto remoto. O serviço de registro aonde a busca se realiza é especificado pela string usando uma sintaxe similar à URL:

rmi://objreg.host:port/objname

O protocolo padrão é rmi, sendo no momento o único suportado através desse método. Se não especificado, o host é a máquina local e a porta é 1099. O nome de registro do objeto é a única parte obrigatória desse argumento.

Além de lookup() os métodos bind(), rebind(), unbind() e list(), descritos na seqüência, são também suportados.

Outra alternativa para ter acesso ao serviço de nomes a partir da aplicação Java é utilizar as funcionalidades do pacote java.rmi.registry, que oferece uma classe e uma interface para que classes Java tenham acesso ao serviço de nomes RMI.

A interface Registry representa uma interface para o registro de objetos RMI operando em uma máquina específica. Através de um objeto dessa classe, é possível invocar o método bind() que associa um nome de serviço (um String) ao objeto que o implementa.

Para obter uma referência para um objeto Registry são utilizados os métodos da classe Lo- cateRegistry, todos estáticos, tais como getRegistry(). Há quatro versões básicas desse método:

1. getRegistry(): obtém referência para o registro local operando na porta default;

2. getRegistry(int port): obtém referência para o registro local operando na porta es- pecificada;

1. getRegistry(String host): obtém referência para o registro remoto operando na por- ta default;

2. getRegistry(String host, int port): obtém referência para o registro remoto operando na porta especificada.

O método estático createRegistry(int port) pode ser utilizado para iniciar um servi- ço de registro na máquina virtual Java corrente na porta especificada como argumento, retornando também um objeto da classe Registry.

Inicialmente, é preciso obter uma referência para o serviço de registro, através da invocação do método:

Registry r = LocateRegistry.getRegistry();

Observe que a referência para Registry é em si uma referência para um objeto remoto, uma vez que a interface Registry é uma extensão da interface Remote.

Uma vez que a referência para o serviço de registro tenha sido obtida, é possível acessar as funcionalidades desse serviço através dos métodos da interface Registry. Particularmente, para registrar um novo serviço utiliza-se o método bind():

r.bind(serviceName, myCount);

O objeto que está sendo registrado deve implementar também a interface Remote, que identifica todos os objetos que podem ser acesados remotamente.

Outros serviços disponíveis através dos métodos de Registry incluem atualização, remoção e busca dos serviços lá registrados. Para atualizar um registro já existente, o método rebind() pode ser utilizado. Para eliminar um registro, utiliza-se o método unbind(). Dado o nome de um serviço, o objeto Remote que o implementa pode ser obtido pelo método lookup(). O método list() retorna um arranjo de String com os nomes de todos os serviços registrados.

Implementação do servidor RMI

Como observado, um objeto servidor RMI simples deve realizar as seguintes tarefas:

1. Criar uma instância do objeto que implementa o serviço; e

2. Disponibilizar o serviço através do mecanismo de registro.

Esse exemplo de servidor RMI para o contador remoto cria uma instância da implementação do serviço e coloca-a à disposição de potenciais clientes, registrando-o no registry RMI:

1. import java.rmi.registry.*;

2. public class CountServer {

3. public static void main(String[] args) {

4. try {

5. String serviceName = "Count001";

6. CountImpl myCount = new CountImpl();

7. Registry r = LocateRegistry.getRegistry();

1. r.bind(serviceName, myCount);

2. System.out.println("Count Server ready.");

10                   }

1. catch (Exception e) {

2. System.out.println("Exception: " + e.getMessage());

3. e.printStackTrace();

14                   }

15             }

16       }

Cliente RMI

A principal etapa no desenvolvimento de uma aplicação cliente RMI é a obtenção da referência remota para o objeto (remoto) que implementa o serviço desejado. Para tanto, o cliente RMI usa o serviço padrão oferecido pelo mecanismo de registro de nomes de serviços.

Uma vez que a referência remota seja obtida, ela pode ser convertida (downcast) para uma refe- rência para a interface que especifica o serviço. A partir de então, os métodos oferecidos pelo serviço remoto são invocados da mesma forma que ocorre para objetos locais.

Esses exemplos ilustram o desenvolvimento de código cliente em RMI. No primeiro exemplo desenvolve-se um cliente RMI que simplesmente invoca o método reset() através de uma refe- rência remota para o objeto servidor:

1. import java.rmi.registry.*;

2. public class CountReset {

3. public static void main(String args[]) {

4. try {

5. Registry r = LocateRegistry.getRegistry();

6. Count myCount = (Count) r.lookup("Count001");

7. myCount.reset();

8                   }

9                   catch(Exception e) {

10                         e.printStackTrace();

11                   }

12                   System.exit(0);

13             }

14       }

Nesse outro exemplo, o cliente utiliza os métodos para modificar e obter o valor do contador remoto. Ele também ilustra a interação de um código com o registro RMI através da classe Naming:

1. import java.rmi.*;

2. public class CountClient {

3. public static void main(String args[]) {

4. try {

5. Remote remRef = Naming.lookup("Count001");

6. Count myCount = (Count) remRef;

1. int initValue = myCount.get();

2. System.out.print("De " + initValue + " para ");

3. long startTime = System.currentTimeMillis();

10                         for (int i = 0 ; i < 1000 ; i++ )

1. myCount.increment();

2. long stopTime = System.currentTimeMillis();

3. System.out.println(myCount.get());

4. System.out.println("Avg Ping = "

15                                                                                + ((stopTime - startTime)/1000f)

16                                                                                + " msecs");

17                   }

1. catch(Exception e) {

2. e.printStackTrace();

20                   }

21                   System.exit(0);

22             }

23       }

Esse terceiro exemplo ilustra a utilização de RMI a partir de um cliente desenvolvido como um applet. Nesse applet, um campo de texto mostra o valor do contador no objeto servidor. Dois botões são fornecidos, um para incrementar o valor mil vezes Start) e outro para obter o valor atual do contador Get):

1. import java.rmi.*;

2. import java.awt.*;

3. import java.awt.event.*;

4. import java.applet.*;

5. public class AppletClient extends Applet

6. implements ActionListener {

7. Count remCount;

8. TextField tfCnt;

9. Button bStart, bGet;

10. String bslabel = "Start";

11. String bglabel = "Get";

12. public void init() {

13. try {

14. setLayout(new GridLayout(2,2));

15. add(new Label("Count:"));

16. tfCnt = new TextField(7);

17. tfCnt.setEditable(false);

18. add(tfCnt);

19. bStart = new Button(bslabel);

20. bStart.addActionListener(this);

21. bGet = new Button(bglabel);

22. bGet.addActionListener(this);

1. add(bStart);

2. add(bGet);

3. showStatus("Binding remote object");

4. remCount = (Count) Naming.lookup("Count001");

5. tfCnt.setText(Integer.toString(remCount.get()));

28                              }

1. catch (Exception e) {

2. e.printStackTrace();

31                              }

32                   }

1. public void paint() {

2. try {

3. tfCnt.setText(Integer.toString(remCount.get()));

36                              }

1. catch (Exception e) {

2. e.printStackTrace();

39                              }

40                   }

1. public void actionPerformed (ActionEvent ev) {

2. try {

3. String botao = ev.getActionCommand();

4. if (botao.equals(bslabel)) {

5. showStatus("Incrementing...");

46                                                      for (int i = 0 ; i < 1000 ; i++ )

1. remCount.increment();

2. showStatus("Done");

49                                          }

1. else {

2. showStatus("Current count");

3. paint();

53                                          }

54                              }

1. catch (Exception e) {

2. e.printStackTrace();

57                              }

58                   }

59       }

Definindo stubs e skeletons

Para que um serviço oferecido por um objeto possa ser acessado remotamente através de RMI, é preciso também as classes auxiliares internas de stubs e skeletons, responsáveis pela comunicação entre o objeto cliente e o objeto que implementa o serviço, conforme descrito na apresentação da arquitetura RMI.

Uma vez que a interface e a classe do serviço tenham sido criadas e compiladas para byteco-

des usando um compilador Java convencional, é possível criar os correspondentes stubs e skeletons. Para tanto, utiliza-se o aplicativo compilador RMI, rmic, disponibilizado juntamente com o kit de desenvolvimento Java.

Um exemplo ilustra o processo de compilação RMI para o serviço do contador remoto. Considere a implementação do serviço que foi previamente definida. O primeiro passo para a criação do stub e do skeleton para esse serviço é obter a classe compilada, que por sua vez precisa da classe da interface:

> javac Count.java

> javac CountImpl.java

Com a classe CountImpl.class disponível, a execução do comando

> rmic CountImpl

gera as classes CountImpl_Stub.class e CountImpl_Skel.class, correspondendo res- pectivamente ao stub e ao skeleton para o serviço. O stub deverá ser disponibilizado junto ao código do cliente RMI, enquanto que o skeleton deverá estar disponível junto ao código do servidor.

Uma classe stub oferece implementações dos métodos do serviço remoto que são invocadas no lado do cliente. Internamente, esses métodos empacotam marshall) os argumentos para o método e os envia ao servidor. A implementação correspondente no lado servidor, no skeleton, desempacota (unmarshall) os dados e invoca o método do serviço. Obtido o valor de retorno do serviço, o método no skeleton empacota e envia esse valor para o método no stub, que ainda estava aguardando esse retorno. Obtido o valor de retorno no stub, esse é desempacotado e retornado à aplicação cliente como resultado da invocação remota.

Internamente, o processo de marshalling utiliza o mecanismo de serialização de Java. Assim, argumentos e valores de retorno de métodos remotos invocados através de RMI estão restritos a tipos primitivos de Java e a objetos de classes que implementam Serializable.