CAPÍTULO 1 1

O que é o que é no EJB 3

Parte 1

Visão Panorâmica
do EJB
O conteúdo deste livro é destinado ao EJB 3, a nova versão do padrão Enterprise
Java-Beans. O renascimento oportuno do EJB foi possível graças às inovações
apresentadas no Java SE 5, como as anotações de metadados e a adoção de idéias
como a injeção de dependência e a persistência baseada no mapeamento objeto-
relacional (ORM).

O Capítulo 1 apresenta o EJB como uma tecnologia. O capítulo também menciona

a força única que o EJB possui como uma plataforma de desenvolvimento e os
novos recursos que promovem produtividade e a facilidade de utilização. O Capítulo
2 fornece amostras de códigos reais e apresenta uma aplicação ActionBazaar, sistema
de empresa imaginária desenvolvida neste livro. O Capítulo 2 é o mais intensivo
sobre códigos que este livro apresenta. Nosso objetivo é fazer com que você saiba
como o EJB funciona de maneira rápida e fácil.

Esta parte apresenta o EJB 3 como uma plataforma poderosa e muito útil e um
padrão em prática para o desenvolvimento de empresas de missão crítica.

Passamos também rapidamente pelo Java Persistence API, uma tecnologia que
ajuda a padronizar o Java ORM e a expandir o EJB 3 além dos limites tradicionais
das aplicações client-server voltadas para a web gerenciadas pelos containers.
2 EJB 3 em Ação
 CAPÍTULO 1 3
O que é o que é no EJB 3

Este capítulo abrange

1
O que é o que é
no EJB 3

! O EJB como componente e framework

! Os tipos de EJB

! Os containers EJB containers e o fornecedor de persistência

! As razões para escolher o EJB 3

4 EJB 3 em Ação

Um dia, quando Deus estava examinando superficialmente suas criaturas, reparou em um garoto
chamado Sadhu, cujo humor e inteligência agradaram-no. Deus estava generoso aquele dia e
concedeu a Sadhu três desejos. Sadhu pediu a ele três reencarnações - uma como joaninha,
outra como elefante e a última como vaca. Surpreso com esses três desejos, Deus pediu que
Sadhu se explicasse. O garoto respondeu, “Eu quero ser uma joaninha para que todos possam
me admirar pela beleza e perdoar o fato de eu não trabalhar. Ser um elefante será divertido, pois
posso engolir quantidades enormes de comida sem parecer ridículo. E eu gostaria de ser uma
vaca, pois seria amado por todos e útil à humanidade.” Deus se encantou com as respostas e
permitiu que Sadhu vivesse essas três encarnações. Ele, então, tornou Sadhu a estrela da manhã
pelo seu serviço à humanidade como uma vaca.

O EJB também viveu suas três encarnações. Quando foi lançado pela primeira vez, a indústria
se encantou com suas inovações. Como a joaninha, o EJB 1 tinha suas funcionalidades limitadas.
A segunda encarnação do EJB foi quase tão pesada quanto o maior dos nossos queridos
paquidermes. As almas guerreiras que não podiam ficar sem o seu poder de elefante tiveram que
domesticar a complexidade impressionante do EJB 2. E, finalmente, em sua terceira encarnação,
o EJB se tornou muito mais útil para as pessoas, como o amável bovino que era sacrificado pelos
Hindus e respeitado como uma mãe, cujo leite alimentava a todos.

Muitas pessoas trabalharam muito para fazer com que o EJB 3 fosse o mais simples e leve
possível sem sacrificar o poder imediato da empresa. Os componentes do EJB estão agora um
pouco menores do que os objetos Java (POJOs) que parecem como um código em um programa
Hello Word. Esperamos que você concorde conosco ao ler os próximos capítulos, em que estrela
é o EJB 3.

Fizemos grande esforço para manter este livro o mais prático possível, sem restringir seu
conteúdo. O livro tem a intenção de ajudá-lo a aprender sobre EJB 3 da maneira mais rápida e
eficaz possível. Ao mesmo tempo, não descuidaremos do que é fundamental. Também nos
aprofundaremos nos pontos desejados, compartilhando com você todos os pontos de vista
surpreendentes que descobrimos e advertiremos você contra as emboscadas mais perigosas.

Este livro fala sobre a transformação radical de uma tecnologia importante e única do mundo
Java. Presumimos que você não tenha pegado este livro para aprender muito sobre o EJB 2.
Você, provavelmente, já deve conhecer o EJB ou ele é um ambiente completamente novo para
você. Nos dois casos, gastar muito mais tempo nas versões anteriores é uma perda de tempo você
não ficará surpreso ao saber que o EJB 3 e 2 têm pouca coisa em comum. Se você tem curiosidade
nesta empreitada que nos traz ao ponto atual, ajudamos você a pegar um dos vários bons livros
sobre as versões anteriores do EJB.

Nosso objetivo neste capítulo é informar a você o que é o que no EJB 3, explicar porque você
deve usá-lo e, para os veteranos em EJB, resumir as melhoras significantes da nova versão
oferecida. Vamos, então, pular direto para o código no próximo capítulo para se basear neste.
Com esses objetivos em mente, vamos iniciar agora com uma ampla visão geral do EJB.

1 . 1 Visão Geral do EJB

Falando claramente, Enterprise JavaBeans (EJB) é uma plataforma para construção de aplicações
corporativas portátil, reutilizável e escalável, que utiliza a linguagem Java. Desde seu início, o
EJB tem sido considerado um modelo de componente ou framework que permite que você
construa aplicações corporativas Java sem ter que reinventar serviços necessários para a construção
de uma aplicação, como as transações, seguranças, persistência automatizada e assim por diante..
 CAPÍTULO 1 5
O que é o que é no EJB 3

O EJB permite que os desenvolvedores de aplicação se foquem na construção corporativa lógica

sem ter que perder tempo na construção do código de infra-estrutura.

Do ponto de vista do desenvolvedor, um EJB é um pedaço do código Java que executa em um

ambiente de tempo de execução especializado chamado container EJB, que fornece um número
de componentes de serviços. Os serviços de persistência são fornecidos por um framework
especializado chamado de fornecedor de persistência. Falaremos mais sobre o container EJB,
fornecedor de persistência e serviços na seção 1.3.

Nesta seção, você aprenderá de que forma o EJB funciona como um componente e um framework.
Vamos examinar também como o EJB serve para construir aplicações multi-camadas.

Concluiremos esta seção listando os motivos pelos quais o EJB pode ser ideal para você.

1.1.1 EJB como um componente

Neste livro, quando falamos sobre EJB´s, estamos nos referindo aos componentes server-side
que você pode utilizar para construir partes de sua aplicação, como a lógica corporativa ou o
código de persistência. Muitos de nós associamos o termo componente ao desenvolvimento
complexo, CORBA mais leve e código Microsoft COM+. No magnífico mundo novo do EJB 3,
um componente é o que deve ser – nada mais do que um POJO com alguns poderes especiais.
Esses poderes permanecem invisíveis até que sejam necessários e não se descuidam do propósito
real do componente. Você verá isto em primeira mão neste livro, começando no capítulo 2.

A idéia real atrás de um componente é que ele encapsule com eficácia o comportamento da
aplicação. Os usuários de um componente não são necessários para conhecer suas operações
internas. Tudo o que precisam saber é como ir além e o que esperar de volta.

Há três tipos de componentes EJB: beans de sessão, beans dirigidos por mensagem e entidades.
Os beans de sessão e os beans dirigidos por mensagem são usados para implementar a lógica
corporativa em uma aplicação EJB e as entidades são usadas para persistência.

Os componentes podem ser reutilizáveis. Por exemplo, suponha que você é encarregado pela
construção de um site para um comércio online que venda livros sobre tecnologia. Você
implementa um módulo para usar cartão de crédito como parte de um objeto Java comum. Sua
empresa vai muito bem e você muda o foco inicial de vendas. A empresa decide, então, diversificar
e começa a desenvolver um site para venda de CDs e DVDs. Como o ambiente de distribuição
para o novo site é diferente, ele não pode ser colocado no mesmo servidor que seu módulo. A
pessoa que construiu o novo site é forçada a duplicar seu módulo de cartão de crédito no site
novo, pois não há maneira mais fácil para acessar seu módulo. Se você já tivesse implementado
o cartão de crédito - módulo de carga como um componente EJB conforme mostrado na figura
1.1 (ou como um serviço web), teria sido muito mais fácil para a pessoa acessá-lo, simplesmente
fazendo uma ligação quando precisasse daquela funcionalidade. Ela poderia ser reutilizada sem
ter que entender sua implementação.

Dado isto, construir um componente reutilizável requer um planejamento cuidadoso, pois,

além das aplicações empresariais, muito da lógica corporativa pode ser reutilizada. Portanto,
você pode não se importar com a reusabilidade dos componentes EJB, mas o EJB ainda tem
muito a oferecer como um framework, como você descobrirá na próxima seção.
6 EJB 3 em Ação

Figura 1.1

O EJB permite o desenvolvimento dos

componentes reutilizáveis. Por
exemplo, você pode implementar o
cartão de crédito – módulo de carga
como um componente EJB que pode
ser acessado por aplicações múltiplas.

