Padrões Arquiteturais no Java EE 7

Transcrição

1 Padrões Arquiteturais no Java EE 7 Vagner F. Le Roy Júnior Curso de Pós Graduação em Arquitetura de Software Distribuído Pontifícia Universidade Católica de Minas Gerais Belo Horizonte, MG Brasil vagnerleroy@gmail.com Abstract. This article seeks to present, analyze and demonstrate, through UML diagrams and source code, applying some design patterns in the architecture of the Java EE7. The main patterns in this document are: Service Façade, DAO, Persistent Domain Object and Data Transfer Object. Resumo. Este artigo busca apresentar, analisar e demonstrar, por meio de diagramas UML e códigos fonte, a aplicação de alguns padrões de projeto na arquitetura do Java EE7. Os principais padrões abordados neste documento são: Service Façade, DAO, Persistent Domain Object e Data Transfer Object. 1. Introdução Projetar sistemas orientados a objetos é difícil, e projetar sistemas orientados a objetos reutilizáveis é ainda mais difícil. Para nos ajudar nesta árdua tarefa, as melhores práticas utilizadas por diversos profissionais ao redor do mundo, envolvendo a construção destes sistemas, foram catalogadas durante o passar dos anos tornando-as conhecidas simplesmente como padrões de projetos ou design patterns. Um padrão nada mais é que uma descrição de uma solução comprovada para um problema recorrente de design, com especial ênfase sobre o contexto, as forças que cercam o problema, as consequências, e o impacto da solução. Os padrões de projeto ficaram popularmente difundidos em 1995 após o lançamento do livro Design Patterns: Elements of Reusable Object-Oriented Software, dos autores Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a Gangue dos Quatro (Gang of Four ou simplesmente GoF). Os padrões de projeto visam facilitar o desenvolvimento de software oferecendo os seguintes benefícios: Soluções provadas: padrões refletem a experiência, conhecimento e insights de desenvolvedores que têm usado com sucesso esses padrões em seu próprio trabalho. Reutilizáveis: padrões proporcionam uma solução pronta que pode ser adaptada a diferentes problemas como necessário. Expressivos: padrões fornecem um vocabulário comum de soluções que podem expressar grandes soluções de forma sucinta. Este artigo busca demonstrar, por meio de códigos fonte e diagramas UML, um breve resumo de algumas das melhores práticas envolvendo padrões de projeto na tecnologia Java EE 7.

2 2. Java EE Em 1992, a Sun Microsystems criou um grupo conhecido como Green Team com o objetivo de desenvolver inovações tecnológicas. Este time então apresentou a ideia de criar um interpretador (o que seria mais tarde a JVM) para facilitar o desenvolvimento de aplicações que rodassem em diversos dispositivos, como vídeo-cassestes, televisões, aparelhos médicos, etc. Por motivos de conflitos de interesses e custo, o projeto não foi bem sucedido. Com a chegada da Web em 1995, a Sun percebeu a oportunidade de desenvolver aplicações que rodassem em diversos browsers e em diversos sistemas operacionais (os chamados applets), não apenas renderizando HTML, mas oferecendo aplicações ricas do lado do cliente. Surgia-se então o Java 1.0. Apesar de ter sido criado com este intuito, os applets caíram em desuso e a tecnologia se focou principalmente no lado do servidor. No ano de 1997 é lançada a versão 1.1 da J2EE, incluindo a primeira versão do principal componente da versão Enterprise, o EJB. Em 1999 é lançada a J2EE 1.2 (Java 2 Enteprise Edition) com bibliotecas e APIs com foco em aplicações distribuídas, tolerante a falhas, multicamadas e baseada em componentes reutilizáveis do lado do servidor. Já em 2006, com o lançamento da versão 5, a plataforma então muda de nome de J2EE para Java EE. Atualmente na sétima versão, e preste ao lançamento da oitava, a tecnologia Java se encontra composta por 3 grandes famílias: Java SE: núcleo central da tecnologia Java. Oferece desde tipos básicos até APIs de alto nível. Muito utilizada por aplicações Desktop. Java ME: fornece API e máquina virtual leve. É voltada para pequenos dispositivos e sua API é um subconjunto da Java SE. Java EE: estende a Java SE incluindo componentes e APIs para desenvolvimento de grandes aplicações corporativas. Com o crescimento de aplicações Java EE e a necessidade de cada vez mais atingir requisitos não-funcionais que permeiam as grandes aplicações Web, surgiram boas práticas e padrões para ajudar o desenvolvedor a vencer estes desafios. Alguns destes padrões serão discutidos em seguida!

