Atualmente é um pouco confuso, pois agora existem vários modelos de componentes em Java EE. Eles são CDI , EJB3 e JSF Managed Beans .
CDI é o novo garoto do bairro. Feijão CDI apresentam dependency injection
, scoping
e um event bus
. Os beans CDI são os mais flexíveis em relação à injeção e ao escopo. O barramento de eventos é muito leve e muito adequado até mesmo para os aplicativos da web mais simples. Além disso, o CDI também expõe um recurso muito avançado chamado portable extensions
, que é uma espécie de mecanismo de plug-in para fornecedores para fornecer funcionalidade extra para Java EE que pode ser disponibilizada em todas as implementações (Glassfish, JBoss AS, Websphere, etc) .
Os beans EJB3 foram adaptados do antigo modelo de componente EJB2 legado * e foram os primeiros beans em Java EE a serem beans gerenciados por meio de uma anotação. Apresentam beans EJB3 dependency injection
, declarative transactions
, declarative security
, pooling
, concurrency control
, asynchronous execution
e remoting
.
A injeção de dependência em beans EJB3 não é tão flexível quanto em beans CDI e os beans EJB3 não têm conceito de escopo. No entanto, os beans EJB3 são transacionais e agrupados por padrão ** , duas coisas muito úteis que o CDI optou por deixar no domínio do EJB3. Os demais itens citados também não estão disponíveis no CDI. No entanto, o EJB3 não possui barramento de eventos próprio, mas possui um tipo especial de bean para ouvir mensagens; o bean acionado por mensagem. Isso pode ser usado para receber mensagens do Java Messaging System ou de qualquer outro sistema que tenha um adaptador de recursos JCA. O uso de mensagens completas para eventos simples é muito mais pesado do que o barramento de eventos CDI e o EJB3 define apenas um ouvinte, não uma API de produtor.
JSF Managed Beans existem no Java EE desde que o JSF foi incluído. Eles também apresentam dependency injection
e scoping
. O JSF Managed Beans introduziu o conceito de escopo declarativo. Originalmente, os escopos eram bastante limitados e na mesma versão do Java EE em que os beans EJB3 já podiam ser declarados por meio de anotações, os JSF Managed Beans ainda tinham que ser declarados em XML. A versão atual do JSF Managed Beans também é finalmente declarada por meio de uma anotação e os escopos são expandidos com um escopo de visualização e a capacidade de criar escopos personalizados. O escopo da visualização, que lembra os dados entre as solicitações para a mesma página, é um recurso exclusivo do JSF Managed Beans.
Além do escopo de visão, há muito pouco ainda acontecendo para JSF Managed Beans no Java EE 6. O escopo de visão ausente no CDI é lamentável, pois caso contrário, o CDI teria sido um superconjunto perfeito do que o JSF Managed Beans oferece. Atualização : No Java EE 7 / JSF 2.2, um @ViewScoped compatível com CDI foi adicionado, tornando o CDI um superconjunto perfeito. Atualização 2 : No JSF2.3, os beans gerenciados JSF foram preteridos em favor dos beans gerenciados CDI.
Com EJB3 e CDI a situação não é tão clara. O modelo de componente EJB3 e a API oferecem muitos serviços que o CDI não oferece, portanto, normalmente, o EJB3 não pode ser substituído pelo CDI. Por outro lado, o CDI pode ser usado em combinação com o EJB3 - por exemplo, adicionando suporte de escopo aos EJBs.
Reza Rahman, membro do grupo de especialistas e implementador de uma implementação de CDI chamada CanDI, freqüentemente sugeriu que os serviços associados ao modelo de componente EJB3 podem ser adaptados como um conjunto de anotações de CDI. Se isso acontecesse, todos os beans gerenciados em Java EE poderiam se tornar beans CDI. Isso não significa que o EJB3 desapareça ou se torne obsoleto, mas apenas que sua funcionalidade será exposta via CDI em vez de pelas próprias anotações do EJB, como @Stateless e @EJB.
Atualizar
David Blevins, da fama TomEE e OpenEJB, explica as diferenças e semelhanças entre CDI e EJB muito bem em seu blog: CDI, quando divulgar os EJBs
* Embora seja apenas um incremento no número da versão, os beans EJB3 eram, em sua maioria, um tipo de bean completamente diferente: um pojo simples que se torna um "bean gerenciado" aplicando uma única anotação simples, versus o modelo em EJB2 onde um peso pesado e O descritor de implantação XML excessivamente detalhado era necessário para cada bean, além do bean ser necessário para implementar várias interfaces de componentes extremamente pesadas e, em sua maioria, sem sentido.
** Os beans de sessão sem estado normalmente são agrupados, os beans de sessão com estado normalmente não (mas podem ser). Para ambos os tipos, o pool é, portanto, opcional e a especificação EJB não o exige de nenhuma forma.