1.1.2 EJB como um framework

Como mencionamos, os componentes EJB vivem em um container. Juntos, os componentes ou
EJBs e o container podem ser vistos como um framework que fornece serviços valiosos para o
desenvolvimento de aplicação corporativa.

Embora muitas pessoas achem que os EJBs arrasam no desenvolvimento relativamente simples
das aplicações web de tamanho moderado, nada poderia ir além da verdade. Quando você
constrói uma casa, você não constrói nada a partir do esboço. Ao invés disso, você compra
materiais ou mesmo os serviços de um empreiteiro conforme necessita. Da mesma forma, não é
muito prático construir uma aplicação para empresa a partir de um esboço. Muitas aplicações
Lado-servidor têm muito em comum, inclusive a lógica corporativa, o estado de aplicação de
gerenciamento, armazenamento e recuperação de informação a partir de um banco de dados
relacional, transações de gerenciamento, implementação de segurança, realização de
processamento assíncrono, sistemas de integração e assim por diante.

Como um framework, o container EJB fornece esses tipos de funcionalidade em comum como
serviços funcionais e fáceis de serem usados para que seus componentes EJB possam usá-los em
suas aplicações sem ignorá-las. Por exemplo, vamos afirmar que quando você constrói o módulo
do cartão de crédito em sua aplicação web, escreve vários códigos complexos e suscetíveis a erro
para gerenciar transações e controle de acesso de segurança. Você poderia ter evitado isso,
usando a transação declarativa e os serviços de segurança fornecidos pelo container EJB. Esses
serviços, assim como muitos outros que você conhecerá na seção 1.3, estão disponíveis nos
componentes do EJB quando forem distribuídos no container EJB, conforme pode ser visto na
figura 1.2. Isto significa escrever aplicações de alta qualidade e ricas em recursos da forma mais
fácil que você possa imaginar.

O container fornece os serviços aos componentes do EJB de uma maneira nova e melhor: as
anotações de metadados são usadas para pré-configurar os EJBs, especificando os tipos de
serviços para adicionar quando o container distribuir os EJBs.

O Java 5 apresentou as anotações de metadados, que são configuradas adequadamente e marcam

um pedaço do código, como uma classe ou método, tendo atributos particulares. É um estilo
declarativo de programação, no qual o desenvolvedor especifica o que deve ser feito e o sistema
adiciona o código a ele.
 CAPÍTULO 1 7
O que é o que é no EJB 3

Figura 1.2

EJB como um framework fornece

serviços aos componentes do EJB.

No EJB, as anotações de metadados simplificam o desenvolvimento e teste das aplicações, sem

depender de um arquivo de configuração XML externo, permitindo que os desenvolvedores
adicionem serviços aos componentes do EJB quando e onde forem necessários. Conforme
representado na figura 1.3, uma anotação transforma um simples POJO em um EJB.

Conforme você aprenderá, as anotações são usadas em toda a parte do EJB e não apenas para
especificar serviços. Por exemplo, uma anotação pode ser usada para especificar o tipo de
componente do EJB.

Embora algumas vezes seja fácil de esquecer, as aplicações empresariais têm mais uma coisa em
comum com uma casa. Ambos foram projetados para durar muito mais do que se possa imaginar.
Capazes de suportar alto desempenho e tolerância à falha, as aplicações escaláveis são um assunto
positivo na plataforma EJB, ao invés de ser uma reflexão tardia.

Você será capaz não só de escrever boas aplicações server-side mais rápidas como também pode
esperar que sua plataforma cresça com o sucesso de sua aplicação. Quando a necessidade de
suportar um grande número de usuários se tornar realidade, você não precisará reescrever seu
código. Quem cuidará desses assuntos serão os fornecedores de container. Você poderá mover
sua aplicação a um servidor distribuído agrupado, apenas configurando-o.

Por último, mas com certeza não menos importante, em um mundo louco por arquitetura
orientada à serviço (SOA) e interoperabilidade, o EJB permite que você transforme sua aplicação
em fonte de influência de serviços web com facilidade quando precisar.

O framework do EJB é um padrão da tecnologia Java com uma especificação aberta. Se gostar,
você pode conferí-lo no site do Java Community Process (JCP) www.jcp.org/en/jsr/detail?id=220.
O EJB é suportado por um grande número de empresas e grupos abertos com implementações
concorrentes, mas compatíveis. Por um lado, indica que um grande grupo de pessoas irá trabalhar
muito para manter o EJB competitivo. Por outro, a portabilidade fácil significa que você possa
escolher quais implementações combinam melhor, fazer sua aplicação portátil além dos containers
EJB a partir de fornecedores diferentes.

POJO
POJO AnotaÁ„o
Anotação EJB
EJB

Figura 1.3 EJBs são objetos Java regulares que podem ser configurados usando anotações de
metadados.
8 EJB 3 em Ação

Agora que já fornecemos uma introdução mais avançada ao EJB, vamos voltar nossa atenção
sobre como o EJB pode ser usado para construir aplicações multi-camadas.

1.1.3 Arquiteturas multi-camadas e EJB

Muitas aplicações empresariais contêm um grande número de componentes. As aplicações
empresariais são projetadas para solucionar um tipo exclusivo de problema do cliente, mas eles
possuem muitas características em comum. Por exemplo, muitas aplicações empresariais possuem
algum tipo de interface de usuário e implementam processos empresariais, exibem um domínio
de problema e salvam os dados em um banco de dados. Por causa desses atributos comuns, você
pode seguir uma arquitetura comum ou projetar um princípio para construir as aplicações
empresariais, conhecido como modelos.

Para um desenvolvimento server-side, os modelos dominantes são as arquiteturas multi-camadas.

Em uma arquitetura multi-camadas, os componentes são agrupados em camadas. Cada uma
possui um propósito bem definido, classificado como uma declaração, bastante parecido com
uma seção de linha de montagem de uma fábrica. Cada seção da linha de montagem executa
uma tarefa que lhe foi designada e passa o restante do trabalho para a linha seguinte. Na
arquitetura multi-camadas, cada camada delega trabalho à camada inferior.

O EJB permite que você construa aplicações usando duas arquiteturas em camadas diferentes:
a arquitetura tradicional de quatro camadas e o design orientado ao domínio (DDD). Vamos dar
uma breve olhada em cada uma dessas arquiteturas.

Arquitetura tradicional de quatro camadas

A figura 1.4 mostra a arquitetura tradicional de quatro camadas. Ela é muito intuitiva e possui
grande popularidade. Nesta arquitetura, a camada de apresentação é responsável por reproduzir
a interface gráfica de usuário (GUI) e manipular a entrada de usuário. A camada de apresentação
transmite cada solicitação para a funcionalidade de uma aplicação à camada de lógica de negócios.
A camada de lógica de negócios é o coração da aplicação e contém o fluxo de trabalho e a lógica
de processamento. Em outras palavras, os componentes da camada de lógica modelam ações ou
processos que a aplicação pode realizar, como billing, buscas, pedidos e manutenção da conta do
usuário.

Figura 1.4

Muitas aplicações empresariais

tradicionais possuem, no mínimo, quatro
camadas. 1) A camada de apresentação é
a interface de usuário atual e pode ser
tanto um browser quanto uma aplicação
de desktop. 2) A camada de lógica de
negócios define as regras da empresa.
3) A camada de persistência lida com as
interações dos bancos de dados. 4) A
camada de banco de dados consiste em
um banco de dados relacional, como o
Oracle, que armazena os objetos de
persistência.
 CAPÍTULO 1 9
O que é o que é no EJB 3

A camada de lógica de negócios recupera e salva informações de um banco de dados por meio
da utilização da camada de persistência, que fornece uma abstração do objeto orientado de
alto nível (OO) sob a camada de banco de dados. A camada de banco de dados consiste
basicamente no sistema de gerenciamento de banco de dados relacional (RDBMS), como Oracle,
DB2 ou SQL Server.

O EJB não é, obviamente, uma apresentação de tecnologia de camada. O EJB é um suporte

robusto para implementar a lógica corporativa e as camadas de persistência. A figura 1.5 mostra
como o EJB suporta essas camadas por meio de seus serviços.

Na seção 1.3, veremos mais detalhes sobre os serviços do EJB. E, na seção 2.1, exploraremos os
tipos de beans do EJB. Por hora, observe apenas que os tipos de beans são chamados beans de
sessão e os beans dirigidos por mensagem (MDBs) residem e usam serviços da camada de lógica.
Já os tipos de beans chamados entidades residem e usam os serviços na camada de persistência.

Figura 1.5

Serviços de componentes
oferecidos pelo EJB 3 em
cada camada de aplicação
suportada.

Observe que cada serviço é

independente do outro,
portanto você está livre para
selecionar os recursos
importantes para sua apli-
cação. Você aprenderá mais
sobre esses serviços na
seção 1.3.

