O que um EJB?

uma aplicao padro do J2EE, conhecida como Enterprise JavaBeans

(EJBs), que funciona como um container de uma aplicao. Embora seja
possvel usar o Java Standard Object como um container de dados, usar um
EJB permite, de diversas maneiras, padronizar de forma simples objetos
Java, dando-lhes escalabilidade, ciclo-de-vida gerencivel e gerenciamento
de estado.
Beans, Clients, Containers, and Servers
Um EJB essencialmente um componente gerenciado que criado,
controlado e destrudo pelo container gereciador do J2EE que estiver sendo
executado. Esse controle permite ao container controlar o nmero de
objetos EJBs existentes e recuper-los para o uso, como uma memria ou
conexo com o banco de dados.
Cada container mantm um pool de instncias de EJBs que esto prontas
para serem usadas por um client. Quando um client, um browser por
exemplo, requer um determinado recurso ou servio, a instncia de um EJB
selecionado ser liberada.
O cliente EJB que usa a instncia no precisa saber nada sobre como
funciona o mesmo. Funcionando como um componente remoto, provendo
suporte uma determinada regra, ou mtodo nele implementada.
O EJB tem como pontos positivos centralizar servios de um container, como
uma segurana ao cdigo, ao ciclo de vida, enfim, ao seu gerenciamento
como um todo. Mas para isso o EJB deve estar em corretamente
implementado com regras que permitam identific-lo como um EJB, para
que assim possamos aproveitar dos seus benefcios.
Tipos de componentes EJB
Existem trs tipos diferentes de EJB que so configurveis para diferentes
propsitos, vejamos abaixo:
Session EJB - Uma sesso usada para mapear processos. Existem dois
tipos de EJBs por sesso: stateless e statefull. EJBs geralmente devem
representar a pura concepo da funcionalidade para que foi criado e do
que preciso.
Entity EJB - Uma entidade EJB mapeia uma combinao de dados e mtodos
associados. Uma entidade EJB geralmente utlizada na concepo de
dados-objetos que so/sero gravados em uma base dados.
Message-driven EJB - Um Message-driven EJB muito parecido com o
conceito da Session EJB, mas somente ativado quando chegam
mensagens assncronas.
Onde us-los?
Ento, veja abaixo exemplos de onde podemos aplicar essas
funcionalidades.
Em um aplicativo Web-centric, o EJB vai fornecer a lgica de negcio
que est por trs dos componentes Web, como servlets e JSPs. Se

uma aplicao Web requer um alto nvel de escalabilidade e facilidade de

manuteno, o uso de EJBs pode ajudar a proporcionar isso.
Thick client applications, tais como aplicaes Swing, podem usar EJBs de
forma semelhante s aplicaes web-centric, para compartilhar a lgica de
negcios de uma forma natural entre os diferentes
tipos de aplicaes cliente.
Business-to-business (B2B) e-commerce applications tambm podem tirar
proveito de EJBs, pois um e-commerce B2B frequentemente gira em
torno da integrao dos processos empresariais. EJBs oferecem um local
ideal para abrigar a lgica do processo de negcios.
Enterprise Application Integration (EAI)
applications podem incorporar EJBs para a
transformao e mapeamento entre diferentes
aplicaes. Novamente, isso um encapsulamento da lgica do negcio que
necessria transferncia de dados entre aplicaes.

Sigla para Enterprise Java Beans

Basicamente EJB uma arquitetura de componentes multi-plataforma para
o desenvolvimento de aplicaes Java, muiti-tier, distribudas, escalveis e
orientadas a objetos.
O objetivo da arquitetura EJB facilitar o trabalho do desenvolvedor para
que ele no tenha que se preocupar com aspectos de infra-estrutura.
Existem 3 tipos de EJBs:
Session Bean - o tipo mais simples de EJB, pode ter estado (stateful) ou
no ter (stateless)
Entity Bean - mapeam tabelas de um banco de dados relacional atravs de
um arquivo de mapeamento. Na prtica cada objeto entity representa uma
linha de uma tabela. Existe uma linguagem de query especfica para buscar
entitys chamada EQL
MDB - so consumidores assincronos de mensagens de filas / tpicos JMS
Na teoria, o uso de EJBs tornaria mais fcil escrever aplicaes de
empresariais como componentes provendo um conjunto de servios
automticos para suportar aplicaes transacionais, o que no acontece na
prtica.
O Hibernate parte fundamental na nova especificao do EJB3, ou ento
na utilizao " na forma de gambiarra ARGHHHHHH " no 2x, servindo como
componente para persistncia dos objetos!