3 Figura 1. Organização em camadas de uma aplicação Java EE. 3. Service Façade (Application Service) Session Façades provêm uma implementação do padrão Façade [Gof] utilizando session beans. No entanto, em um projeto que não é utilizado EJB, podemos utilizar POJOs (Plain and Old Java Objects) no lugar dos EJB. Para prover um vocabulário comum ao discutir Façades, tanto para EJB, quanto para POJOs, foi criado o termo Service Façade Problema A motivação para utilizarmos um Application Service em um contexto orientado a serviços é a seguinte: Centralizar a regra de negócio em vários componentes e serviços da camada de negócios. O acesso aos componentes de lógica de negócio tem que ser o mais conveniente e mais consistente possível tornando necessário uma API de alta granularidade.

4 3.2. Forças O estado do componente após a invocação da Service Façade deve permanecer consistente. A realização por trás da fachada de serviço deve ser encapsulada. A interface da Service Façade deve ser utilizável como um serviço remoto. Em caso de alteração, a assinatura dos métodos expostos devem permanecer estáveis e compatíveis Solução Com o EJB 3.1, não é mais necessário implementarmos a interface do Bean (apesar de ser recomendável para fins de testes) e nem especificarmos os wrappers locais e remoto. Sendo assim, um Service Façade é composto por uma interface de negócio local e sua implementação, isto é, um Session Bean Stateless. Em Java EE, a principal responsabilidade de um Service Façade é ainda a composição de serviços independentes e reutilizáveis, mas para casos de uso simples, pode-se implementar diretamente a lógica de negócios sem delegá-la a outros componentes. Figura 2. ServiceFaçade em Java EE Em cenários mais complexos, um Service Façade coordena alguns serviços ou DAOs. A interface de negócios remota deve ser utilizada apenas por clientes remotos, porém, sempre que possível, a interface local deve ser acessada em seu lugar. 4. DAO (Data Access Object) A ideia original para o padrão DAO era fornecer um mecanismo que permitisse alterar a fonte de dados independente do seu tipo de armazenamento (Banco de dados relacionais, banco de dados orientado a objetos, LDAP, arquivos textos), sem alterar o restante da lógica da aplicação. Sendo assim, a principal motivação deste padrão é

5 querer separar a lógica de negócios da realização concreta dos mecanismos de armazenamento de dados Problema O problema real deste padrão é seu uso excessivo. Alterar o mecanismo de banco de dados ou até mesmo o fornecedor em um projeto real não é realista e na maioria dos casos, necessário. Uma aplicação que utiliza SQL dificilmente será portada para LDAP. Mesmo com os recursos do JPA introduzidos no Java EE, a abstração total da camada de acesso a dados em raros casos é feita. Utilizamos esta abordagem somente em casos muito simples. Quando necessitamos de consultas sofisticadas, utilizamos um DAO Forças Há a necessidade de se acessar uma fonte de dados legada ou algum outro recurso que não seja compatível com JPA. É necessário manter testável a abstração de acesso a dados. É dissociar a implementação proprietária do acesso aos recursos do resto da aplicação. A aplicação é orientada a serviços: a lógica de negócio e acesso a dados são separados. É necessário ter que lidar com fontes de dados legados não padronizadas. As queries são muito complexas e é importante mantê-las em um lugar separado Solução Em um ambiente Java EE, não é necessário utilizarmos a JDBC para acessarmos o banco de dados. Pode-se utilizar a linguagem genérica de consultas da JPA, bem como SQL nativo. A JPA fornece, através do objeto Entity Manager, métodos como UPDATE, DELETE, INSERT para trabalharmos diretamente com objetos ao invés de utilizar a API JDBC de baixo nível. O acesso é simples e o Entity Manager pode ser injetado diretamente a qualquer session bean:

