Artigo da SQL Magazine 40 - Persistência com EJB 3.0

Clique aqui para ler esse artigo em PDF.

Clique aqui para ler todos os artigos desta edição

Persistência com EJB 3.0

A API de Persistência Java (JPA)

Enterprise Java Beans foram por muito tempo o patinho feio da especificação JEE. Muitos desenvolvedores já descobriram funcionalidades poderosas como Session Beans, Message Driven Beans e TimeServices, entretanto a complexidade de uso de tais recursos aliado à deficiência dos serviços de persistência dificultaram a adoção da tecnologia e impulsionaram o uso de soluções alternativas como o Hibernate e o Oracle TopLink. A boa notícia é que a especificação EJB 3.0, mais simples e turbinada, pretende colocar os polêmicos Enterprise Java Beans novamente em foco, mas desta vez, como atores principais e não meros coadjuvantes.

A finalidade do EJB 3.0 é melhorar a arquitetura EJB reduzindo a sua complexidade do ponto de vista dos desenvolvedores. A especificação EJB 3.0 foi definida pela JSR-220 (Enterprise JavaBeans, Version 3.0), finalizada em 11 de maio de 2006. Parte dessa especificação é a nova API de persistência Java (JPA). Esta API de persistência é o novo padrão para soluções de mapeamento objeto-relacional em Java. Este artigo vai explorar os fundamentos desta nova API e fornecerá exemplos práticos de códigos que servirão como ferramentas para ajudar os desenvolvedores a começarem rapidamente a utilizar esta API.

O que é a persistência em EJB 3.0

A persistência EJB 3.0 utiliza o mapeamento objeto-relacional para minimizar o “gap” existente entre o nosso modelo orientado a objetos e o banco de dados relacional. As aplicações escritas usando a API de persistência Java devem ser portáveis para muitas bases de dados relacionais.

A implementação da JPA é feita por um “provider” de persistência. Esse “provider” define como as coisas funcionam através da implementação de todas as interfaces definidas pela especificação da JPA. Com isso, podem existir várias implementações da JPA. Além de ser portável entre bases de dados relacionais, uma aplicação bem projetada em EJB 3.0 deve ser portável também em termos do “provider” de persistência. Essa portabilidade significa que a aplicação deverá funcionar com implementações de “providers” de fabricantes distintos, que estejam em conformidade com a JSR-220, sem nenhum esforço adicional.

Enterprise Java Beans foram tradicionalmente associados com containers pesados como JBoss, Websphere, WebLogic e outros. Estes containers fornecem muitos serviços para as aplicações distribuídas, porém eles não são necessariamente parte de uma aplicação EJB 3.0. Para muitas aplicações, este cenário de distribuição pode ainda fazer sentido, entretanto, a API de Persistência Java é especificamente projetada para ser usada com ou sem um container. Em particular, o “provider” de persistência é necessário pela especificação para trabalhar fora do “container”.

Os requisitos

Para começar a trabalhar com a persistência em EJB 3.0 precisamos de alguns itens instalados:

·         Provider de persistência EJB 3.0;

·         Banco de dados relacional;

·         Driver JDBC.

Os exemplos apresentados nesse artigo devem trabalhar com muitas combinações das ferramentas apresentadas na lista anterior. Recordando que um dos grandes benefícios de utilizarmos os padrões especificados é que você não está amarrado a um fornecedor.

O Hibernate é o framework livre e de código aberto mais popular que implementa a JPA. Os exemplos apresentados aqui foram desenvolvidos usando o Hibernate 3.2.0 em conjunto com o Hibernate Entity Manager 3.2.0. Todos os códigos apresentados neste artigo devem funcionar com essas versões de Hibernate ou qualquer outra implementação, de outro fabricante, que esteja em conformidade com a JSR-220. Lembre-se de que a JSR-220 é apenas uma especificação e podem existir várias implementações desta especificação.

O EntityManager

O EntityManager no EJB 3.0 é responsável por consultar e gerenciar as entidades persistentes conhecidas como Entidades. O EntityManager é o início da maioria das operações de persistência. A técnica para recuperar um EntityManager em um ambiente Java EE é ligeiramente diferente da técnica para recuperar  um EntityManager em um ambiente Java SE. Por simplicidade, os exemplos aqui apresentados estão focados no ambiente Java SE, assim, nenhum container precisa ser configurado. Na Listagem 1 temos o trecho de código referente à criação do EntityManager a partir de uma EntityManager Factory em um ambiente Java SE.

Listagem 1. Criação do EntityManager.

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

...

EntityManagerFactory emf =

  Persistence.createEntityManagerFactory("mycontext");

EntityManager em = emf.createEntityManager();

Para que uma entidade se torne persistente é necessário associá-la a um contexto de persistência, que fornece a conexão entre as instâncias e o banco de dados. A manipulação destas instâncias é feita, a partir desse contexto, por meio do gerenciador de entidades (EntityManager). O gerenciador de entidades na JPA é uma instância da interface javax.persistence.EntityManager.

O primeiro parâmetro do método createEntityManagerFactory é o nome do contexto persistente. Este contexto de persistência precisa ser configurado no arquivo persistence.xml. Este arquivo de configuração precisa estar localizado no diretório /META-INF ou em algum arquivo “.jar” que esteja no seu CLASSPATH. Se o arquivo de configuração não estiver em um arquivo “.jar”, tenha cuidado como o CLASSPATH é configurado. O arquivo de configuração precisa ser carregado como um recurso chamado META-INF/persistence.xml, então se o arquivo está em /local/dev/stuff/META-INF/persistence.xml precisamos ter o caminho /local/dev/stuff/ no CLASSPATH, e não /local/dev/stuff/META-INF/. Na Listagem 2 é apresentado o exemplo de um descritor de contexto de persistência.

Listagem 2. Descritor do contexto de persistência.

org.hibernate.ejb.HibernatePersistence

com.persistencedemo.Pessoa

com.persistencedemo.Empregado

com.persistencedemo.OutraClasse

Na Listagem 2, o nome da unidade de persistência () é um rótulo arbitrário, você escolhe um nome e este nome será utilizado mais tarde para fazer referência a esse contexto de persistência. O descritor pode conter uma ou várias unidades de persistência, e cada uma deve ter um nome. Este nome é o primeiro argumento para o método Persistence.createEntityManagerFactory do código java apresentado anteriormente. Se o descritor contiver mais de uma unidade de persistência, cada uma deve ser configurada com seus próprios parâmetros. O nome passado para o método Persistence.createEntityManagerFactory utiliza o mecanismo de persistência desta configuração passada.

O elemento define o nome do provedor de persistência. Este nome é um nome específico e dependente do fornecedor do provider. No nosso caso, org.hibernate.ejb.HibernatePersistence é o nome do provedor do Hibernate.

O arquivo descritor contém ainda o elemento para cada tipo de entidade associada com sua unidade de persistência. As entidades serão descritas com mais detalhes mais adiante.

Como pode ser visto na Listagem 2, dentro do elemento existem quantos elementos . Este elemento permite que propriedades arbitrárias sejam atribuídas e passadas para o provedor de persistência. Estas propriedades são normalmente configurações específicas do fornecedor da classe do provedor."