Padrões JEE – Parte 5

Oi pessoal!

Este é o último post da série sobre Padrões de Projeto JEE.

Antes de mais nada, gostaria de agradecer aos feedbacks positivos recebidos!  Bom saber que os posts estão sendo úteis para o pessoal 🙂

Vou finalizar com os patterns da camada de integração.  Esta camada, como o próprio nome dá a entender, concentra componentes responsáveis por encapsular acesso a dados e comunicação com sistemas externos, através por exemplo de web services, troca de mensagens, etc.  Se pararmos para pensar, o próprio acesso a dados pode ser visto como comunicação com sistemas externos, uma vez que o SGBD é por si só um sistema externo!

Vamos aos padrões deste post: Data Access Object, Service Activator, Domain Store e Web Service Broker.

Data Access Object

Problema: Deseja-se encapsular acesso e manipulação de dados em uma camada separada.

Solução: Utilizar um Data Access Object para abstrair e encapsular todo o acesso ao armazenamento persistente.  O Data Access Object gerencia a conexão com a fonte de dados para obter e armazenar dados.

Estrutura:

Diagrama de sequência:


Participantes e responsabilidades:

  • Client: Objeto que requer acesso à fonte de dados para obter e armazenar dados.  Pode ser um Business Object, uma Session Façade, um Application Service, um Value List Handler, um Transfer Object Assembler ou qualquer outro objeto auxiliar que precise acessar dados persistentes.
  • DataAccessObject:  Abstrai a implementação de acesso a dados para o Client para habilitar acesso transparente à fonte de dados.  Implementa operações CRUD (Create, Update, Delete).
  • DataSource:  Representa uma implementação de fonte de dados.  Pode ser um banco de dados (relacional, orientado a objetos), repositório XML, sistema de arquivos, sistema legado, mainframe, serviço (ex.: B2B), algum tipo de diretório (ex.: LDAP) etc.
  • ResultSet: Representa o resultado da execução de uma consulta.  Ex.: instância de java.sql.ResultSet, da API de JDBC.
  • Data:  Representa um transfer object usado para transportar dados.

Exemplos de aplicabilidade:

Abaixo temos o código de um Data Access Object (DAO).  Omiti o código da classe ClienteTO (transfer object) por brevidade.   Basicamente, é feita uma consulta via JNDI no construtor do DAO para recuperar uma determinada fonte de dados Oracle.  O código é “inspirado” no exemplo encontrado no livro Core J2EE Patterns [1].

Service Activator

Problema: Deseja-se invocar serviços de forma assíncrona.

Solução: Usar um Service Activator para receber requisições assíncronas e invocar um ou mais métodos de negócio.  Nos diagramas e exemplos de código mostrados a seguir, supõe-se o uso da API JMS – Java Message Service [2] – para a infra-estrutura de envio/recebimento de mensagens assíncronas.

Estrutura:

Diagrama de sequência:

Participantes e responsabilidades:

  • Client:  Qualquer cliente na aplicação que precise invocar um serviço de negócio de forma assíncrona.  O cliente pode ser qualquer tipo de componente, e é responsável por enviar mensagens JMS.
  • Request:  O objeto que representa a mensagem criada pelo cliente e enviada para o ServiceActivator, utilizando um middleware orientado a mensagem.  De acordo com a especificação do JMS, o objeto Request tem que implementar a interface javax.jms.Message.
  • ServiceActivator:  Classe que deve implementar a interface javax.jms.MessageListener, definida pela especificação do JMS.  O ServiceActivator implementa o método onMessage(), que é invocado quando uma nova mensagem chega.  Dessa forma, o ServiceActivator é responsável por executar o parsing da mensagem para determinar o que deve ser feito.
  • BusinessService:  Objeto alvo que executará o processamento assíncrono.  Seu papel é tipicamente o de uma Session Façade ou um Application Service.
  • Response:  Objeto que representa a mensagem criada pelo ServiceActivator ou pelo BusinessService em resposta à requisição (ex.: uma confirmação ou o resultado do processamento assíncrono).

Exemplos de aplicabilidade:

O exemplo abaixo é adaptado do livro Core J2EE Patterns.  Consiste em um Message Driven Bean (MDB)  – um tipo especializado de Enterprise Java Bean voltado especificamente para o recebimento de mensagens assíncronas – cuja função é receber mensagens de pedidos de compra (“Orders”).

Domain Store

Problema: Deseja-se separar o código de persistência do modelo de objetos.