6 O JPA fornece somente uma interface e podemos mudar a sua implementação apenas mudando uma linha de código no arquivo persistent.xml. Vários fabricantes implementam a especificação JPA e disponibilizam produtos como Hibernate, Eclipse Link. Veja abaixo um exemplo desta configuração utilizando o framework Hibernate: O Entity Manager é uma abstração do provedor de serviços JPA e pode ser encarado como uma implementação genérica do padrão DAO, podendo ser injetado diretamente em uma classe de serviço. Em Java EE, o padrão DAO é opcional e não é a

7 única forma de acessar o armazenamento de dados. Em suma, pequenos projetos que utilizam de simples CRUD, podem utilizar um Entity Manager injetado em uma classe de serviço para fazer acesso aos dados, porém, grandes projetos corporativos podem ainda necessitar da camada de DAO. Veja na figura abaixo um diagrama de classes representando o padrão DAO em Java EE: Figura 3. Padrão DAO em Java EE 6 5. Persistent Domain Object (Business Object) O Objetivo deste padrão é implementar um modelo de domínio com a lógica de negócios e seus relacionamentos. Em J2EE, o uso de modelos procedurais já eram condenados, porém, a tecnologia não ajudava o desenvolvedor com ferramentas que o ajudassem no seu trabalho. Mais tarde, ferramentas como Hibernate foram desenvolvidas tornando a persistência nos modelos de domínio transparente Problema O uso de roteiros de transação em aplicações funciona bem até que seja necessário colocar comportamentos específicos em objetos. Muitas vezes, esses comportamentos específicos são implementados com o uso de estruturas condicionais (if, else...) tornando o código difícil de manter, testar e de evoluir. O uso do modelo procedural infere em modelos anêmicos (classes sem lógica de negócio, somente com getters e setters) que não aproveitam os recursos da orientação à objetos como polimofirmo e herança, obrigando que as verificações sejam feitas em classes de Serviços ou Façades. A maioria destes problemas é causada pela falta de orientação a objetos na camada de persistência da aplicação Forças A lógica de negócios é complexa O modelo conceitual pode ser derivado a partir dos requisitos e mapeado para objetos de domínio.

8 Os objetos de domínio precisam ser mantidos em um banco de dados relacional (é o caso mais comum). Os casos de uso, histórias de usuários ou outros documentos de especificação já descrevem o domínio de destino de forma orientada a objetos. A relação entre o comportamento e os dados podem ser derivados a partir da especificação Solução A solução é se preocupar primeiramente com a lógica de negócios e modelar as classes sem se preocupar com a camada de persistência. Questões como a modelagem de classes coesas com estado encapsulado, comportamento co-relacionado e herança devem ser priorizadas. A JPA é bastante flexível e pode se adequar facilmente a um modelo rico de objetos. Classes que utilizam heranças e pesquisas polimórficas são perfeitamente mapeadas em seus objetos de domínio. Modelos anêmicos não possuem, por definição, comportamento o que leva a lógica da aplicação para classes de serviços. Essas classes precisam acessar atributos do modelo, e isso é feito geralmente com getters e setters. Este tipo de abordagem não apresenta um grande problema, mas ofusca a lógica de domínio da aplicação. O maior problema está nas estruturas condicionais que são exigidas para diferenciar os tipos de entidade. Essas estruturas são necessárias para compreender o comportamento dependente do tipo de uma forma procedural. 6. Transfer Object e Data Transfer Object O surgimento desse padrão se deu pela necessidade de transferir múltiplos dados entre aplicações corporativas ou camadas remotas. Em J2EE, a utilização de sucessivas chamadas a métodos remotos para buscar atributos causava danos no desempenho da aplicação. Como solução, criaram objetos de transferência de dados (DTO) para diminuir este impacto. Porém, com a chegada do Java EE e a introdução do JPA, o problema original para qual este padrão foi criado, foi solucionado Problema Em Java EE, o desprendimento de entidades persistentes solucionou o problema original. Não há mais a necessidade de se criar mais uma camada para transferir dados, bastando apenas a entidade JPA implementar a interface java.io.serializable, tornando possível sua navegação por camadas locais ou remotas. Em J2EE, o bean CMP (Container Managed Persistent) não era serializável, o que obrigava o desenvolvedor a implementar uma nova camada na aplicação. Os DTO se tornaram aplicáveis em Java EE quando se deseja fornecer diversas visões para a camada de persistência sem alterar a interface externa. Isto é muito utilizado no mundo SOA, já que mudanças internas não podem quebrar o contrato de serviço. Sua aplicação como proxy se dá no ambiente SOA - um DTO pode ser utilizado como proxy para reduzir o acoplamento entre serviços inter-relacionados e quando se deseja melhorar o desempenho de casos de uso que possuem entidades fortemente