A arquitetura tradicional de quatro camadas não é perfeita. Um dos pontos mais desfavoráveis é
que ela enfraquece o ideal de modelagem OO do domínio corporativo, como objetos que
encapsulam tanto os dados quanto o comportamento. Como a arquitetura tradicional se concentra
na modelagem dos processos empresariais, ao invés do domínio, a camada de lógica empresarial
tende a parecer mais como uma aplicação procedural dirigida por banco de dados do que com
um OO. Como os componentes de camada de persistência são simples portadores de dados, eles
se parecem muito mais com as definições de registros de bancos de dados do que com cidadãos
da primeira classe do mundo OO. Como você verá na próxima seção, DDD propõe uma
arquitetura alternativa que tente solucionar esses problemas percebidos.

Design orientado ao domínio

O termo design orientado ao domínio (DDD) pode ser relativamente novo, mas o conceito não é
(consulte Domain-driven design: Tackling Complexity in the Heart of Software (Design orientado ao
domínio: Lidando com a Complexidade no Coração do Software), de Eric Evans [Addison-
Wesley Professional, 2003]). DDD enfatiza que o domínio objetos deve conter lógica de negócios
e não deve ser apenas uma réplica burra dos registros dos bancos de dados. Os objetos de
10 EJB 3 em Ação

domínio são conhecidos como entidades no EJB 3 (consulte a seção 1.2 que discute sobre
entidades). Com o DDD, os objetos Catálogo e Cliente em uma aplicação comercial são exemplos
típicos das entidades e podem conter lógicas de negócios.

Em seu excelente livro POJOs em Ação (Manning, 2006), o autor Chris Richardson aponta o
problema ao usar objetos de domínio apenas como portador de dados.

Alguns desenvolvedores ainda visualizam objetos persistentes apenas como um meio de

obter dados dentro e fora do banco de dados e escrevem lógicas de negócios procedurais.
Eles desenvolvem o que Fowler chama de “modelo de domínio anêmico”.... Assim como
no sangue do anêmico falta vitalidade, os modelos de objeto anêmico somente modelam
superficialmente o problema e consistem em classes que implementam pouco ou nenhum
comportamento.

Além disso, mesmo com seu valor aparente, até o lançamento do EJB, era difícil implementar o
DDD. Chris continua a explicar como o EJB 2 apoiou o código procedural:

... os desenvolvedores do J2EE escrevem códigos de estilo procedural [porque] são apoiados
pela arquitetura EJB, literatura e cultura, que enfatiza os componentes do EJB. Os
componentes do EJB 2 não são adequados para implementar um modelo de objeto.

De comum acordo, implementar um modelo de domínio real foi quase impossível com o EJB 2,
pois os beans não eram POJOs e não suportaram muitos recursos OO, como a herança e o
polimorfismo. Chris trata especificamente dos beans de entidade como um problema:

Os beans de entidade do EJB 2, os quais pretendem representar os objetos corporativos,

possuem inúmeras limitações que os tornam extremamente difíceis de serem usados para
implementar um modelo de objeto persistente.

A boa notícia é que o EJB 3 permite que você siga facilmente um projeto orientado por objeto ou
DDD. As entidades definidas pelo EJB 3 Java Persistence API (JPA) suportam recursos OO,
como a herança ou polimorfismo. É fácil implementar um modelo de objeto de persistência com
o EJB 3 JPA. Além disso, você pode adicionar lógica corporativa às suas entidades de tal forma
que a implementação de um modelo de domínio rico com o EJB 3 seja uma tarefa trivial.

Observe que muitas pessoas não gostam de adicionar lógica corporativa complexa ao objeto de
domínio por si só e preferem criar uma camada para uma lógica procedural atribuída como
camada de serviço ou camada de aplicação (consulte Modelos de Arquitetura de Aplicação
Empresarial, de Martin Fowler [Addison-Wesley Professional, 2002]). A camada de aplicação é
similar à camada lógica de negócios da arquitetura de quatro camadas tradicional, mas é mais
superficial. Você pode também usar beans de sessão para construir a camada de serviço. Se você
utilizar a arquitetura tradicional de quatro camadas ou a arquitetura em camadas com o DDD,
você pode usar as entidades para modelar objetos de domínio, incluindo o estado e
comportamento. Discutiremos a modelagem de domínio com as entidades JPA no capítulo 7.

Apesar de seus serviços e pontos de vista impressionantes, o EJB não é único. Você pode
combinar várias tecnologias para igualar mais ou menos os serviços EJB e infra-estrutura.

Por exemplo, você pode usar o Spring com outras tecnologias de fonte aberta como Hibernate e
AspectJ para construir sua aplicação. E então, porque escolher o EJB 3?

Que bom que perguntou...

 CAPÍTULO 1 11
O que é o que é no EJB 3

1.1.4 Porque escolher o EJB 3?

No início deste capítulo, nos referimos ao EJB como uma tecnologia pioneira.

O EJB é uma tecnologia groundbreaking que aumentou os padrões de desenvolvimento server-

side. Como o Java, o EJB mudou algumas coisas que inspiraram muitas inovações. Na verdade,
há alguns anos o único concorrente importante do EJB veio da Microsoft .NET framework.

Nesta seção, indicaremos alguns dos recursos atrativos do EJB que certamente teremos em sua
nova versão.

Fácil de usar

Graças ao foco determinado na facilidade de uso, o EJB 3 é provavelmente a plataforma de

desenvolvimento server-side mais simples que existe. Os recursos que mais são realçados são a
programação POJO, as anotações a favor do tão falado XML, o uso intenso dos padrões sensíveis
e o JPA. Você aprenderá sobre todos esses recursos neste livro. Embora o número de serviços
EJB seja significante, você os achará muito intuitivos. Para a maioria, o EJB 3 possui uma
perspectiva prática e não necessita de que você entenda as complexidades teóricas. Na verdade,
muitos serviços EJB são projetados para dar a você uma pausa neste modo de pensar e para que
você possa se concentrar no trabalho feito e ir para casa no final do dia sabendo que concluiu
alguma coisa.

Acúmulo de soluções integradas

O EJB oferece um conjunto de soluções para servidor, incluindo persistência, messaging,

programas leves, remoting, serviços de web, injeção de dependência (DI) e interceptores. Isso
significa que você não terá que perder tempo procurando ferramentas terceirizadas para
integrar à sua aplicação. Além disso, o EJB fornece integração contínua a outras tecnologias
Java EE, como JDBC, JavaMail, Java Transaction API (JTA), Java Messaging Service (JMS), Java
Authentication Authorization Service (JAAS), Java Naming and Directory Interface (JNDI), Java
Remote Method Invocation (RMI) e assim por diante. O EJB garante também a integração contínua
entre tecnologias de camada de apresentação como JavaServer Pages (JSP), servlets, JavaServer
Faces (JSF) e Swing.

Padrão aberto Java EE

O EJB é uma parte crítica do padrão Java EE. Se você vai adotar o EJB, é fundamental que
entenda esse conceito. O EJB possui uma especificação API pública aberta, que as empresas
utilizam para criar um container ou a implementação do fornecedor de persistência. O padrão
EJB é desenvolvido pelo Java Community Process (JCP) e consiste em um grupo de pessoas não
exclusivas dirigidas pelo padrão Java. O padrão aberto leva os fornecedores com o EJB a ter um
suporte maior, o que significa que você não precisará depender de uma solução proprietária.

Suporte maior ao fornecedor

O EJB é suportado por uma grande variedade de empresas independentes. Incluindo as maiores
empresas do ramo de tecnologia do mundo, muito respeitadas e financeiramente estabilizadas,
como a Oracle e a IBM, assim como os grupos JBoss e Geronimo.

O suporte amplo ao fornecedor se traduz em três vantagens importantes para você. Primeira,
você não está a mercê dos altos e baixos de uma empresa particular ou grupo de pessoas.
Segunda, muitas pessoas possuem interesses a longo prazo para manter a tecnologia o mais
competitiva possível. Você pode ser capaz de levar vantagem das melhores tecnologias dentro ou
12 EJB 3 em Ação

fora do ambiente Java em um cronograma competitivo. Terceira, os fornecedores concorrem

entre si para fornecer recursos não padronizados adicionados ao valor. Todos esses fatores
ajudam a manter o EJB continuamente na linha de evolução.

Base de código de alta qualidade e estável

Embora o EJB 3 seja um passo a frente, muitas implementações de servidor de aplicação ainda
se beneficiarão a partir de uma base de código relativamente estável, que residiu em muitos
ambientes empresariais por um longo período de tempo. Muitas soluções para fornecedores de
persistência como JDO, Hibernate e TopLink também são produtos estáveis que estão sendo usados
em muitos ambientes de produção de missão crítica. Isto significa que, embora o EJB 3 seja
novo, você pode esperar por implementações estáveis muito mais rápidas. Por causa de seu
ambiente baseado em padrões, a qualidade das implementações do container EJB 3 não passa
despercebida pelos fornecedores. Em algum estágio, ajuda a garantir um nível saudável da
qualidade de implementação própria.

Agrupamento, balanceamento de carga e failover

Os recursos historicamente adicionados por muitos fornecedores de servidores de aplicações

são suportes robustos para o agrupamento, balanço de carga e failover. Os servidores de aplicação
EJB possuem um registro de trilha provado para suportar alguns dos ambientes de servidores
ativados por computação (HPC) de alto desempenho. Mais importante que isso, você pode
alavancar tal suporte sem alterar o código, sem interação de ferramenta terceirizada e com
configuração relativamente simples (além do trabalho inerente em configurar um agrupamento
de hardware). Isto significa que você pode confiar no agrupamento de hardware para medir sua
aplicação com o EJB 3, caso precise.