Detalhes sobre o modelo EJB

Localizao, Factory e Interfaces

A interface Home e o Home Object

Interface de Factory para criar, localizar e remover instncias de Beans
O desenvolvedor de Beans define esta interface
O Home Object implementa a interface Home
Implementa todos os servios de lifecycle do Bean
Lembre que os Beans no so acessados diretamente
Apenas o container (Home Object e EJBObject) acessa os Beans
O Home Object automaticamente construdo pelas ferramentas do
Container Provider a partir da interface especificada
O Home Object deve ser localizado pelo cliente atravs dos servios de
Naming (JNDI) do EJB Server
assim que tudo comea
A interface Remote e o EJBObject
Especifica os Business Methods do Bean
O cliente acessa o EJBObject e este interpe a funcionalidade desejada
(persistncia, transao, segurana, gerncia de estado), e acessa o Bean
Quem realmente implementa a interface Remote o EJBObject, no o Bean

O EJBObject gerado automaticamente pelas ferramentas do Container

Provider a partir da interface especificada
O modelo EJB 2.0 introduziu o conceito de interface locais.
Convenes de nomes para EJB
Item

Sintaxe

Exemplo

Nome do EJB no DD

<nome>EJB

AccountEJB

Nome de display do EJB

JAR no DD

<nome>JAR

AccountJAR

Classe de
implementao do EJB

<nome>Bean

AccountBean

Home interface

<nome>Home

AccountHome

Remote interface

<nome>

Account

Tipos de Beans
Caracterstica

O que o Bean
representa

Session Bean

Entity Bean

Uma conversao transiente

com um cliente

Do uma viso OO de um BD

Pode ser considerado uma

extenso do cliente que o
criou
Pode acessar um banco de
dados usando JDBC ou
acessando um Entity Bean

Igual ao tempo de vida do

cliente. Existe somente
Tempo de vida durante uma sesso
cliente/servidor
(curto espao de tempo)

Representam dados num

banco de dados e os mtodos
que agem sobre os dados
Num SGBDR, cada Bean
poderia representar um
registro de uma tabela, por
exemplo
Persiste tanto quanto os
dados do banco de dados
(longo espao de tempo)

Atributos

Representam o estado da
conversao. Este estado
Representam dados de um
mantido entre chamadas a
banco de dados (colunas de
mtodos mas no depois que uma tabela, por exemplo)
a sesso acaba

Persistncia
(alm da
sesso)

O Bean deve gerenciar sua

prpria persistncia

Compartilhame Um nico Bean por cliente

nto
(sem compartilhamento)

Gerenciada automaticamente
pelo Container
Acesso compartilhado entre
clientes

Container gerencia a
concorrncia
Identificado usando uma
chave primria
Criao

No incio de uma sesso

A criao de um novo Bean

insere dados num banco de
dados

Durabilidade

No sobrevive a um crash de
servidor

Sobrevive a um crash de
servidor

Transao

Pode ser "transaction-aware",

Transacional
se assim for programado

Exemplo

Shopping Cart

User Account Bean mantendo

os dados associados a um
usurio num site de compras

Diferenas entre dois tipos de Session Beans

O tipo definido no Deployment Descriptor
Stateful
Caracterstic
Session
a
Bean

Stateless Session Bean

No h estado a ser gerenciado
Bean pode sair da memria sem salvar qualquer
coisa (no h "Passivation")
Beans so intercambiveis e podem ser alocados
de um "pool"

Gerenciado
automatica
Gerncia de mente pelo
estado
Container
(Activation,
Passivation)

Estado
conversacio
Responsabili
O cliente tem que manter qualquer estado
nal pode ser
dades
necessrio
mantido no
Bean
Performance Mais pesado Extremamente lightweight
Verificao de crdito
(Todo o trabalho pode ser feito numa nica
chamada de mtodo)
Mailer Bean para enviar mail confirmando uma
compra
Bean que valida um ID de empregado

