Arquitetura para acessos remotos

Primeiramente desenvolvi uma arquitetura que permitia o uso de clientes remotos, ou seja, que estavam rodando em outros servidores de aplicações.
Esta abordagem se deveu ao fato do NetBeans possuir um ambiente excelente de depuração, além de possuir um servidor TomCat embutido. Desta maneira, os Servlets rodavam no servidor Tomcat acessando os ``beans'' que estavam no servidor JBoss.

Para que este acesso remoto fosse bem sucedido, foi necessário que os beans possuíssem interfaces remotas e estivessem registrados no servidor ``JNDI''.
Além disso, era necessário que a aplicação cliente(cliente Web que roda no TomCat) possuísse estas interfaces.
Por isso, elas foram disponibilizadas através de um arquivo ``jar''.

Nesta arquitetura, o acesso aos ``beans'' está bem mascarado, de forma que o cliente nem sabe que está utilizando-os.
Para acessá-los, utiliza-se uma classe utilitária e, os dados dos Entity Beans são passados da aplicação cliente a servidora(e vice-versa) na forma de Value Objects.

Para o desenvolvimento do sistema, foi preciso criar uma série de ``beans'': Entity e Session, responsáveis pela persistência de dados e por controlar fluxos de transformações, respectivamente.
Além disso, padrões J2EE foram utilizados para garantir maior flexibilidade, poupar esforço e melhorar a performance.
Os principais padrões utilizados foram: Remote Adapter, Value Object e Facade.
O primeiro existe mais para poupar o trabalho de criar um ``bean''(localizá-lo e retornar um EJBObject), o segundo está relacionado à performance, por diminuir o tráfego de rede e, o terceiro aumenta a flexibilidade²⁰ do sistema.
Os dois primeiro padrões foram criados diretamente por uma ferramenta de geração de código chamada XDocLet.
Para isto, bastou definir algumas ``tags'' para que, as classes que implementavam os padrões, fossem geradas automaticamente.

Classes²¹, a partir das quais, as outras²² foram criadas:

PessoaBean:

Um Entity Bean que representa uma pessoa no sistema. Ela é um objeto persistente gerenciado pelo servidor de aplicações.

PessoaAgentBean:

Uma Fachada para um PessoaBean.
O uso de uma fachada, permite que a classe PessoaBean seja alterada sem que o cliente precise mudar seu código, já que ele acessa apenas a fachada.
²³

Figura 5: Diagrama UML simplificado mostrando as classes que estão diretamente relacionadas com as classes: PessoaBean e PessoaAgentBean

Vamos analisar algumas classes deste diagrama, lembrando que com exceção das classes: PessoaBean e PessoaAgentBean, todas as outras foram geradas automaticamente pelo XDocLet.

A partir da classe PessoaBean, o XDoclet gerou as seguintes classes:

PessoaCMP:

Estende a classe PessoaBean, implementa os métodos da interface Entity Bean que não foram implementados pela classe PessoaBean e, realiza algumas operações com os Value Objects, dentre elas, retornar uma Pessoa como uma PessoaValue.

PessoaLocal:

Interface ``local'' da classe PessoaBean.

PessoaLocalHome:

Interface ``home'' da classe PessoaBean.

PessoaUtil:

Possui métodos para retornar a interface ``local home'' da classe PessoaBean.
Além disso, ela guarda numa variável a classe ``home'' retornada, funcionando como um ``cache''.

PessoaValue²⁴:

Agrupa alguns campos da classe PessoaBean a fim de poder transmitir os dados da classe PessoaBean empacotados pela rede, de modo a diminuir o tráfego de rede.

As seguintes classes foram geradas pelo XDoclet a partir da classe PessoaAgentBean:

PessoaAgent:

Interface remota do bean PessoaAgent.

PessoaAgentHome:

Interface home do bean PessoaAgent.

PessoaAgentUtil:

Classe utilitária do bean PessoaAgent que possui métodos para retornar sua interface home, além de manter um cache do home retornado.

PessoaAgentRemote:

Remote Adapter para o PessoaAgentBean. Esta classe é acessada diretamente pela aplicação cliente e, é responsável por repassar as chamadas ao ``bean'' PessoaAgent. Para cada chamada que ela recebe, as seguintes tarefas são realizadas:

1. Obtém a interface ``home'' do ``bean''.
2. Cria um objeto através da interface ``home''.
3. Repassa a chamada ao ``bean''.
4. Recebe a resposta e retorna ao cliente.

Os primeiros dois passos são executados apenas na primeira chamada pois, a classe guarda um ``cache'' com o objeto criado, para repassar futuras chamadas ao mesmo.
Esquecemos de mencionar que a classe PessoaagentRemote é Singleton.

... flexibilidade²⁰

Como a aplicação cliente só se comunica com as Fachadas que, por sua vez se comunicam com os Entity Beans, uma alteração na estrutura dos Entity Beans não acarreta a necessidade de mudança na aplicação cliente.

...Classes²¹

Classes que foram codificadas manualmente

... outras²²

Classes utilitárias.

... fachada.\\²³

O uso de uma fachada para cada Entity Bean não é recomendado. Neste exemplo, criamos uma fachada que acessa apenas um ``bean'' mas, no sistema, a maior parte das fachadas opera sobre diversos Entity Beans.

...PessoaValue²⁴

Mais informações sobre Value-Objects 3.7.3