Enterprise Java Beans e diferenças entre as versões 3.0 e 3.1
Autor: . | Publicado: 2013-06-17T12:00:00-07:00










Introdução


Servlets Container, Application Server, Java EE...?

Muita gente confunde, principalmente no início da carreira ou na faculdade, um servlet container com servidores de aplicação, por exemplo, qual a real diferença entre o Tomcat (Servlet Container) e o Glasfish (Application Server) ?

A plataforma Java EE é fortemente baseada em componentes, o objetivo desta abordagem, é criar funcionalidades específicas que podem ser reutilizáveis e devem fazer parte de algo muito maior, como uma peça de um quebra cabeça que tem uma função especifica de se encaixar com as outras peças (componentes) para formar o todo.



Basicamente o Tomcat por ser um Servlet Container, não 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 Aplicação, para serem definidos como tal, devem suportar os componentes/tecnologias da especificação Java EE (x), a exemplo do JBoss application Server 8 que implementa a JSR 342, para suportar o Java EE 7.

Veja a diferença nesta imagem do Web Container x EJB Container:

<img alt="Diagram of Java EE Platform APIs for the applet, web,
EJB, and application client containers." src="http://docs.oracle.com/cd/E19575-01/819-3669/images/overview-j2eeArchitecture.gif" />
&nbsp;(Fonte:&nbsp;http://docs.oracle.com/cd/E19575-01/819-3669/6n5sg7arb/index.html)

Tudo ok até agora? Você já sabe o que é um componente e a diferença 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),&nbsp;JSR 220&nbsp;(EJB 3.0),&nbsp;JSR 318&nbsp;(EJB 3.1) and&nbsp;JSR 345&nbsp;(EJB 3.2).

Vamos falar das 4 ultimas Gerações de EJB's, onde, as ultimas 3 versões se propoem a reestabelecer a honra da família e devem ser analisadas sem rancor ou maguas, possivelmente causadas em uma época não tão distante.


A proposta do EJB desde sua concepção é sensacional, são componentes que podem ser disponibilizados em ambientes distribuidos, você cria módulos para executar regras de negócios específicas, que se tornam acessíveis para outros sistemas sem a necessidade de conhecer sua implemetação. Seria possível ter um componente EJB FolhaDePagamento, sendo utilizado por vários sistemas, sem a necessidade de conhecer como várias regras e legislações foram implementadas. Basicamente você consegue particionar o seu problema e disponibilizar a solução como um componente.

O problema começa quando a complexidade para trabalhar a tecnologia X Y ou Z é muito grande, mesmo com recursos poderosos, as implementações anteriores a versão 3.0
deram muita dor de cabeça para os programadores daquela época (Não, eu ainda não era programador! Provavelmente estava jogando bola na rua ou Tibia nesta época \o/ ). Os principais problemas eram:

&nbsp;Para um simples EJB era necessário no minimo implementar um interface e criar um DDs (veja aqui)
&nbsp;Uso de JNDI Lookups (Não sabe o que é JNDI Lookups? Veja aqui ) que foi muito bem substituito por Injeção de Dependências.

&nbsp;EJB-QL não era efetivo, sendo necessário utilizar JDBC ou outro mecanismo de persistência e acesso ao banco de dados.

&nbsp;Métodos de callback muitas vezes desnecessários eram obrigatórios.

&nbsp;... Já deu para entender porque tanta gente odeia (ou deveria) EJB.

&nbsp;Tudo isso causava muitos problemas e gargalos nas aplicações, alta complexidade aliada a várias implementações 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 começou a se popularizar, e assim como que por consequência, nunca mais quis ouvir falar de EJB (porém isto da outro post!).

Na versão 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 versão 3.0 para 3.1 e suas diferenças.




Comparativo 3.0 x 3.1


Stateless Session Beans




Caso use EJB 3.0 sempre defina uma interface para seu Bean. Isto não é uma opção :)



Stateless&nbsp; Sessions
Beans :&nbsp;

EJB para criar componentes específicos de regras de negócio onde não
existe a necessidade de manter estado entre os métodos implementados. Exemplo:



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Public void showMessage (String message){

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;System.out.println(“Sua mensagem é :&nbsp; “+message);

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } 