Exemplo

Shopping
Cart

Acesso a um Catlogo de Produtos. Embora

parea melhor usar um Entity bean aqui, devido
persistncia, lembre que o catlogo no est
associado a um cliente particular e que nenhum
estado sobre o cliente deve ser mantido. Porm,
um estado geral, no especfico a um cliente
particular pode ser mantido. Podemos usar
Stateless Beans para montar uma cache do
catlogo medida que este acessado. O Bean
prov browsing e searching no catlogo. Como o
Bean poder manipular vrias linhas do catlogo
ao mesmo tempo (no search, p. ex.) e oferecer
uma viso compartilhada de informao, o Bean
poder ser compartilhado.

Regras para escolher o tipo de Bean

Uso de Entity Beans
Quando o estado do Business Object deve ser armazenado de forma
persistente e o comportamento do objeto tem a ver basicamente com o
acesso ao estado
Para prover acesso concorrente por mltiplos clientes, quando o estado no
especfico a um cliente
Para representar uma nica linha lgica de um BD
Para prover robustez. Se dados de um cliente devem permanecer quando
uma sesso de cliente acabou ou depois de um crash de servidor, use um
Entity Bean
Uso de Stateful Session Bean
Para manter estado especfico a um cliente (estado conversacional). No h
compartilhamento com outros clientes

Para representar objetos no persistentes (objetos com curto tempo de vida

e que no precisam permanecer depois de uma sesso ou aps um crash de
servidor)
Para representar o workflow entre Business Objects (para administrar as
interaes entre Business Objects)
Uso de Stateless Session Bean
Para modelar servios reutilizveis (prevendo um servio genrico para os
clientes, sem manter dados especficos de um cliente)
Para prover alto desempenho (porm, lembre que o cliente ter que manter
o estado, se necessrio)
Para operar sobre mltiplas linhas lgicas de um BD (para representar uma
viso compartilhada de dados fixos)
Para prover uma viso procedural dos dados (quando se foge do modelo OO
e todos os dados necessrios so fornecidos na entrada e todos os
resultados retornados no fim do procedimento)
Business Logic deve estar nos Session Beans
Para escalabilidade, prefira Stateless Session Beans
O uso de Stateful Beans deve ser minimizado
Para acesso a BD, prefira Entity Beans para:
Ter uma viso OO dos dados
No ter que tratar de aspectos transacionais, de persistncia, de segurana,
etc.
Faa com que o cliente acesse apenas Session Beans
Esconda os Entity Beans atrs de Session Beans
Por qu?
Para possibilitar armazenar estado transacional o que no deve ser feito em
Entity Beans
Se houver aspectos transacionais no triviais a considerar, eles podem ser
tratados no Session Bean (escrito por um especialista) e o Application
Developer no vai ter que saber nada sobre transaes
Melhora a integridade dos Bancos de Dados, j que o Application Developer
no vai manipular o BD diretamente. Ele s usaria Session Beans
H um outro tipo de bean (Message-Driven) que no veremos
Usado para processar mensagens assncronas
Detalhes sobre os servios automticos
Gerncia de estado

Para gerenciar recursos limitados, o Container pode expulsar ("passivar")

um Bean (fazendo com que ele ocupe menos recursos temporariamente)
No ocorre para Stateless Session Beans
O Container decide como e quando fazer isso
Tem hook methods ejbActivate() e ejbPassivate() que permitem colocar a
lgica adicional desejada para estes momentos
Lembra que o container um framework e oferece hook methods
Normalmente, os hooks methods nada fazem porque o framework j tratou
de tudo
Gerncia de persistncia
Para Entity Beans
Alm de simplicidade, uma outra vantagem fundamental de usar
persistncia Bean-managed que posso mudar a fonte de dados subjacente
no futuro e nada afetar no componente ou nas aplicaes que o usam
Tem vrios hook methods que podem ser utilizadas
ejbCreate(), ejbRemove(), ejbLoad(), ejbStore(), ejbActivate(), ejbPAssivate()
A persistncia pode ser tratada pelo prprio Bean (Bean-managed
persistence)
Usar s se a ao default do container no for adequada
Apoia-se nos mtodos ejbLoad() e ejbStore(), principalmente, usando
chamadas JDBC, por exemplo
Pode ser Container-managed com vrias alternativas de implementao em
existncia
Serializao do componente
Mapeamento de campos do Bean para colunas de uma nica tabela de um
SGBD Relacional
O mapeamento feito em tempo de deployment
Se o Bean envolver vrias tabelas, pode-se criar uma View e mapear os
campos do Bean para colunas da view
Porm, lembre que vrios BDs no permitem atualizar os dados de uma
view
Implementao de complex joins atravs de um mapeamento ObjectRelational, com uma ferramenta visual especial
Gerncia de transaes
Para Session Beans e Entity Beans
Suporta transaes distribudas
Envolvendo vrios bancos de dados