O EJB é uma opção atrativa para a construção de aplicações empresarias. Nas seções seguintes,
explicaremos mais sobre os tipos de EJB e como utilizá-los. Também discutiremos sobre containers
e fornecedores de persistência e exploraremos os serviços que eles fornecem. Ao terminar de ler
as seções 1.2 e 1.3, você terá uma boa idéia sobre o que é o EJB, onde funciona e quais serviços
ele oferece. Bom, vamos começar!

1.2 Entendendo os tipos EJB

Se você é como muitos desenvolvedores, você sempre terá um prazo apertado para atender.
Muitos de nós tentamos pedir, emprestar ou roubar códigos reutilizáveis para tornar nossa vida
mais fácil. Foram-se os dias em que os desenvolvedores tinham o luxo de criar sua própria infra-
estrutura ao construir uma aplicação comercial. Enquanto muitos frameworks de fonte aberta e
comerciais disponíveis podem simplificar o desenvolvimento da aplicação, o EJB é um framework
atrativo que tem muito a oferecer.

Esperamos que, por ora, você esteja entusiasmado com o EJB e queira aprender mais sobre ele.
Vamos ver como utilizar o EJB como um framework para construir sua lógica de negócios e
camadas de persistência de suas aplicações, começando com os beans.

Na linguagem EJB, um componente é um “bean”. Se seu gerente não encontrar trocadilhos

para “coffee bean”, culpe o departamento de marketing da Sun. Hey, de qualquer forma vamos
ouvir as pessoas usarem bastante as palavras “empresa” e “bean” como se isso fosse perfeitamente
normal…
 CAPÍTULO 1 13
O que é o que é no EJB 3

Como mencionamos anteriormente, o EJB classifica os beans em três tipos, baseados em sua
utilidade:

! Beans de sessão

! Beans dirigidos por mensagens

! Entidades

Cada tipo de bean tem um propósito e pode utilizar um subconjunto específico de serviços EJB.
O propósito real dos tipos de beans é proteger contra a sobre carga com seus serviços que
surgem. É como garantir que uma pessoa com óculos de armação de plástico não terá curiosidade
em saber o que acontece quando tocar ambos os lados de uma bateria de carro ao mesmo tempo.
A classificação do bean também ajuda você a entender e organizar uma aplicação de uma maneira
sensata; por exemplo, os tipos de beans ajudam você a desenvolver aplicações baseadas em uma
arquitetura multi-camada.

Como mencionamos rapidamente, os beans de sessão e os beans dirigidos por mensagens (MDBs)
são usados para construir lógica de negócios e residem em um container, que gerencia esses
beans e fornece serviço a eles. As entidades são usadas para modelar a persistência de uma
aplicação. Como o container, é um fornecedor de persistência que gerencia as entidades. Um
fornecedor de persistência é plugável dentro do container e extraído no Java Persistence API
(JPA). Essa organização de API do EJB 3 é mostrada na figura 1.6.

Discutiremos sobre o container e o fornecedor de persistência na seção 1.3. Por ora, tudo o que
você precisa saber é que esses são elementos separados da implementação do EJB e cada qual
fornece suporte para diferentes tipos de componentes EJB.

Vamos nos aprofundar em vários tipos de componentes EJB, começando com os beans de sessão.

Figura 1.6 Organização geral do API do EJB 3. A API de persistência Java é completamente
separável do container EJB 3. O processamento de lógica de negócios é executado por meio
de dois tipos de componentes: beans de sessão e beans dirigidos por mensagem. Ambos são
gerenciados pelo container.

Os objetos de persistência são chamados de entidades, que são gerenciados pelo fornecedor
persistente por meio da interface EntityManager.

1.2.1 Beans de sessão

Um bean de sessão é executado por um cliente com o propósito de realizar uma operação de
negócios específica, como a verificação de um histórico de crédito para um cliente. O nome
‘sessão’significa que uma instância de bean está disponível para a duração de uma “unidade de
trabalho” e não sobrevive a uma queda do servidor ou parada temporária. Um bean de sessão
14 EJB 3 em Ação

pode modelar qualquer funcionalidade lógica de aplicação. Há dois tipos de beans de sessão: com
estado e sem estado.

Um bean de sessão com estado salva automaticamente um bean de estado entre as invocações do
cliente sem ter que escrever qualquer código adicional. Um exemplo típico de um processo de
informação de estado é o carrinho de compras de um comércio na web como o da Amazon. Em
contraste a isso, os beans de sessão sem estado não mantêm quaisquer serviços de aplicação de
modelo e estado que podem ser completados em uma única invocação do cliente. Você poderia
construir beans de sessão sem estado para implementar os processos empresariais como a carga
de um cartão de crédito ou a verificação de um histórico de crédito do cliente.

Um bean de sessão pode ser executado tanto local quanto remotamente usando o Java RMI. Um
bean de sessão sem estado pode ser exibido como um serviço de web.

1.2.2 Beans dirigidos por mensagens

Como os beans de sessão, os MDBs processam lógica empresarial. No entanto, são diferentes em
um ponto importante: os clientes nunca executam métodos MDBs diretamente. Ao invés disso,
os MDBs são lançados por meio de mensagens enviadas ao servidor de mensagens, que permite
o envio de mensagens assíncronas entre os componentes do sistema. Alguns exemplos típicos de
servidores de mensagens são IBM WebSphere MQ, SonicMQ, Oracle Advanced Queueing e TIBCO.
Os MDBs são tipicamente usados para integração de sistema robusto ou processamento assíncrono.
Um exemplo de mensagens é o envio de um pedido de reabastecimento de estoque a partir de
um sistema de varejo automatizado para fornecer um sistema de gerenciamento em cadeia.

Não se preocupe muito com as mensagens agora; daremos mais detalhes sobre esse assunto mais
adiante neste livro.

Depois, explicaremos o conceito de persistência e descreveremos como os frameworks de objetos

relacionais ajudam a ativar a persistência automatizada.

1.2.3 Entidades e Java Persistence API

Um dos recursos mais atraentes do EJB 3 é o modo com que ele controla a persistência. Já
mencionamos anteriormente sobre os fornecedores de persistência e o JPA, mas agora entraremos
em detalhes.

Persistência é a habilidade de ter os dados contidos nos objetos Java automaticamente armazenados
em um banco de dados relacional como o Oracle, SQL Server e DB2. A persistência em EJB 3 é
gerenciada pelo JPA. Ela persiste automaticamente aos objetos Java usando uma técnica chamada
mapeamento objeto-relacional (ORM). O ORM é essencialmente o processo de mapeamento de
dados contidos nos objetos Java das tabelas de banco de dados usando configuração. Ele desobriga
você da tarefa de escrever o código JDBC de baixo nível, chato e complexo, para manter os
objetos em um banco de dados.

Os frameworks que fornecem capacidade ORM para realizar persistência automatizada são
conhecidos como frameworks ORM. Como o nome já diz, um framework ORM executa persistência
transparente usando metadados do mapeamento objeto-relacional que define como os objetos
são mapeados nas tabelas de banco de dados. ORM não é um novo conceito e já está presente por
algum tempo. Oracle TopLink é provavelmente o framework ORM mais antigo no mercado; o
framework de fonte aberta JBoss Hibernate popularizou os conceitos ORM entre a comunidade do
desenvolvedor atual.
 CAPÍTULO 1 15
O que é o que é no EJB 3

Nos termos do EJB 3, um fornecedor de persistência é essencialmente um framework ORM que

suporta o EJB 3 Java Persistence API (JPA). O JPA define um padrão para

! A criação de metadados de configuração ORM para mapeamento de entidades às

tabelas relacionais.

! O API EntityManager —um padrão API para realização CRUD (create, read, update, e
delete) (criar, ler, atualizar e deletar)/operações de persistência para entidades.

! O Java Persistence Query Language (JPQL), para pesquisa e recuperação de dados de

aplicação persistentes.

Desde que JPA padronizou os frameworks ORM para a plataforma Java, você pode conectar
produtos ORM como JBoss Hibernate, Oracle TopLink ou BEA Kodo conforme o “provedor de
persistência” do JPA em sua aplicação.

Você pode pensar que a persistência automatizada é algo que você achará útil para todos os tipos
de aplicação, não apenas para as aplicações server-side como àquelas construídas com o EJB.
Afinal, o JDBC, o avô do JPA, é usado em tudo, desde sistemas em tempo real de larga escala até
protótipos . Este é o motivo pelo qual o JPA é completamente separado do resto do EJB 3 e
usado em ambientes Java SE.

Entidades são beans de sessão e são equivalentes no mundo JPA. Vamos dar uma breve
olhada nelas logo mais, assim como veremos também a API EntityManager e Java Persistence
Query Language (JPQL).

Entidades

