Arquitetura voltada ao acesso local

Com o passar do tempo, notamos que o uso de acessos remotos não era necessário e, apenas trazia ônus ao sistema.
Decidimos então, utilizar apenas acessos locais e, deixar a aplicação servidora e cliente rodando no mesmo servidor de aplicações.
Entretanto, caso no futuro o acesso remoto seja desejável não parece ser muito custoso implementá-lo²⁵.
Nesta nova arquitetura, o padrão Remote Adapter foi excluído. Desta maneira, a aplicação cliente precisa ter em mãos, além das interfaces ``locais'' e ``home'', as classes utilitárias²⁶.

Na arquitetura anterior, a aplicação cliente tinha acesso às fachadas indiretamente, através dos Adaptadores Remotos. Agora, o acesso é direto, não há mais um despachante²⁷.

Como ocorreu na arquitetura anterior, a aplicação cliente continua trocando dados dos Entity Beans com a aplicação servidora através de Value-Objects.

A seguir, a estrutura de classes utilizada. Neste caso, com execeção das classes: PessoaBean, PessoaFacadeBean, todas as outras foram geradas automaticamente pelo XDocLet.

Vale lembrar que a principal diferença entre as classes PessoaFacadeBean e PessoaAgentBean reside no fato da primeira ser um Session Bean ``Stateful''<sup>28</sup> e a segunda ``Stateless''²⁹.

Por ser bastante parecido com o diagrama da arquitetura anterior, não achamos necessário uma explicação mais prolongada.

Figura 6: Diagrama UML simplificado mostrando as classes que estão diretamente relacionadas com as classes: PessoaBean e PessoaFacadeBean.

Note que a classe PessoaFacadeBean possui um atributo chamado PessoaLocal. Esta é a chave da diferença entre as arquiteturas.
Esta variável armazena o Entity Bean³⁰ que a fachada está manipulando e, para o qual está repassando as chamadas.
Isto é uma grande vantagem pois, se várias chamadas forem realizadas por um mesmo cliente, teremos um ganho de performance, uma vez que não é necessário localizar o ``bean'' novamente.

... implementá-lo²⁵

Observe como os dois diagramas são parecidos para se convencer disto

... utilitárias²⁶

Na verdade, na arquitetura anterior, as classes utilitárias também precisavam ser passadas à aplicação cliente(via ``jar'') mas, eram apenas utilizadas pelas classes que implementavam os Remote Adapters

... despachante²⁷

Os Adaptadores remotos são bem mais que meros despachantes, elas escondem do cliente a complexidade das chamadas aos ``beans''

... ``Stateful''²⁸

Mantém estado entre as chamadas de cada cliente

... ``Stateless''²⁹

Não mantém.

... Bean³⁰

Na verdade, guarda um EJBObject que encapsula o ``bean''