Demarcao de transao pode ser feita das seguintes formas:

Com cdigo usando javax.jts.UserTransaction
Automaticamente feito pelo Container com instrues no Deployment
Descriptor
Demarcao: os atributos de demarcao podem se aplicar ao Bean todo ou
a mtodos individuais
Tipos de atributos de transao:
TX_NOT_SUPPORTED: chamada feita fora do contexto de qualquer transao
TX_BEAN_MANAGED: o Bean se vira
TX_REQUIRED: ao entrar no mtodo, usa o contexto atual de transao se
houver, caso contrrio, crie um novo contexto de transao
TX_SUPPORTS: Se o mtodo for chamado dentro de um contexto de
transao, ok; caso contrrio, tambm ok.
TX_REQUIRES_NEW: Um novo contexto de transao sempre criado
TX_MANDATORY: Se no houver contexto de transao, lana exceo
Tratamento de concorrncia:
Vrios nveis de isolamento de transao disponveis (no deployment
descriptor)
Esses nveis dizem quanto de outras transaes as suas estaro vendo
durante a execuo
Existe uma relao inversamente proporcional entre altos nveis de
isolamento e o nvel de concorrncia
Se voc quiser mais isolamento, mais locks sero usados pelo BD, haver
menos concorrncia e os tempos de espera crescero
Para entender os nveis de isolamento, precisamos entender trs situaes
que podem ocorrer:
Problema 1: Transao A modifica uma linha; transao B l a mesma linha;
transao A faz rollback e a linha desaparece. Esta situao chama-se dirty
read.
Problema 2: Transao A l uma linha; transao B modifica a linha;
transao A l a linha novamente e v valores diferentes. Esta situao
chama-se non-repeatable read.
Problema 3: Transao A seleciona um conjunto de linhas satisfazendo um
critrio de pesquisa (clusula WHERE); Transao B insere linhas que
tambm satisfazem a pesquisa; Transao A repete a pesquisa e recebe
novos dados. Esta situao chama-se phantom read.
No EJB, 4 nveis de isolamento so possveis:
TRANSACTION_READ_UNCOMMITTED

Permite dirty reads, non-repeatable reads e phantom reads

TRANSACTION_READ_COMMITTED
Permite non-repeatable reads e phantom reads
TRANSACTION_REPEATABLE_READ
Permite phantom reads
TRANSACTION_SERIALIZABLE
No permite as situaes acima
Segurana
Usa o modelo de segurana normal do Java (no JDK)
java.security
Tudo declarado no Deployment descriptor
Resumo
Pode estabelecer "roles"
Pode associar usurios a roles
Pode executar certos mtodos com privilgios especiais
Autorizao com Access Control Lists
Cada mtodo pode ter uma lista de usurios que podem cham-lo
Detalhes adicionais sobre o Container
Agora que sabemos mais sobre EJB, podemos listar as coisas que o
Container faz
Swap de Beans de/para disco
Gerncia de persistncia
Disponibiliza um Home Object (o factory) para criar e localizar Beans
Registra o Home Object no servio de nomes (JNDI) para que o cliente possa
ach-lo
Cria, inicializa e remove Beans
Se encarrega de executar os Business Methods no contexto apropriado de
transao
Implementa servios bsicos de segurana
Resource pooling (exemplo: conexes de bancos de dados)
Outros servios dependentes do fornecedor:
Load Balancing
Fail-over transparente