Se você estiver usando JPA para construir lógica de persistência em suas aplicações, você deve
usar as entidades. Entidades são objetos Java que permanecem no banco de dados. Exatamente
como os modelos de beans de sessão, que manipulam os processos corporativos de alto nível.
Enquanto os beans são “verbos” de um sistema, entidades são os “substantivos”. Por exemplo,
uma entidade Employee, uma entidade User, uma entidade Item e assim por diante. Eis aqui
outra definição perfeitamente válida (e simples de ser entendida) sobre as entidades: elas são
representações OO dos dados da aplicação armazenadas no banco de dados. Neste sentido, as
entidades sobrevivem às quedas do container e paradas temporárias. Você deve saber como o
fornecedor de persistência sabe onde a entidade será armazenada. A mágica real existe nos
metadados ORM; uma entidade contém dados que especificam como ela mapeou o banco de
dados. Você verá um exemplo disto no próximo capítulo. As entidades JPA suportam um
amplo conjunto de capacidades relacionais e OO, inclindo as relações entre as entidades,
herança e polimorfismo.

EntityManager

A interface JPA EntityManager gerencia as entidades para fornecer serviços de persistência.

Enquanto as entidades informam ao provedor JPA como elas mapeiam o banco de dados, elas
não permanecem em si mesmas. A interface EntityManager lê o metadado ORM para uma entidade
e realiza operações de persistência. A EntityManager sabe como adicionar entidades ao banco de
dados, atualizar entidades armazenadas e apagar e recuperar entidades do banco de dados.
Além disso, o JPA fornece habilidade de manusear o gerenciamento do ciclo de vida, o
desempenho do ajuste, caching e gerenciamento de transação.
16 EJB 3 em Ação

Java Persistence Query Language

JPA fornece uma linguagem de consulta, como a SQL, chamada Java Persistence Query Language
(JPQL) para buscar entidades salvas no banco de dados. Com uma API robusta e flexível, como
JPQL, você não perderá nada ao escolher a persistência automatizada ao invés de escrever o
JDBC à mão. Além disso, JPA suporta SQL específica de banco de dados, nativa, nos casos raros
onde vale a pena usá-la.

A esta altura, você já deve ter uma visão apropriada de alto nível das várias partes do EJB. Você
também deve saber que precisa de um container EJB para executar beans de sessão e MDBs,
assim como precisa de um fornecedor de persistência para executar suas entidades, para que
esses componentes possam acessar os serviços fornecidos pelo EJB 3. O container, o fornecedor
de persistência e os serviços são os conceitos mais importantes no EJB 3 e falaremos sobre eles
daqui a pouco.

1.3 Conhecendo o EJB

Ao construir uma simples classe Java, você precisa de um Java Virtual Machine (JVM) para
executá-la. De forma parecida, (como você aprendeu na seção anterior) para executar beans de
sessão e MDBs é necessário um container EJB e, para executar suas entidades, você precisa de
um fornecedor de persistência. Nesta seção, daremos uma visão panorâmica dos containers e
fornecedores de persistência e explicaremos como eles se relacionam.

No mundo Java, os containers não são apenas limitados ao reino do EJB 3. Você provavelmente
já conhece o container da web que permite que você execute aplicações baseadas em web usando
as tecnologias Java, como servlets, JSP ou JSF. Um container Java EE é uma solução de servidor
de aplicação que suporta EJB 3, um container de web e outras APIs de Java EE e serviços. BEA
WebLogic Server, GlassFish da Sun Microsystems, IBM WebSphere, JBoss Application Server e Oracle
Application Server 10g são exemplos de containers Java EE. A relação entre container Java EE,
container de web, container EJB e fornecedor de persistência JPA é mostrada na figura 1.7.

Se você instalar um servidor de aplicação associado ao Java EE, como GlassFish, ele irá conter um
container de web, um container EJB e um fornecedor JPA pré-configurados. No entanto, alguns
fornecedores e projetos abertos podem fornecer apenas um container de web, como o Tomcat,
ou fornecedor de persistência associado ao EJB 3, como o Hibernate.

Esses containers fornecem funcionalidades limitadas comparadas às que você possui com um
container Java EE 5 completo.

Nesta seção, iremos destacar como o container EJB e o fornecedor de persistência funcionam e
finalizaremos com uma discussão completa sobre os serviços do EJB. Primeiro, vamos ver o
container EJB.

1.3.1 Acessando os serviços EJB: container EJB

Pense no container como uma simples extensão da idéia básica de um JVM. Exatamente como o
JVM gerencia com transparência a memória em seu favor, o container fornece serviços para o
componente EJB, como transações, gerenciamento de segurança, remoting e suporte aos serviços
de web. De fato, você deve pensar no container como um JVM mais forte, cuja proposta é executar
EJBs. No EJB 3, o container fornece serviços aplicáveis apenas aos beans de sessão e MDBs. A
tarefa de colocar um componente EJB 3 dentro de um container é chamada de distribuição. Uma
 CAPÍTULO 1 17
O que é o que é no EJB 3

vez que um EJB é distribuído com êxito em um container, ele pode ser usado em suas aplicações.

O fornecedor de persistência é uma cópia do container no JPA. Falaremos brevemente sobre

isso mais adiante.

Figura 1.7 O container Java EE contém basicamente containers de web e EJB e um fornecedor
de persistência. Os beans de sessão sem estado (Credit Check EJB) e os beans de sessão com
estado (Cart EJB) são distribuídos e inseridos no container EJB. As entidades (Cliente e
Catálogo) são distribuídas e inseridas em um fornecedor de persistência e podem ser acessadas
tanto pelos conponentes do container de web quanto pelo EJB.

1.3.2 Acessando os serviços JPA: Fornecedor de persistência

Na seção 1.2.3, mencionamos que a tarefa do fornecedor de persistência é fornecer serviços JPA
padronizados. Vamos verificar como ele faz isso. Ao invés de seguir o modelo de container,
como o JVM, o JPA segue um modelo similar às APIs, como o JDBC. O JPA fornece serviços de
persistência, como recuperação, adição, modificação e apagamento das entidades JPA quando
você pergunta por elas, chamando pelos métodos de API EntityManager.

O termo “fornecedor” vem de APIs, assim como os termos JDBC e JNDI. Se você trabalhou com
JDBC, sabe que um “fornecedor” é essencialmente o fornecedor da implementação que a API
JDBC usa às escondidas. Os produtos que fornecem implementação JPA são os fornecedores de
persistência ou mecanismos de persistência. JBoss Hibernate e Oracle TopLink são dois
fornecedores JPA populares.

Como o JPA é completamente plugável e separável, o fornecedor de persistência e o container

em uma solução EJB 3 não precisam vir do mesmo fornecedor. Por exemplo, você pode usar o
Hibernate dentro de um container WebLogic BEA se achar melhor, ao invés da implementação
Kodo que vem com o Weblogic.

Mas, sem os serviços, o quão bom são os containers? Na próxima seção, iremos explorar os
conceitos de serviços criticos do EJB.

1.3.3 Obtendo funcionalidade com os serviços EJB

A primeira coisa que devemos ter em mente enquanto avaliamos qualquer tecnologia é o que ela
nos fornece. O que há de tão especial no EJB? Além de uma tecnologia de apresentação multi-
camada, como JSP, JSF ou Struts, você não pode criar sua aplicação de web usando apenas a
linguagem Java e talvez algumas APIs, como JDBC, para acesso ao banco de dados? A resposta
mais comum é que você poderia, caso os prazos e a competição implacável não existissem.
Realmente, ninguém antes imaginava que o EJB era exatamente o que diziam sobre ele.
18 EJB 3 em Ação

O que o resultado de longas horas provou é que você tende a perder mais tempo solucionando
problemas corriqueiros e comuns ao invés de se concentrar em soluções corporativas reais.
Essas experiências amargas enfatizam que há soluções comuns que podem ser reutilizadas para
solucionar problemas de desenvolvimento comuns. Isto é exatamente o que o EJB propõe.

O EJB é uma coleção de soluções “compactadas” para os problemas de desenvolvimento de

aplicação do servidor como também um mapeamento dos padrões de componentes comuns do
servidor. Essas soluções “compactadas” ou serviços são fornecidos tanto pelo container EJB
quanto pelo fornecedor de persistência. Para acessar esses serviços, você constrói os componentes
da aplicação e os distribui no container. Neste livro, falaremos muito sobre como você pode
explorar os serviços EJB.

Nesta seção, apresentaremos brevemente alguns dos serviços que o EJB oferece. Obviamente
que nós não poderemos explicar os detalhes de implementação de cada serviço nesta seção. Nem
será necessário incluir cada serviço que o EJB oferece neste momento. Ao invés disso, listaremos
brevemente os principais serviços do EJB 3 na tabela 1.1 e explicaremos seus significados a
partir de uma perspectiva prática. Este livro mostra como usar cada um dos serviços apresentados
na tabela 1.1 em sua aplicação.

Apesar dos recursos robustos do EJB 2, uma das reclamações mais comuns entre as pessoas que
o utilizaram é a de que ele era muito complexo. Estava claro que o EJB 3 teria que executar o
desenvolvimento da maneira mais simples possível, ao invés de simplesmente adicionar recursos
ou serviços. Se você trabalhou com o EJB 2, leu alguma coisa sobre sua complexidade ou
simplesmente ouviu falar, deve estar curioso para ver o que há de diferente no EJB 3. Vamos
olhar mais de perto.