Não dependo de nenhum outro método para executar meu método
showMessage("Str"), isso significa que este método não tem a necessidade de manter
estado com outros métodos deste EJB.



Anotações:



@Stateless – define um EJB como Stateless Session Bean.





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



@PostConstruct – funciona como um método de instancia que é
executado após a sessão do EJB ser criada pelo EJB Container.



@PreDestroy – funciona como um método de instancia que é
executado antes da sessão do EJB ser encerrada pelo EJB Container.


Stateful Session Beans



Stateful Session Bean, também serve para criar componentes
de negócio, porém seu funcionamento é o &nbsp;oposto de Stateless Session Beans. Com os SSB&nbsp;tenho a necessidade de manter estado com
outros métodos do EJB.



&nbsp;Cada instância deve
ser exclusiva, já que é necessário manter o estado entre os métodos,porque oss dados de uma sessão não devem se embaralhar com dados de outras
sessões.Exemplo:



Imagine uma loja virtual onde você tem os métodos:



&nbsp; finalizarCompra();&nbsp;

&nbsp; consultarItensNoCarrinho();

&nbsp; adicionarItensNoCarrinho(); &nbsp;



Os 'métodos' da sessão de um usuário nunca devem se 'embaralhar' com os 'métodos' de outros usuários, caso isso ocorra os métodos que são dependentes entre si serão prejudicados e não irão realizar as funções para qual foram desenvolvidos.





Anotações



EJB 3.0 – necessário 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 não é mais necessário definir uma interface se o
acesso ao EJB for local. Deve-se mapear apenas com @Stateful



Um Stateful&nbsp; session
bean pode ser definido como ocioso onde é realocado da memória principal para
um dispositivo secundário de armazenamento (HD por exemplo) até ser requisitada
novamente.



@Remove – anotando um método com remove o EJB container após
a execução deste método o EJB Container irá destruir a sessão do stateful
session bean corrente.



@PostConstruct&nbsp; – equivalente
ao steteful session bean



@PreDestroy - equivalente ao steteful session bean



@PrePassivate – uma instancia pode entrar no estado passivo
caso não esteja sendo utilizada pelo container (esteja ociosa esperando uma
chamada por exemplo). O método anotado com prePassivate irá ser executado antes
da instancia entrar neste estado.



@PostActivate – Quando uma instancia retorna do estado
passivado para ativo o método anotado com postActivate será executado.


Singleton Session Beans



Este tipo de Session Bean surgiu na versão 3.1 da
especificação Enterprise Java Beans. O objetivo deste session bean&nbsp; é compartilhar dados transientes entre todos
os usuários da aplicação, onde todos usuários estarão compartilhando a
“sessão”. 

Como este session bean está disponível apenas na versão 3.1
caso o bean seja configurado com acesso remoto ,é necessário implementar uma
interface com as declarações dos métodos que devem ser implementados no
Bean,caso contrário, se o acesso for local anotar a classe como @Singleton já é
suficiente.

Após definir a implementação da classe como @Singleton ,
informe se o acesso será,

@Local ou @Remote e a classe que representa a interface.



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @Singleton

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @Remote(EJBBean.class)

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Public class
EJBBeanImpl{ ..... }



@Startup – inicia o singleton session bean junto a a
aplicação, esta anotação deve ser feita no topo da&nbsp; class.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @Singleton

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;@Startup

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Public class
EJBBeanImpl{ ..... }



Por padrão a instancia de um singleton session bean será
criada quando o EJB Container o fizer,porém podemos utilizar a anotação acima
para obrigar o container a criar o bean na inicialização da aplicação.

Este Session Bean também pode possuir métodos de callback
que funcionam de maneira similar ao stateless e stateful sessions beans.



O Funcionamento dos métodos:



@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-to-ejb30.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/819-3669/6n5sg7arb/index.htmlhttp://www.infoq.com/br/news/2012/08/ejb-3.2-inicial
http://www.slideshare.net/hlavalle4141/as-novidades-da-especificao-ejb-32