EJB != J2EE
O que resta do framework J2EE sem o modelo EJB?
J2EE basicamente uma padronizao de uma srie de servios
corporativos, tais como gerncia de transaes e gerncia de threads
EJB uma forma de compor esses servios sob a forma de um modelos de
componentes
Ainda podemos acessar alguns esses servios sem fazer uso de EJB
Utilizando-os diretamente no cdigo :-(
Utilizando alguns frameworks ou bibliotecas que abstraem o uso de tais
servios
No entanto, alguns servios apenas so oferecidos no modelo EJB
Entity beans so os nicos components dedicados ao acesso de dados no

framework J2EE
S EBJs suportam gerncia de transaes declarativas via Container Managed
Transactions (CMT)

Pool de threads para objetos de negcio

Existem algumas solues alternativas no-J2EE para esses servios. Ex.:
Hibernate, TopLink, Spring
O que realmente queremos do modelo EJB?
Por qu arquitetos de software experientes no mundo J2EE tendem a usar
apenas um subconjunto de EJB (Stateless Session Beans) ?
De uma forma geral, Stateless Session Beans e Message-driven Beans so bem
vistos!
Por outro lado, o valor de Stateful Session Beans bastante questionado
A especificao EJB torna difcil a tarefa dos containers de alcanar a mesma
robustez que objetos de sesso HTTP possuem
Por ltimo, Entity Beans so considerados a parte mais fraca da especificao
EJB
No resolvem bem o mapeamento O/R
So dificeis de testar
No existem sem o container EJB especfico
Examinemos alguns dos servios mais importantes providos por Stateless
Session Beans
Gerncia de transaes declarativas
Boa soluo para a maioria dos casos, porm no sempre apropriado
No a melhor implementao possvel

Existem outras alternativas, ex.: Spring

Acesso remoto
Considerado a melhor soluo para expor interfaces remotas via RMI/IIOP
(isso vale para todo o modelo EJB)
Se for necessrio expor WS existem outras boas opes
Pool de instncias EJB
Cada vez menos importante considerando a eficincia da Garbage
Collection moderna e o preo das memrias RAM
Pool de recursos
Ao contrrio do pool de instncias, extremamente importante
Por exemplo, pool de conexes de BD
Segurana
Declarativa e baseada em papis
No enderea todos os requisitos complexos, ex.: checagem de credenciais
dinmicas de segurana
O que no queremos do modelo EJB?
Proliferao do nmero de classes
precisamos de, pelo menos, 3 classes para implementar cada EJB: home
interface, component interface (local ou remota) e a classe de
implementao do bean
Complexidade nos Descritores de deployment
so enormes
praticamente impossveis de serem escritos manualmente
no intuitivos
existncia de descritores adicionais proprietrios de cada container EJB
Complexidade no class loading
O container EJB normalmente no usa o mesmo class loader do container
Web. A existncia de mais de um class loader potencialmente um grande
problema (ex.: class loaders so hierrquicos)
Dificuldade de testar
EJBs so extremamente dependentes do container EJB, o que dificulta testes
de unidade
Solues como o framework Cactus permitem que realizemos testes, porm
ainda uma alternativa complexa e custosa
Arquitetos de software tendem a minimizar a necessidade de se testar
Entity Beans fazendo com que estes tenham apenas mtodos getters e

setters. Isto bastante ruim, pois objetos de negcio devem conter

comportamento
Complexidade no modelo de programao
A premissa da especificao EJB de facilitar a escrita de aplicaes no foi
alcanada. Ex.: proliferao no nmero de classes e preciso realizar
consultas JNDI para acessar todo e qualquer EJB
Dificultar coisas simples
EJB torna dificil algumas coisas tradicionalmente simples
A implementao de um simgleton problematica, pois uma restrio EJB
de programao no permite a leitura/escrita de variveis estticas
(estamos falando de multiplas JVMs)
dificil garantir que algum processamento ocorra quando o container EJB
for iniciado
dificil compartilhar configuraes entre EJBs e objetos rodando fora do
container EJB
Perda de produtividade
Causada em grande parte pela complexidade do modelo
Algumas ferramentas minimizam esse problema :-)
Problemas de portatibilidade
Uma pergunta: por qu no temos componentes EJB de prateleira?
Dependndias de aspectos especficos do servidor de aplicao dificultam a
portatibilidade
Queremos mesmo ignorar totalmente a complexidade inerente s
aplicaes corporativas?
possivel obter uma grande reduo de complexidade usando conceitos
J2EE, mas no possvel esquecer totalmente de aspectos de design e
background requeridos em arquiteturas corporativas
Restries de prograo
A maioria das restries no so problemticas na prtica
Um pequeno preo a ser pago para se ter os servios oferecidos
Existem basicamente trs razes para a existncia dessas restries:
Custering
EJBs devem poder rodar em um cluster, portanto algumas premissas que
valem para uma nica JVM no so mais vlidas. Ex.: comportamento de
campos static
Gerncia de Trheads

