parte da revista Java Magazine edição 53. Clique aqui para ler todos os artigos desta edição.

forma transparente

Como usar o suporte fornecido pelo Spring a mecanismos de acesso remoto, que abstraem as complexidades da comunicação remota para o desenvolvedor

O Spring suporta acesso a serviços remotos no modelo RPC (chamada remota de procedimentos). O suporte do framework a serviços remotos abrange os mecanismos mais comuns de transporte usados em RPC como RMI, HTTP (utilizando serialização de objetos), EJBs e Web Services.

Arquitetura

O Spring faz o acesso aos serviços remotos através de um proxy dinâmico que implementa uma interface de negócio. O mecanismo é similar ao uso da tecnologia JAX-RPC para acessar Web Services. Com JAX-RPC, é criada uma interface “service endpoint” pela qual o serviço é acessado, e a transformação dos objetos/valores em XML ocorre transparentemente.

A grande vantagem do Spring é permitir que você exponha como um serviço remoto a interface de negócio, sem alterações. Ou seja, não é necessário especializar interfaces específicas ou lançar exceções que não fazem parte do negócio em seus métodos. Já ao usar JAX-RPC (ou RMI ou EJB), temos que indicar que nossos métodos lançam java.rmi.RemoteException. Com o Spring Remoting, todas as exceções se tornam exceções de runtime (subclasses de java.lang.RuntimeException). Assim, é claro, o desenvolvedor não será obrigado a tratá-las ou relançá-las de forma explícita.

A Figura 1 ilustra a estrutura do acesso a um serviço remoto com o Spring. Repare que o cliente interage somente com a interface de negócio e que é um proxy (substituto/intermediário) que se comunica remotamente com o serviço.

Quando disponibilizamos um serviço para que seja acessado de forma remota, o Spring também nos auxilia. Há o conceito de Exporter, um objeto capacitado a tornar um bean disponível remotamente. A Figura 2 ilustra como funciona a exportação de um bean (nomeado “Serviço” no diagrama).

Veremos neste artigo como fazer o acesso remoto com RMI, HTTP e EJB. O acesso via outros mecanismos é bastante similar: seguem a mesma estrutura, variando somente classes e algumas propriedades. O suporte a EJBs é particularmente interessante. Por utilizar um proxy dinâmico, o Spring encapsula e isola o tipo de EJB da aplicação. Com isso é possível acessar um EJB local ou remoto da mesma forma – através de sua interface de negócio.

 

Figura 1. Arquitetura de Proxy do Spring

Figura 2. Arquitetura de Exporter do Spring

 

Primeiro exemplo

Nosso primeiro exemplo será uma aplicação contendo um componente simples disponibilizado no servidor, que retorna a data e a hora do servidor através de uma chamada remota. A aplicação será implementada utilizando RMI.

Implementando o exemplo

O primeiro passo é a codificação da nossa “interface de negócio”, br.com.jm.remoting.rmi.service.TimerService (veja a Listagem 1). Esta interface possui apenas um método que retorna a data e a hora do servidor. A classe de implementação é a TimerServiceImpl (no mesmo pacote) e é mostrada na Listagem 2. Repare que o método getTime() retorna apenas um objeto java.util.Date convertido para String.

Com esses dois itens, já temos um serviço que pode ser disponibilizado no Spring. Se o configurássemos como um bean no Spring, já poderíamos utilizá-lo na mesma aplicação. Mas isso não é o que desejamos: precisamos exportar o serviço para que se torne disponível remotamente.

 

 Listagem 1. Interface de “negócio”

package br.com.jm.remoting.rmi.service;

 

public interface TimerService {

  public String getTime();

}

 

 

Listagem 2. Implementação da interface de negócio

package br.com.jm.remoting.rmi.service;

 

import java.util.Date;

 

public class TimerServiceImpl implements TimerService {

  public String getTime() {

...

Quer ler esse conteúdo completo? Tenha acesso completo