Tabela 1.1 Principais serviços dos componentes EJB 3 e porque eles são importantes para
você. Os serviços de persistência são fornecidos pelo fornecedor JPA.
Ser vi Áos Apl i caÁı es O que si gni f i cam

I n t egr ação Bean s d e sessão e M DBs Aju d a a u n ir os com p on en t es p or m eio d e

u m a con f igu r ação sim p les, ao in vés d e
cód igos. N o EJB 3, isso é f eit o p or m eio d a
in jeção d e in d ep en d ên cia (DI ) assim com o o
l ook u p .

Poolin g Bean s d e sessão sem est ad o Par a cad a com p on en t e EJB, a p lat af or m a
e M D Bs EJB cr ia u m p ool d e in st ân cias d o
com p on en t e, qu e são com p ar t ilh ad os p elos
clien t es. Cad a in st ân cia p ooled p od e ser
u sad a som en t e p or u m clien t e. À m ed id a
qu e u m a in st ân cia é f in alizad a p or u m
clien t e, r et or n a ao p ool p ar a r eu t ilização,
ao in vés d e ser d escar t ad a n o lix o p ar a
r eciclagem .

T h r ead - Saf et y Bean s d e sessão e M DBs O EJB ex ecu t a t od os os com p on en t es com

segu r an ça em cad eia d e f or m a
com p let am en t e in visível. I sso sign if ica qu e
você p od e escr ever os com p on en t es d o seu
ser vid or com o se f osse d esen volver u m a
ap licação d e d esk t op com lin h a d e
ex ecu ção ú n ica. N ão im p or t a o qu ão
com p lex o seja o com p on en t e, o EJB
gar an t ir á su a segu r an ça em cad eia.
 CAPÍTULO 1 19
O que é o que é no EJB 3

Tabela 1.1 Principais serviços dos componentes EJB 3 e porque eles são importantes para
você. Os serviços de persistência são fornecidos pelo fornecedor JPA. (Continuação)

Ser vi Áos Apl i caÁı es O que si gni f i cam

Ger en ciam en t o d e Est ad o
Bean s d e sessão com est ad o
O con t ain er EJB ger en cia o est ad o d os
com p on en t es com est ad o, ao in vés d e
escr ever cód igos su scet íveis a er r o p ar a o
ger en ciam en t o d o est ad o. I sso sign if ica qu e
você p od e m an t er o est ad o em in st ân cias
var iáveis com o se f osse d esen volver u m a
ap licação p ar a d esk t op . O EJB cu id a d e
t od os os d et alh es d a m an u t en ção d a sessão
at r ás d os bast id or es.

M essagin g M DBs. O EJB 3 p er m it e qu e você escr eva

om p on en t es d e m en sagem sem t er qu e
lid ar com m u it os d et alh es m ecân icos d a API
d o JavaM essagin g Ser vice (JM S).

Tr an sações Bean s d e sessão e M DBs O EJB su p or t a o ger en ciam en t o d e

t r an sação d eclar at iva, qu e aju d a você a
ad icion ar com p or t am en t o t r an sacion al aos
com p on en t es u san d o u m a con f igu r ação
sim p les, ao in vés d e cód igo. De f at o, você
p od e d esign ar qu alqu er m ét od o d e
com p on en t e p ar a ser t r an sacion al. Se o
m ét od o se com p let a n or m alm en t e, o EJB
en cer r a a t r an sação e f az as alt er ações d os
d ad os p or m eio d o m ét od o p er m an en t e.
Caso con t r ár io, a t r an sação é r et r oced id a.

Segu r an ça Bean s d e sessão O EJB su p or t a a in t egr ação com o Java

Au t h en t icat ion e Au t h or izat ion Ser vice
(JAAS) API p ar a qu e seja m ais f ácil
ex t er n alizar com p let am en t e a segu r an ça e
gar an t ir qu e u m a ap licação u se con f igu r ação
sim p les, ao in vés d e at r avan car su a ap licação
com cód igo d e segu r an ça.

I n t er cep t or es Bean s d e sessão e M DBs O EJB 3 ap r esen t a AO P d e f or m a leve e

acessível u san d o in t er cep t or es. I sso p er m it e
qu e você sep ar e f acilm en t e as p r op r ied ad e
t r an sver sais, com o loggin g e au d it in g e
con t in u ar d e u m a m an eir a con f igu r ável.

Acesso r em ot o Bean s d e sessão N o EJB 3, você p od e ex ecu t ar com p on en t es

acessíveis r em ot am en t e sem escr ever
qu alqu er cód igo. Além d isso, o EJB 3
p er m it e qu e o cód igo d o clien t e acesse
com p on en t es r em ot os com o se f ossem
com p on en t es locais, u san d o DI .

Ser viços d e web Bean s d e sessão sem est ad o O EJB 3 p od e t or n ar os com p on en t es

em p r esar iais em ser viços d e web r obu st os
com m ín im as alt er ações n o cód igo.

Per sist ên cia En t id ad es For n ecer p er sist ên cia au t om at izad a 100%

con f igu r ável, basead a em p ad r ões com o
u m a alt er n at iva p ar a evit ar er r os d o cód igo
JDBC/SQ L é o p r in cip al objet ivo d a
p lat af or m a EJB 3.
20 EJB 3 em Ação

Tabela 1.1 Principais serviços dos componentes EJB 3 e porque eles são importantes para
você. Os serviços de persistência são fornecidos pelo fornecedor JPA. (Continuação)

Ser vi Áos Apl i caÁı es O que si gni f i cam

Cach in g e Desem p en h o En t id ad es Além d a p er sist ên cia au t om at izad a, a JPA

f or n ece u m n ú m er o d e ser viços qu e gir am
em t or n o d o cach in g, d a ot im ização d o
d esem p en h o e d o aju st e d a ap licação. Esses
ser viços são in est im áveis n o su p or t e d e
sist em as d e m éd ia e lar ga escala.

1.4 O Renascimento do EJB

Software é orgânico. Como as formas de vida baseadas em carbono, o software cresce e evolui. Os
recursos padecem. Novos recursos nascem. Os números soltos continuam crescendo como os
galhos de uma árvore saudável. O EJB não é uma exceção à regra da evolução do software.

Na verdade, conforme a tecnologia avança, a saga do EJB é mais do que alterar, é estagnar.
Apenas um bocado de outras tecnologias pode ostentar a metamorfose robusta e as melhoras
contínuas que o EJB possui.

É hora de percebermos as novas encarnações do EJB, começando com o exemplo de um bean de

sessão sem estado simples e, em seguida, revelando as alterações dos recursos que tornam o EJB
uma ferramenta de desenvovimento fácil de ser usada.

Para explorar os novos recursos do EJB 3, apontamos alguns problemas associados ao EJB 2. Se
você não estiver familiarizado com o EJB 2, não se preocupe – o mais importante é lembrar-se
como os problemas foram solucionados no EJB 3.

Os problemas associados ao EJB 2 foram muito discutidos. Na verdade, há muitos livros, como
o Bitter EJB (Manning Publications, 2003), escritos sobre este tópico. Chris Richardson em
POJOs em Ação identificou legalmente a quantidade de códigos transparentes que você possui
para escrever um EJB:

Você deve escrever muitos códigos para implementar um EJB – Você deve escrever uma
interface home, uma interface de componente, classe de bean e um descritor de distribuição,
o que para um bean de entidade pode ser muito complexo. Além disso, você deve escrever
um número de métodos de classe de bean padronizados que nunca são chamados, mas
que são necessários pelos implementos de classe de bean da interface. Esse código não é
conceitualmente difícil, mas é um trabalho árduo que você precisa tolerar.

Nesta seção, gostaríamos de passar por esses pontos e apresentar como eles foram solucionados
no EJB 3. Como você verá, o EJB 3 identifica as questões mais problemáticas no EJB 2 e as
soluciona por meio do reconhecimento do negrito e da adaptação inteligente das técnicas
amplamente disponíveis na soluções abertas como Hibernate e Spring. Ambos passaram no “teste
de incubação de mercado” sem serem muito destruídos. Essa versão prepara o EJB de várias
maneiras para as inovações, solucionando os problemas mais imediatos e criando uma zona de
buffer para a próxima transformação.

Mas, antes, vamos dar uma olhada em código. Provavelmente, você nunca usa o EJB 2 para
construir aplicações simples como Hello Word. No entanto, queremos mostrar a você uma
implementação simples do EJB que o onipresente Hello World desenvolveu usando o EJB 3.
 CAPÍTULO 1 21
O que é o que é no EJB 3

Queremos que você veja este código por dois motivos: primeiro, para demonstrar o quão simples
é desenvolver com o EJB 3 e, segundo, porque isso provavelmente será o contexto das discussões
nas próximas seções e precisam estar claros.

1.4.1 Exemplo de HelloUser

Os exemplos de Hello Word regeram o mundo desde sua primeira aparição em A Linguagem de
Programação C, de Brian Kernighan e Dennis Ritchie (Prentice Hall PTR, 1998). Hello Word
tornou-se popular e complicado por boas razões. É muito adequado apresentar uma tecnologia
o mais simples e clara possível. Enquanto os livros de tecnologia começam com um exemplo de
Hello Word, decidimos mudar essa regra e fornecer exemplos diferentes para manter as coisas
relevantes e intensas.