A criao de suas prprias threads no EJB pode afetar a execuo das

threads gerenciadas pelo container
Segurana
Algumas restries so naturais em virtude de aspectos de segurana
O que esperar de de EJB 3.0?
EJB 3.0 comeou a ser desenvolvido meses antes do lanamento da release
2.1
Sua principal motivao "melhorar a arquitetura EJB de forma a reduzir
sua complexidade do ponto de vista do desenvolvedor"
Utilizar fortemente anotaes (J2SE 1.5) para reduzir o tamanho e
complexidade dos descritores de deployment
Adoo da abordagem Hibernate para persistncia em BDs relacionais
Ser que no tarde para EJB 3.0?
Existe um atraso entre o lanamento da especificao e sua implementao
pelos servidores EJB
A necessidade de manter compatibilidade pode dificultar as coisas

Argumentos questionveis quanto ao uso de EJB

"S possivel obter escala com o uso de EJBs"
"Muitos programadores entendem EJB"
Isso verdade?
EJB complexo
Requer um bom background de middleware e aplicaes corporativas
Grandes mudanas esto por vir com EJB 3.0
Usar Enterprise Beans ou no?
A primeira questo a ser feita quanto necessidade de se ter realmente
uma arquitetura distribuda
Caso uma necessrio uma arquitetura distribuda com RMI/IIOP, EJB a
tecnologia perfeita
Mesmo que no queiramos uma arquitetura distribuda, o uso de EJB pode
ser justificado em algumas outras situaes. Vejamos algumas delas:
Gerncia de transaes
Pode ser declarativa ou via programao
Controle de Concorrncia
EJB so escritos como se fossem single-threaded

Porm este no um argumento decisivo para o uso de EJB, pois, em geral,

no necessrio escrever cdigos extremamente complexos quanto
concorrncia
Threads so geralmente encontrados em cdigos que tratam de caching de
dados
E geralmente queremos fazer cache na camada web, no na camada de
aplicaes
Gerncia de Configurao declarativa
Permite que manipulemos variveis de ambiente e da aplicao atravs do
descritor de deployement (ejb-jar.xml)
Permite reconfigurar o EJB sem modificar cdigo java
Prtica bastante comum de programao, portanto no argumento
decisivo para o uso de EJB
De uma forma geral temos o seguinte: mais voc tem dos seguintes
requisitos (alguns discutidos acima), mais chances h de tirar proveito de
Enterprise Beans:
Gerncia de persistncia (EJB trata isso automaticamente)
Acesso concorrente a dados (EJB trata isso automaticamente)
Acesso remoto a dados (Beans EJB podem ser acessados remotamente)
Modelo de desenvolvimento baseado em componentes
Transportabilidade (executar em vrios ambientes operacionais)
Controle de transaes
Controle de segurana
Alta disponibilidade
Escalabilidade
Neutralidade com respeito a clientes (cliente pode ser thin, thick, web
service, CORBA, .Net, ser escrito em qualquer linguagem, ...)

Enterprise Java Beans e diferenas entre as verses 3.0 e 3.1

Servlets Container, Application Server, Java EE...?
Muita gente confunde, principalmente no incio da carreira ou na faculdade,
um servlet container com servidores de aplicao, por exemplo, qual a real
diferena entre o Tomcat (Servlet Container) e o Glasfish (Application
Server) ?
A plataforma Java EE fortemente baseada em componentes, o objetivo

desta abordagem, criar funcionalidades especficas que podem ser