Solução: Usar um Domain Store para transparentemente persistir um modelo de objetos.  Diferentemente dos mecanismos de persistência gerenciados pelo container ou pelo bean oferecidos pela Plataforma JEE, o mecanismo de persistência empregado por este pattern é separado do modelo de objetos.

Estrutura:

Diagrama de Sequência:

Participantes e responsabilidades:

  • ApplicactionService:  Elemento que interage com objetos de negócio persistentes (ver padrão Application Service).
  • Persistable:  Uma interface que todos os objetos de negócio persistentes devem implementar.
  • PersistenceManagerFactory:  Cria e gerencia PersistenceManagers.
  • PersistenceManager:  Gerencia a persistência e as consultas do modelo de objetos.  Interage com o StateManager, mas não com o objeto de negócio, sendo portanto desacoplado e independente deste último.  Instrui o StateManager a atualizar o estado do objeto quando necessário.
  • StateManager:  Gerencia o estado de objetos persistentes.  O objeto persistente compartilha a responsabilidade por gerenciar seu estado com o StateManager, que força o armazenamento e recuperação transacional de estado da fonte de dados.
  • StoreManager:  Interage com a fonte de dados para realizar operações CRUD.  É um Data Access Object .
  • DataResource:  Qualquer serviço que gerencia dados.  Pode ser um SGBD relacional ou orientado a objetos, um Enterprise Information System etc.
  • SessionFacade: Ponto de entrada para a camada de serviços.  Comunica-se com um ou mais ApplicationServices.
  • PersistMap:  Contém os relacionamentos entre os objetos e os mapeamentos entre objetos persistentes e a fonte de dados (DataResource).
  • Transaction:  Usado para delimitar transações.
  • Query:  Encapsula uma consulta, bem como seus critérios de filtragem/ordenação e parâmetros.

Exemplos de aplicabilidade:

Hoje em dia não é comum que se implemente o padrão Domain Store “do zero” em uma aplicação, uma vez que o mesmo, além de ser por si só complexo – chegando por vezes a empregar mecanismos avançados de geração de bytecode  em tempo de execução para evitar um grande número de classes –  é implementado, com variações, nos frameworks de mapeamento objeto-relacional atualmente disponíveis no mercado, tais como Hibernate [3], JPA [4], JDO [5], entre outros.

Web Service Broker

Problema: Deseja-se fornecer acesso a um ou mais serviços usando XML e protocolos Web.

Solução: Usar um Web Service Broker para expor e intermediar um ou mais serviços utilizando XML e protocolos Web.

Estrutura:

Diagrama de Sequência:

Participantes e responsabilidades:

  • Client: Qualquer componente que seja capaz de gerar uma requisição a um web service.
  • EndpointProcessor:  Servlet que atua como o ponto inicial de entrada para o web service, sendo responsável por receber e processar cada requisição.  A requisição é tipicamente baseada no SOAP/HTTP ou REST/HTTP.  Mais comumente, este elemento é embutido no runtime system utilizado para invocação de web services, tais como JAX-RPC ou JAX-WS.
  • WebServiceBroker:  Web service que serve como um intermediário para um ou mais serviços, que podem ser por sua vez serviços JEE (ex.: Session Façade, Application Service) ou sistemas legados.  Pode ser implementado como um POJO, como um session bean baseado em JAX-RPC ou um POJO baseado em JAX-RPC.
  • BusinessService:  Pode ser uma fachada ou um Application Service..

Exemplos de aplicabilidade:

Os trechos de código são adaptados do livro Core J2EE Patterns e demonstram a implementação do pattern para uma aplicação de processamento de pedidos de compra.  É importante ressaltar que o exemplo, embora seja útil do ponto de vista didático, raramente é empregado atualmente em aplicações reais, uma vez que tecnologias mais recentes, tais como o JAX-WS, abstraem os detalhes de mais baixo nível, não exigindo, por exemplo, a implementação de uma servlet por parte do desenvolvedor para recebimento das requisições.

EndpointProcessor:

WebServiceBroker:

Concluímos por aqui a exploração de padrões JEE. Apesar deste ser um assunto complexo e que por vezes requer conhecimento anterior em tópicos mais avançados da tecnologia Java, espero ter conseguido passar a “essência” dos patterns, ao menos no nível em que se deve esperar em questões de concursos.

Até mais!

Referências:

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

[2] Java Message Service (JMS).  http://java.sun.com/products/jms/

[3] Hibernate.  http://www.hibernate.org/

[4] Java Persistence API.  http://java.sun.com/javaee/technologies/persistence.jsp

[5] Java Data Objects (JDO).  http://java.sun.com/jdo/


»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...

Deixe uma resposta

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