Em 2004, um dos autores, Debu, escreveu um artigo para o TheServerSide.com no qual declarou,
quando o EJB foi lançado, que ele seria tão simples que você poderia escrever um Hello Word
usando apenas poucas linhas do código. Qualquer desenvolvedor EJB 2 experiente sabe que
isso não poderia ser feito de maneira tão fácil. Você teria que escrever uma interface de home,
uma interface de componente, uma classe de bean e um descritor de distribuição. Bem, agora
que o EJB 3 foi finalizado, vamos ver se Debu estava certo em sua previsão (listagem 1.1).

Listagem 1.1 HelloUser sessão bean

package ejb3inaction.example;
public interface HelloUser {
public void sayHello(String name);
}

package ejb3inaction.example;
import javax.ejb.Stateless;
@Stateless
public class HelloUserBean implements HelloUser {
public void sayHello(String name) {
System.out.println(“Hello “ + name + “ welcome to EJB 3!”);
}
}

A listagem 1.1 é certamente um exemplo completo e reservado do funcionamento do EJB!

Observe que, para simplificar, mantemos ambas as interfaces e classes como parte da mesma
listagem. Como você pode ver, o EJB não parece muito mais complexo do que seu primeiro
programa Java. A interface é Java plana (POJI) e a classe de bean é objeto Java plano (POJO)
. O divertido símbolo @stateless na listagem 1.1 é uma anotação de metadado que converte
o POJO em um EJB poderoso sem estado. Se você não está familiarizado com as anotações de
metadados, iremos explorá-las no capítulo 2. De fato, são informações de configuração
“comentadas” que podem ser adicionadas ao código Java.

Para executar este EJB, você deve distribuí-lo no container EJB. Se você quer executar essa amostra,
faça o download dos arquivos compactados contendo os exemplos dos códigos no site www.
manning.com/panda e siga as instruções online para distribuir e executar seu container EJB favorito.

No entanto, não se preocupe muito com os detalhes deste código agora; são apenas uma simples
ilustração. Navegaremos pelos detalhes do código no próximo capítulo. Nossa intenção com o
exemplo Hello World é usá-lo como base para discutir como o EJB 3 trata as questões mais
aflitivas que marcaram o EJB 2 como enfadonho.

Agora, vamos conhecer o que transformou o elefante EJB na vaca EJB.

22 EJB 3 em Ação

1.4.2 Modelo de programação simplificado

Concordamos veementemente com a citação de Chris Richardson: um dos maiores problemas
com o EJB 2 foi a quantidade de códigos transparentes que você precisava para escrever uma
implementação EJB.

Se tentássemos produzir a listagem 1.1 como um exemplo EJB 2, teríamos que trabalhar com
várias classes e interfaces apenas para produzir uma simples linha. Todas essas classes e interfaces
tiveram as interfaces API do EJB implementadas ou ampliadas com restrições rígidas e tolas
como lançar java.rmi.RemoteException para todos os métodos. As interfaces implementadas como
javax.ejb.SessionBean para a classe de implementação do bean foram particularmente consumidas,
desde que você forneça uma implementação para o novo ciclo de vida dos métodos, como
ejbCreate, ejbRemove, ejbActivate, ejbPassivate, e setSession-Context, quer use-os quer não. De fato,
você foi forçado a lidar com vários passos mecânicos para realizar muito pouco. Ferramentas
IDE, como JBuilder, JDeveloper e WebSphere Studio dificultaram um pouco com a automatização
de alguns desses passos. No entanto, no geral, ferramentas apropriadas com suporte robusto
eram extremamente caras e incompetentes.

Conforme visto na listagem 1.1, o EJB 3 permite que você dsenvolva um componente EJB
usando POJOs e POJIs que não sabem nada sobre serviços de plataforma. Você pode, então,
aplicar metadados de configuração usando anotações a esses POJOs e POJIs para adicionar
serviços de plataforma como a remotabilidade, suporte aos serviços de web e ciclo de vida das
chamadas de retorno apenas quando necessário.

O passo redundante para criar interfaces de home foi feito por completo. Em resumo, as definições
dos serviços EJB moveram-se do mundo seguro das interfaces para configurações distribuídas e
executadas onde melhor se adequavam. Um número de passos mecânicos foi utilizado pela
plataforma por si só. Em outras palavras, você não precisa escrever vários códigos para
implementar um EJB!

1.4.3 Anotações ao invés de descritores de distribuição

Além de escrever vários códigos padronizados, uma dificuldade significante no gerenciamento
do EJB 2 era o excesso de configuração XML para cada componente que você ainda tinha que
fazer. Embora o XML seja um grande mecanismo, a verdade é que nem todos são fãs de sua
eloqüencia, legibilidade e fragilidade.

Antes da chegada das anotações de metadados do Java 5, não tínhamos outra escolha que não
fosse usar o XML para configuração. O EJB 3 permite que usemos as anotações de metadados
para configurar um componente ao invés de usar descritores de distribuição XML. Como você
pode adivinhar a partir da listagem 1.1, além de eliminar a eloqüencia, as anotações ajudam a
evitar a natureza monolítica dos arquivos de configuração XML e localizam a configuração do
código que foi afetada por ele. Observe que você ainda pode usar os descritores de distribuição,
caso sejam mais adequados ou apenas para complementar as anotações. Falaremos mais sobre
isso no capítulo 2.

Além de tornar a tarefa de configuração mais fácil, o EJB 3 reduz a quantidade total de
configuração do conjunto, usando padrões sensíveis onde for possível.

Isso é especialmente importante quando você lidar com persistência automatizada usando ORM,
conforme veremos nos capítulos 7, 8, 9 e 10.
 CAPÍTULO 1 23
O que é o que é no EJB 3

1.4.4 Injeção de dependência vs. JNDI

Uma das partes mais entediantes do desenvolvimento do EJB 2 era escrever as mesmas linhas do
código várias vezes para fazer um JNDI lookup quando necessário para acessar um EJB ou uma
fonte gerenciada por container, como o manuseio da conexão do banco de dados pooled. Em
POJOs em Ação, Chris Richardson enfatiza bem:

Uma aplicação J2EE tradicional usa a JNDI como mecanismo, no qual um componente
usa para acessar outro. Por exemplo, a camada de apresentação usa uma JNDI lookup
para obter uma referência a uma interface home de bean de sessão. De forma semelhante,
um EJB usa a JNDI par acessar os recursos que ela necessita, como um JDBC DataSource.
O problema com a JNDI é que ela une o código de aplicação ao servidor de aplicação,
tornando o desenvolvimento e o teste mais difíceis.

No EJB 3, a JNDI lookup foi transformada em configuração simples usando a injeção de

dependência baseada em metadados (DI). Por exemplo, se você quiser acessar o EJB HelloUser,
que vimos na listagem 1.1, a partir de outro EJB ou servlet, você poderia usar um código
como este.
...
@EJB
private HelloUser helloUser;

void hello(){
helloUser.sayHello(“Curious George”);
}
...

Não é o máximo? A anotação @EJB “injeta” com transparência o EJB HelloUser na variável
anotada. A injeção de dependência EJB 3 fornece a você essencialmente uma abstração simples
árvore JNDI das empresas de ampla escala. Observe que você pode ainda usar JNDI lookups
onde eles são inevitáveis.

1.4.5 Persistência API simplificada

Muitos problemas com o modelo de persistência EJB 2 aconteceram devido à aplicação do
paradigma do container em um problema prejudicial. Isso tornou o modelo de programação
de bean de entidade do EJB 2 extremamene complexo e não intuitivo.

Permitir o acesso remoto foi uma das motivações primordiais dos beans de entidade gerenciados
por container. Na verdade, poucos clientes usaram esse recurso por causa das questões de
desempenho, optando por usar os beans de sessão como ponto de acesso remoto.

Sem sombra de dúvidas, os beans de entidade foram a pior parte do EJB 2. O EJB 3 soluciona
o problema usando um paradigma API mais natural centralizado na manipulação de POJOs
baseados em metadados por meio da interface EntityManager. Além do mais, as entidades do
EJB 3 não carregam a obrigação desnecessária do acesso remoto.

Outra limitação do EJB 2 era a impossibilidade de enviar um bean de entidade EJB 2 com fio em
diferentes camadas. Os desenvolvedores do EJB descobriram um antídoto para este problema:
adicionar outra camada de objetos – os objetos de transferência de dados (DTOs).

Chris recapitula:
24 EJB 3 em Ação

Você precisa escrever objetos de transferência de dados – um objeto de transferência de dados

(DTO) é um objeto de dados mudo que retornou pelo EJB ao seu chamado e contém
dados da camada de apresentação que aparecerão ao usuário. É apenas uma cópia dos
dados a partir de um ou mais beans de entidade, que não podem ser passados para a
camada de apresentação, pois estão permanentemente anexados ao banco de dados.
Implementar os DTOs e o código que os cria é um dos aspectos mais entediantes da
implementação EJB.

Como eles são POJOs, as entidades podem ser transferidas entre diferentes camadas sem ter que
recorrer aos anti-padrões como objetos de transferência de dados.