reutilizveis e devem fazer parte de algo muito maior, como uma pea de
um quebra cabea que tem uma funo especifica de se encaixar com as
outras peas (componentes) para formar o todo.
Basicamente o Tomcat por ser um Servlet Container, no suporta varias
tecnologias que compoem o Java EE (verifique aqui os componentes suportados
pelo Java EE 7) dentre eles EJB's. J os Servidores de Aplicao, para serem
definidos como tal, devem suportar os componentes/tecnologias da
especificao Java EE (x), a exemplo do JBoss application Server 8que
implementa a JSR 342, para suportar o Java EE 7.
Veja a diferena nesta imagem do Web Container x EJB Container:

(Fonte: http://docs.oracle.com/cd/E19575-01/8193669/6n5sg7arb/index.html)
Tudo ok at agora? Voc j sabe o que um componente e a diferena entre
um Java EE Container e um Servlet Container, agora vamos entender um
pouco sobre os temidos EJB's.

Enterprise Java Beans

(EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) and JSR 345 (EJB 3.2).
Vamos falar das 4 ultimas Geraes de EJB's, onde, as ultimas 3 verses se
propoem a reestabelecer a honra da famlia e devem ser analisadas sem
rancor ou maguas, possivelmente causadas em uma poca no to
distante.

A proposta do EJB desde sua concepo sensacional, so componentes

que podem ser disponibilizados em ambientes distribuidos, voc cria
mdulos para executar regras de negcios especficas, que se tornam
acessveis para outros sistemas sem a necessidade de conhecer sua
implemetao. Seria possvel ter um componente EJB FolhaDePagamento,
sendo utilizado por vrios sistemas, sem a necessidade de conhecer como
vrias regras e legislaes foram implementadas. Basicamente voc
consegue particionar o seu problema e disponibilizar a soluo como um
componente.
O problema comea quando a complexidade para trabalhar a tecnologia X Y
ou Z muito grande, mesmo com recursos poderosos, as implementaes
anteriores a verso 3.0
deram muita dor de cabea para os programadores daquela poca (No, eu
ainda no era programador! Provavelmente estava jogando bola na rua ou
Tibia nesta poca \o/ ). Os principais problemas eram:
Para um simples EJB era necessrio no minimo implementar um interface e
criar um DDs (vejaaqui)
Uso de JNDI Lookups (No sabe o que JNDI Lookups? Veja aqui ) que foi
muito bem substituito por Injeo de Dependncias.
EJB-QL no era efetivo, sendo necessrio utilizar JDBC ou outro mecanismo
de persistncia e acesso ao banco de dados.
Mtodos de callback muitas vezes desnecessrios eram obrigatrios.
... J deu para entender porque tanta gente odeia (ou deveria) EJB.
Tudo isso causava muitos problemas e gargalos nas aplicaes, alta
complexidade aliada a vrias implementaes alternativas (muita coisa
ainda estava incompletada) e Anti-Patterns... deve ter muito programador
que perdeu noites de sono, fez muita hora extra e naturalmente se
apaixonou pelo Spring quando o mesmo comeou a se popularizar assim
como que por consequncia nunca mais quis ouvir falar de EJB (porm isto
da outro post!).
Na verso 3.x os EJB's foram completamente reestruturados implementando
conceitos fundamentados no mundo open source como DI, CoC, JPA e
Annotations. Abaixo vamos ver um comparativo entre as melhorias
efetuadas da verso 3.0 para 3.1 e suas diferenas.

Comparativo 3.0 x 3.1

Stateless Session Beans

Caso use EJB 3.0 sempre defina uma interface para seu Bean. Isto no
uma opo :)

Stateless Sessions Beans :

EJB para criar componentes especficos de regras de negcio onde no
existe a necessidade de manter estado entre os mtodos implementados.
Exemplo:

Public void showMessage (String message){

System.out.println(Sua mensagem : +message);
}

No dependo de nenhum outro mtodo para executar meu mtodo

showMessage("Str"), isso significa que este mtodo no tem a necessidade
de manter estado com outros mtodos deste EJB.

Anotaes:

@Stateless define um EJB como Stateless Session Bean.

@Remote(Inferface.class) define que o EJB poder ser acessado

remotamente.

@PostConstruct funciona como um mtodo de instancia que executado

aps a sesso do EJB ser criada pelo EJB Container.

