Padrões JEE – Parte 3

Olá a todos!

Segue a terceira parte da série de posts sobre padrões JEE, passando agora à camada de negócio.  É importante ressaltar que a compreensão dos padrões pertencentes a essa camada podem requerer um entendimento básico de tecnologias como enterprise beans e JNDI.  Isso porque, embora os padrões JEE da camada de negócio possam ser utilizados em outros cenários, tais como aplicações que não fazem uso de EJBs, muitos deles foram motivados por problemas e/ou necessidades inerentes a essas tecnologias e a sistemas distribuídos em geral.  Serão vistos os padrões Business Delegate, Service Locator, Session Façade e Application Service.

Business Delegate

Problema: Isolar a aplicação cliente da complexidade da comunicação remota com componentes de negócio.

Solução: Usar um Business Delegate para encapsular o acesso a um serviço de negócio.  O Business Delegate esconde os detalhes de implementação do serviço de negócio, tais como mecanismos de consulta e acesso.  Dessa forma, pode-se acessar a partir do cliente um serviço de negócio remoto de forma transparente, da mesma forma que se acessaria um objeto local.

Estrutura:

Diagrama de sequência:

Participantes e responsabilidades:

  • BusinessDelegate: fornece controle e proteção para o serviço de negócio.
  • ServiceLocator: encapsula os detalhes relativos à localização de um componente de negócio.  Ver padrão Service Locator.
  • BusinessService:  componente da camada de negócio (ex.: enterprise bean) que é acessado pelo cliente.
  • Handle:  objeto que permite que se reconecte a um objeto remoto sem que seja necessário localizá-lo novamente.  Normalmente utilizado em cenários de caching de referências para objetos remotos.

Exemplos de aplicabilidade:

Um aspecto interessante relativo ao uso deste padrão é que, embora business delegates estejam logicamente associados à camada de negócio – uma vez que abstraem o acesso a componentes de negócio e são em geral implementados pelos mesmos desenvolvedores de tais componentes – fisicamente os mesmos estão localizados na camada de apresentação, pois dessa forma atuam como proxies para objetos remotos (ver padrão Proxy – GoF).

Os trechos de código abaixo, embora contenham código relativo à API de EJB, são auto-explicativos e demonstram as classes que implementam, respectivamente, os papéis de BusinessDelegate e componente de negócio.

Interface do session bean AccountSession:

Componente de negócio remoto que implementa a interface AccountSession:

Service Locator

Problema: Deseja-se localizar de forma transparente componentes e serviços de negócio de maneira uniforme.

Solução: Utilizar um Service Locator para implementar e encapsular a lógica de localização do componente ou serviço de negócio.

Estrutura:

Diagrama de sequência:


Participantes e responsabilidades:

  • Client: Elemento que precisa localizar e acessar um componente ou serviço que esteja nas camadas de negócio ou integração.  Um exemplo típico é o de um Business Delegate (ver padrão Business Delegate) ou uma classe de acesso a dados que precisa obter uma conexão a um datasource JDBC.
  • ServiceLocator: Encapsula a API de localização, dependências relativas à plataforma, bem como toda a complexidade relativa à localização e criação de objetos de negócio, provendo uma interface simplificada para os clientes e com isso promovendo maior simplicidade e reúso.
  • Cache: Elemento opcional que armazena referências para componentes previamente consultados.
  • InitialContext:  Ponto de início para a localização e criação de objetos.  Varia de acordo com o tipo de componente (ex.: enterprise bean, fila de mensageria etc.) a ser acessado.
  • Target: Representa o serviço ou componente que o cliente está tentando localizar com o ServiceLocator.
  • RegistryService:  Implementação do registro que armazena referências para os serviços ou componentes.  Exemplos: serviços de publicação e busca, tais como registros JNDI, UDDI e outros.

Exemplos de aplicabilidade:

O trecho de código abaixo mostra o uso de uma API de consulta a um enterprise bean.  No exemplo em questão, faz-se uso de JNDI para localizar o recurso desejado.  O service locator em questão é implementado como um singleton (GoF) que adicionalmente implementa uma cache de referências para objetos remotos.

Session Façade

Problema: Deseja-se expor componentes e serviços de negócio para clientes remotos.