A simplificação da persistência API leva a outros benefícios, como a personalização dos frameworks
de persistência, uma API de persistência separável que pode ser usada fora do container EJB e
suporta melhor os recursos orientados a objetos,como a herança e o polimorfismo. Veremos a
persistência EJB 3 em ação no capítulo 2, mas, agora, vamos dar uma olhada em alguns dos
principais recursos da persistência API.

Persistência padronizada

Um dos maiores problemas com os beans de entidade do EJB 2 era a falta de padronização
do ORM.

Os beans de entidade do EJB 2 deixaram os detalhes da configuração de mapeamento do banco

de dados para o fornecedor. Isso resultou nos beans de entidade que não eram portáteis nas
implementações do container. O mecanismo de consulta do EJB 2, EJB-QL, tinha um sentimento
incompleto por ele. Essas lacunas de padronização aumentaram muito os paradigmas ORM
alternativos, como Hibernate, Oracle, TopLinl e JDO.

O principal objetivo do JPA é compactar as lacunas de padronização deixadas pelo EJB 2. O

EJB 3 solidifica a persistência automatizada com JPA em três maneiras distintas. A primeira
fornece uma configuração ORM robusta capaz de manusear muitas complexidades da persistência
automatizada. A segunda, Java Persistence Query Language (JPQL), melhora de forma significativa
o EJB-QL, padronizando as tecnologias de consulta ORM divergentes. A terceira, a API
EntityManager padroniza as operações ORM CRUD. Mas, a padronização não é o único benefício
da API simplificada: outro grande recurso é sua capacidade de executar fora do container.

A Persistência API Java separada

Como vimos na seção 1.2.3, a persistência API não é apenas uma solução para aplicações server-
side. A persistência é um problema que mesmo uma aplicação de desktop baseado em Swing pode
solucionar. Isso é a realização que guiou a decisão de tornar o JPA uma API separada, capaz de
executar fora de um container EJB 3. Tanto quanto JDBC, JPA pretendia ser uma solução de
persistência para propósitos gerais em qualquer aplicação Java. Isso é um passo positivo na
expansão do escopo do EJB 3 no tradicional domínio externo das aplicações de servidor.

Melhor suporte OO de camada de persistência

Como os beans de entidade do EJB 2 foram registrados, eles não suportariam recursos ricos em
OO como a herança e o polimorfismo e não permitiriam a mixagem de estados de persistência
e lógica de domínio. Como vimos na seção 1.1.3, isso tornou impossível modelar a camada de
domínio na arquitetura DDD.
 CAPÍTULO 1 25
O que é o que é no EJB 3

As entidades EJB 3 possuem suporte OO robusto, não apenas porque são POJOs, mas também
porque o esquema de mapeamento ORM JPA é desevolvido com o OO em mente. JPQL
também possui suporte robusto para OO. Ansioso para aprender mais sobre a JPA? Fique
conosco e verá muitas discussões sobre JPA no decorrer deste livro; a parte 3 é dedicada a
essas discussões sobre JPA.

O desenvolvimento dirigido por teste de tornou bastante popular, pois pode melhorar o
desempenho das aplicações do software. Vamos ver como o EJB 3 melhora a testabilidade
das aplicações.

1.4.6 Componentes POJO de unidades testáveis

Ser capaz de testar a unidade do estado do componente ou lógica é uma técnica crítica para o
aumento da qualidade do código. No EJB 2, apenas o teste funcional dos componentes era
possível, desde que os componentes tivessem que se distribuir no container a ser executado.
Enquanto as interações de usuário para simulação do teste funcional com o sistema é inválida,
não é um bom substituto para o teste de unidade de baixo nível.

Como todos os componentes EJB 3 são POJOs, eles podem facilmente ser executados fora do
container. Isso significa que é possível testar a unidade de todas as lógicas corporativas dos
componentes usando o teste de frameworks como JUnit ou TesteNG.

Essas são apenas alterações primárias ao EJB 3; há muitas outras que você verá no decorrer
desse livro.

Apenas no caso de você pensar que escolheu entre o Spring e o EJB 3, explicamos que não é
necessário observá-los como tecnologias concorrentes.

1.4.7 EJB 3 e Spring

Como mencionamos anteriormente, o EJB 3 e o Spring são vistos como competidores; no entanto,
se você olhar mais de perto, pode perceber que eles também podem se complementar.

O Spring possui particularmente alguns pontos fortes: suporte para inversão de controle (IoC)
para componentes com ciclos de vida simples, como singletons; recursos importantes (no entanto,
mais complexos), suporte de programação orientado ao aspecto (AOP); um número de interfaces
simples, como JDBCTemplate e JMSTemplate, utilizam padrões de uso comuns das APIs Java EE
de baixo nível e assim por diante.

Por outro lado, o EJB 3 fornece melhor suporte para o gerenciamento de estado transparente
com beans de sessão com estado, pooling, segurança em cadeia, suporte robusto a mensagens com
MDBs, suporte integrado para o gerenciamento de transação distribuída, persistência automatizada
padronizada por meio da JPA e assim por diante.

Partindo de um ponto de vista neutro e criterioso, o EJB 3 e o Spring podem ser tecnologias
complementares. A boa notícia é que parte das comunidades do Spring e do Java EE estão
trabalhado assiduamente para tornar a integração Spring/EJB 3 uma realidade.

Realmente é uma boa idéia se você possui um investimento signficativo em Spring mas deseja
utilizar os benefícios do EJB 3. Falaremos mais detalhadamente sobre a integração Spring/EJB 3
no capítulo 16. No entanto, gostaríamos de listar as possibilidades agora.
26 EJB 3 em Ação

Tratando os componentes de camada corporativa EJB 3 como beans de Spring

É possível tratar os componentes de camada corporativa EJB 3 como beans de Spring. Isso
traduz uma arquitetura mostrada na figura 1.8. Nesta arquitetura, o Spring é usado para unir a
aplicação que contém componentes de camada corporativa EJB 3.

O projeto Spring Pitchfork, parte do Spring 2, pretende criar um cenário de integração completamente
transparente. O framework do Spring planeja suportar metadados de anotações EJB 3 especificando
beans de sessão sem estado, interceptores injeção de recurso e assim por diante.

Figura 1.8

Estratégia de integração Spring/

EJB 3. É possível usar os
componentes de camada
corporativa do EJB 3 como se
fossem beans de Spring. Isso
permite que você utilize as
intensidades complementares
de ambas as tecnologias de uma
maneira “híbrida”.

Integrando a JPA com o Spring

Suponha que você ache o Spring conveniente para suas necessidades de camada corporativa e
queira padronizar sua camada de persistência. Neste caso, é fácil integrar a JPA diretamente ao
Spring com a integração Spring/JDO ou Spring/Hibernate.

Esse esquema é mostrado na figura 1.9.

Além de usar o Spring com JPA, você pode encontrar-se em uma situação na qual queira usar
juntos ambos os beans de sessão do Spring e do EJB 3. Vamos examinar as possibilidades
dessa integração.

Figura 1.9

Integração Spring/JPA. Como

a JPA é uma API separável,
você pode integrar Spring
com JPA quando integrar o
Hibernate.

Usando as interfaces Spring dentro dos componentes EJB 3

Outra idéia interessante é usar algumas intefaces do Spring como JDBCTemplate e JMSTemplate
ou mesmo beans de Spring dentro dos componentes do EJB 3. Você pode fazer isso diretamente
ou por meio do acesso ao contexto da aplicação do Spring. Containers como Jboss, Oracle e BEA
 CAPÍTULO 1 27
O que é o que é no EJB 3

estão trabalhando para fornecer suporte sem igual para integrar os beans de Spring aos beans de
sessão e MDBs.

Esse tipo de integração é visualizada na figura 1.10. Discutiremos a combinação do EJB 3 com
o Spring no capitulo 16.

Figura 1.10

Em certos casos, poderia ser

uma boa idéia usar o Spring
a partir do EJB 3. Embora
seja possível fazer isso hoje
em dia, a expectativa é de
que essas possibilidades
sejam ainda melhores no
futuro.

1.5 Resumo
Agora, você tem uma boa idéia sobre o que é o EJB 3, o que ele traz de novidade e porque você
deve pensar em usá-lo para construir aplicações server-side. Demos a você uma visão geral dos
novos recursos contidos no EJB 3, incluindo esses pontos importantes:

! Os componentes do EJB 3 são POJOs configuráveis por meio de anotações de metadados

simplificadas.

! O acesso ao EJB das aplicações dos clientes se tornou muito simples usando a injeção
de dependência.

! O EJB 3 padroniza a persistência com o Java Persistence API, que define as entidades
POJO que podem ser usadas tanto dentro quanto fora do container.

Fornecemos também um código para mostrar como o EJB 3 endereça os pontos de

desenvolvimento que eram inerentes ao EJB 2, e demos uma rápida olhada em como o EJB 3
pode ser usado com Spring.

Com esse conhecimento essencial, você provavelmente esta ansioso para ver mais códigos.
Planejamos satisfazer esse desejo, no mínimo em partes, no próximo capítulo. Esteja pronto
para um grandioso tour por toda a API do EJB 3 que mostra como são os códigos e como são
realmente muito simples.
28 EJB 3 em Ação