@PreDestroy funciona como um mtodo de instancia que executado

antes da sesso do EJB ser encerrada pelo EJB Container.
Stateful Session Beans

Stateful Session Bean, tambm serve para criar componentes de negcio,

porm seu funcionamento o oposto de Stateless Session Beans. Com os
SSB tenho a necessidade de manter estado com outros mtodos do EJB.

Cada instncia deve ser exclusiva, j que necessrio manter o estado

entre os mtodos,porque oss dados de uma sesso no devem se
embaralhar com dados de outras sesses.Exemplo:

Imagine uma loja virtual onde voc tem os mtodos:

finalizarCompra();
consultarItensNoCarrinho();
adicionarItensNoCarrinho();

Os 'mtodos' da sesso de um usurio nunca devem se 'embaralhar' com os

'mtodos' de outros usurios, caso isso ocorra os mtodos que so
dependentes entre si sero prejudicados e no iro realizar as funes para
qual foram desenvolvidos.

Anotaes

EJB 3.0 necessrio definir uma interface para o bean e mapear se o EJB
ter acesso remoto ou local (similar ao stateless session bean)

@Stateful e @ Remote ou @Local + (nomeInterface.class)

EJB 3.1 no mais necessrio definir uma interface se o acesso ao EJB for
local. Deve-se mapear apenas com @Stateful

Um Stateful session bean pode ser definido como ocioso onde realocado
da memria principal para um dispositivo secundrio de armazenamento
(HD por exemplo) at ser requisitada novamente.

@Remove anotando um mtodo com remove o EJB container aps a

execuo deste mtodo o EJB Container ir destruir a sesso do stateful
session bean corrente.

@PostConstruct equivalente ao steteful session bean

@PreDestroy - equivalente ao steteful session bean

@PrePassivate uma instancia pode entrar no estado passivo caso no

esteja sendo utilizada pelo container (esteja ociosa esperando uma
chamada por exemplo). O mtodo anotado com prePassivate ir ser
executado antes da instancia entrar neste estado.

@PostActivate Quando uma instancia retorna do estado passivado para

ativo o mtodo anotado com postActivate ser executado.
Singleton Session Beans

Este tipo de Session Bean surgiu na verso 3.1 da especificao Enterprise

Java Beans. O objetivo deste session bean compartilhar dados transientes
entre todos os usurios da aplicao, onde todos usurios estaro
compartilhando a sesso.
Como este session bean est disponvel apenas na verso 3.1 caso o bean
seja configurado com acesso remoto , necessrio implementar uma
interface com as declaraes dos mtodos que devem ser implementados
no Bean,caso contrrio, se o acesso for local anotar a classe como
@Singleton j suficiente.
Aps definir a implementao da classe como @Singleton , informe se o
acesso ser,
@Local ou @Remote e a classe que representa a interface.

@Singleton
@Remote(EJBBean.class)
Public class EJBBeanImpl{ ..... }

@Startup inicia o singleton session bean junto a a aplicao, esta

anotao deve ser feita no topo da class.
@Singleton
@Startup
Public class EJBBeanImpl{ ..... }

Por padro a instancia de um singleton session bean ser criada quando o

EJB Container o fizer,porm podemos utilizar a anotao acima para obrigar
o container a criar o bean na inicializao da aplicao.
Este Session Bean tambm pode possuir mtodos de callback que
funcionam de maneira similar ao stateless e stateful sessions beans.

O Funcionamento dos mtodos:

@PostConstruct e @PreDestroy tem o funcionamento semelhante aos outros

Beans.
Fontes:
http://blog.caelum.com.br/novidades-do-ejb-31-do-futuro-java-ee-6/
https://today.java.net/pub/a/today/2007/01.23/migrating-from-ejb2x-toejb30.html
http://docs.oracle.com/cd/E16439_01/doc.1013/e13981/ses21imp002.htm#
BABFABIC
http://en.wikipedia.org/wiki/Enterprise_JavaBeans
http://docs.oracle.com/cd/E19575-01/8193669/6n5sg7arb/index.htmlhttp://www.infoq.com/br/news/2012/08/ejb-3.2inicial
http://www.slideshare.net/hlavalle4141/as-novidades-da-especificao-ejb-32