9 conectadas. É mais rápido transferir apenas um subconjunto de entidades interrelacionadas e que são de interesse do consumidor, do que transferir todas entidades Forças Há a necessidade manter o serviço externo compatível. As mudanças de um cliente não devem afetar os outros. A transferência de dados entre entidades profundamente interligadas precisa ser otimizada. É necessário diferentes visões para um único modelo de domínio. Os dados de recursos e sistemas de informação devem ser transferidos para o cliente. Há a necessidade de se comunicar com um legado, de recursos orientados para o conjunto de dados com POJOs. Transportar meta-dados da camada de apresentação para construção de UI s em tempo real. Entidades JPA orientadas a objeto precisam ser transformadas em um formato simplificado para a transferência de dados sobre RESTFul, SOAP, CORBA, ou até mesmo ASCII Solução A solução para este problema se tornou trivial com a chegada da interface java.io.serializable no jdk 1.1. Em caso de transportamos a entidade para outra JVM, precisamos apenas que a entidade implemente a interface java.io.serializable. Desta forma, o estado do objeto é transportado pelos atributos e são acessíveis por meios de métodos getters e setters, utilizando reflexão. Veja o exemplo abaixo:

10 Para melhorar a performance, podemos, ao invés de utilizar a interface Serializabe, utilizarmos Externalizable, que diminui o tamanho dos dados trafegados além de evitar o uso da reflexão: 7. Conclusão Neste trabalho foi apresentado alguns dos principais padrões utilizados no Java EE 7. Como vimos, estes padrões resolvem uma série de problemas que o desenvolvimento utilizando Java nos traz. Alguns destes padrões foram remodelados, a partir do catálogo de padrões e boas práticas blueprints do J2EE, para o Java EE, tornando mais simples desenvolver aplicações em Java. Vale salientar que a aplicação de padrões exige um estudo detalhado do problema, identificando todas suas variáveis e avaliando qual será o impacto da utilização daquele padrão na arquitetura do sistema. Portanto, aplicar padrões é uma forma segura de resolver problemas já conhecidos no desenvolvimento de sistema e sua utilização deve-se restringir somente em casos que haja realmente a necessidade, pois sua aplicação sem um estudo prévio e profundo pode tornar a arquitetura confusa, além de não conseguir resolver o problema em questão. 8. Referências BIEN, Adam. Real World Java EE Patterns: Rethinking Best Practices. [s. L.]: Lulu.com, p. GAMMA, Erich et al. Design patterns: elements of reusable object-oriented software. Pearson Education, Linha de Código, Design Patterns Fundamentais do J2EE. Disponível em: < Acesso em 04 de maio de 2014.

11 Oracle, Java BluePrints. Disponível em: < Acesso em 31 de outubro de Caelum, O que é java. Disponível em: < Acesso em 10 de outubro de 2014.