Artigo Java Magazine 14 - Java livre

Entity Beans no JBoss

Parte 1: CMP e CMR em exemplos

Persistência de objetos e relacionamentos com segurança e escalabilidade

Amada por uns e odiada por outros, a especificação Enterprise JavaBeans (EJB) é o coração de grandes sistemas desenvolvidos com a plataforma J2EE. Uma parte importante da especificação são os mecanismos de persistência CMP e CMR, que permitem desenvolver a camada de persistência de uma aplicação de modo orientado a objetos, sem a necessidade de lidar com tabelas, linhas e colunas nas classes de negócios.

Infelizmente, a especificação EJB, mesmo em sua versão mais recente (2.1), omite detalhes em pontos importantes. Isso leva na prática a sistemas que não são facilmente portados entre servidores de aplicações diferentes, e estimula desenvolvedores desiludidos (ou pouco persistentes) a adotar alternativas como JDO ou Hibernate. Por outro lado, a especificação EJB evoluiu muito desde a sua versão 1.0 e será a melhor solução para persistência em uma grande variedade de sistemas.

Neste artigo veremos de maneira prática como implementar entity beans, com exemplos escritos para o servidor livre JBoss, além de mostrar onde a portabilidade da sua aplicação pode ser comprometida. Algum conhecimento prévio sobre EJBs será de grande valia – mas não imprescindível – para a execução e o entendimento dos exemplos apresentados. E, curiosamente, muito pouco deste artigo será realmente específico para o JBoss; com poucas adaptações – talvez nenhuma – os exemplos poderão ser executados em outros servidores J2EE disponíveis no mercado.

Nossos exemplos serão focados na versão 2.0 da especificação. Isso porque o JBoss 3.2.x, assim como a maioria dos servidores J2EE no mercado, ainda não foi atualizado para o EJB 2.1. De toda forma, as mudanças são pequenas, especialmente nas áreas de EJB aqui tratadas (mostraremos algumas delas no decorrer do artigo).

A abordagem será de “aprenda com exemplos”, que oferece resultados rápidos mas não substitui uma base sólida nos conceitos e tecnologias abordados; para tal o leitor deve recorrer à documentação indicada ao final do artigo. Recomendo ainda a consulta aos artigos “JBoss Inicial” (Edição 5) e “Banco de Dados com JBoss” (Edição 8), além dos "Tira-dúvidas" sobre pacotes J2EE publicados nas Edições 9 e 10.

Esta é a primeira parte de uma série de dois artigos. A segunda parte tratará de tuning dos mecanismos de persistência e otimizações de acesso ao banco de dados subjacente.

Entity beans CMP e BMP

Entity beans são componentes persistentes, cujo estado é preservado entre diferentes sessões do usuário, ou entre reinicializações do container. São identificados por um atributo chamado de chave primária, em analogia aos bancos relacionais; podem ser de dois tipos: CMP (Container Managed Persistence – persistência gerenciada pelo container) ou BMP (Bean Managed Persistence – persistência gerenciada pelo bean).

Durante a versão 1.x da especificação de EJB o tipo BMP foi muito popular, não pelas suas vantagens, mas pelas deficiências do CMP original. O uso do BMP tornava entity beans ruins em termos de performance, exigindo grande quantidade de acessos ao banco, além de forçar o desenvolvedor a enxergar seus dados sob a ótica relacional – o que ia contra um dos principais propósitos de usar entity beans: enxergar os dados como objetos.

A partir da versão 2.0 o CMP se tornou poderoso o suficiente para aplicações do “mundo real”. Com isso, hoje o uso de BMP deve ser reservado apenas para situações especiais, no caso dos recursos de persistência do container não atenderem às necessidades da aplicação – por exemplo, se seu container é capaz de lidar apenas com bancos relacionais, mas sua aplicação necessita manipular também informações em um banco de dados legado (como o IMS do mainframe); ou se a aplicação precisa consultar informações de um diretório LDAP.

Entity beans CMP têm toda a interação com o banco de dados gerenciada pelo container EJB, que decide quando e como recuperar ou atualizar os dados. Bons containers manterão um extenso cache de entity beans, de modo que manipular informações pelo código Java pode fazer mais sentido do que programar stored procedures no banco de dados. Containers de qualidade também postergarão atualizações até o final da transação, para minimizar a quantidade de comandos UPDATE requeridos.

Um entity bean é pouco mais que uma coleção de atributos e seus métodos get/set – além de um ou mais métodos de criação e um método de deleção. Não há métodos explícitos de atualização ou de recuperação de informações do banco. Pressupõe-se que os resultados dos métodos get/set reflitam sempre o estado corrente do banco de dados. Isto significa que a lógica de negócios construída sobre entity beans costuma ser mais simples do que seria com o uso de chamadas JDBC ou com o uso de DAOs (Data Access Objects).

Primeiro entity bean

A definição de um componente EJB inicia-se pela sua interface local do componente (ou então pela sua interface remota); na Listagem 1 é mostrada a interface local (o tipo recomendado para entity beans). A interface home é definida na Listagem 2. O exemplo é uma aplicação simples de agenda de contatos corporativos.

Iniciamos pela entidade “Categoria”, que seria utilizada para filtrar os contatos, como amigos, colegas de trabalho, família, grupo de usuários etc. (no texto, será às vezes usado o termo "entidade" como sinônimo de entity bean). É uma prática padrão não expor os atributos individuais de uma entidade, mas fazê-lo por meio de um Value Object (veja mais adiante a seção “Padrões de projeto para EJBs”). O Value Object, ou VO,"