Solução: Usar uma Session Façade para encapsular componentes da camada de negócio e expor um serviço de alta granularidade para clientes remotos.  Dessa forma, os clientes acessam uma Session Façade ao invés de acessarem os componentes de negócio diretamente, diminuindo com isso a complexidade e a replicação de código.

Estrutura:


Diagrama de Sequência:


Participantes e responsabilidades:

  • Client:  Elemento que precisa acessar o serviço de negócio.  Tipicamente é um business delegate em outra camada.
  • SessionFacade:  Implementada como um session bean – stateless ou stateful, a depender da necessidade.  Esconde a complexidade de lidar com vários componentes de negócio que participam em um caso de uso e portanto fornece uma abstração de maior nível para os clientes.
  • BusinessComponent: Em geral, é implementada como um objeto de negócio que modela dados do negócio (ex.: entidades) ou como um Application Service (ver padrão Application Service) que modela comportamento (regras de negócio) .
  • ApplicationService: Implementa a lógica de negócio que é executada para fornecer o serviço requerido.
  • DataAccessObject:  Objeto responsável por lidar diretamente com a persistência e/ou recuperação dos dados (ver padrão Data Access Object).

Exemplos de aplicabilidade:

Abaixo, temos um exemplo de session bean que atua como uma fachada para o subsistema de gerenciamento de contas de um sistema bancário.  A implementação do session bean em questão consiste basicamente em delegar o processamento para um outro componente, referenciado no código como AccountManagementService.  Na próxima sessão, veremos que esse componente atua na realidade como um Application Service.

Interface do session bean AccountSession:

Componente de negócio remoto que implementa a interface AccountSession:

Application Service

Problema: Deseja-se centralizar a lógica que envolve vários componentes e serviços da camada de negócio.

Solução: Usar um Application Service para centralizar e agregar comportamento, a fim de fornecer uma camada de serviço uniforme.

Estrutura:


Diagrama de Sequência:


Participantes e responsabilidades:

  • Client: Papel tipicamente desempenhado por uma fachada, que pode ser implementada por sua vez como um POJO ou como uma Session Façade.  O cliente também pode ser um outro Application Service.
  • ApplicationService:  Encapsula a lógica de negócio requerida para fornecer um serviço específico.  Em geral, implementa comportamento comum a vários objetos de negócio, comportamento relacionado a um caso de uso específico ou então a um tipo específico de plataforma clente.  É recomendado que seja implementado como um POJO, pois dessa forma torna-se mais reutilizável.
  • BusinessObject:  Instâncias de entidades de negócio que o ApplicationService pode acessar para realizar um serviço.  Comumente, vários objetos de negócio são acessados para atender a uma requisição de serviço.
  • Service:  Componente que oferece qualquer serviço à aplicação, a exemplo de classes utilitárias.
  • DataAccessObject:  Representa objetos de acesso a dados em cenários onde o ApplicationService acessa diretamente os dados persistentes.

Exemplos de aplicabilidade:

O código abaixo mostra um exemplo de um Application Service responsável por implementar métodos de negócio relacionados a gerenciamento de contas de um banco.  Ao mesmo tempo, regras de negócio são checadas para garantir que a operação é válida.

No próximo post sobre padrões JEE da camada de negócio, tratarei dos padrões Business Object, Composite Entity, Transfer Object, Transfer Object Assembler e Value List Handler.

Referências:

[1] Core J2EE Patterns – Best Practices and Design Strategies, 2nd Edition.  Depak Alur, John Crupi e Dan Malks.  2003.

[2] Catálogo online de padrões: http://java.sun.com/blueprints/patterns/catalog.htm

»crosslinked«

Monique Monteiro

Sou Arquiteta de Software (embora já tenha atuado também como Gerente de Projetos), MSc em Ciência da Computação e sou de Recife, mas moro atualmente em Brasília. Estou envolvida na área de TI (mais especificamente desenvolvimento de software) há cerca de 10 anos (contando o período da faculdade, é claro :)), e de lá pra cá sempre gostei de aprender coisas novas relacionadas ao estado da arte em desenvolvimento e Engenharia de Software em geral! Desde dezembro de 2009 estou trabalhando no Tribunal de Contas da União (TCU), como Auditora Federal de Controle Externo.

Você pode gostar...

1 Resultado

  1. alessandropa disse:

    Monique, ótimos artigos. Parabéns! Mas você continua estudando para algum outro concurso?

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *