De hecho, actualmente es un poco confuso, ya que ahora hay varios modelos de componentes en Java EE. Son Beans administrados CDI , EJB3 y JSF .
CDI es el chico nuevo del barrio. Habas CDI cuentan dependency injection
, scoping
y un event bus
. Los beans CDI son los más flexibles con respecto a la inyección y el alcance. El bus de eventos es muy ligero y muy adecuado incluso para las aplicaciones web más simples. Además de esto, CDI también expone una característica muy avanzada llamada portable extensions
, que es una especie de mecanismo de complemento para que los proveedores proporcionen funcionalidad adicional a Java EE que puede estar disponible en todas las implementaciones (Glassfish, JBoss AS, Websphere, etc.) .
Los beans EJB3 se actualizaron a partir del antiguo modelo de componente EJB2 * heredado y fueron los primeros beans en Java EE en ser beans gestionados mediante una anotación. Cuentan con los granos de EJB3 dependency injection
, declarative transactions
, declarative security
, pooling
, concurrency control
, asynchronous execution
y remoting
.
La inyección de dependencia en los beans EJB3 no es tan flexible como en los beans CDI y los beans EJB3 no tienen un concepto de alcance. Sin embargo, los beans EJB3 son transaccionales y agrupados de forma predeterminada ** , dos cosas muy útiles que CDI ha decidido dejar en el dominio de EJB3. Los otros elementos mencionados tampoco están disponibles en CDI. Sin embargo, EJB3 no tiene bus de eventos propio, pero tiene un tipo especial de bean para escuchar mensajes; el bean dirigido por mensajes. Esto se puede utilizar para recibir mensajes de Java Messaging System o de cualquier otro sistema que tenga un adaptador de recursos JCA. El uso de mensajería completa para eventos simples es mucho más pesado que el bus de eventos CDI y EJB3 solo define un oyente, no una API de productor.
Los beans administrados JSF han existido en Java EE desde que se incluyó JSF. Ellos también cuentan con dependency injection
y scoping
. JSF Managed Beans introdujo el concepto de alcance declarativo. Originalmente, los ámbitos eran bastante limitados y en la misma versión de Java EE, donde los beans EJB3 ya se podían declarar mediante anotaciones, los beans administrados JSF todavía tenían que declararse en XML. La versión actual de JSF Managed Beans también se declara finalmente a través de una anotación y los ámbitos se amplían con un ámbito de vista y la capacidad de crear ámbitos personalizados. El alcance de la vista, que recuerda datos entre solicitudes a la misma página, es una característica única de JSF Managed Beans.
Aparte del alcance de la vista, todavía hay muy poco para JSF Managed Beans en Java EE 6. El alcance de vista que falta en CDI es lamentable, ya que de lo contrario CDI habría sido un superconjunto perfecto de lo que ofrecen JSF Managed Beans. Actualización : en Java EE 7 / JSF 2.2, se ha agregado un @ViewScoped compatible con CDI , lo que hace que CDI sea el superconjunto perfecto. Actualización 2 : en JSF2.3, los beans administrados JSF se han desaprobado en favor de los beans administrados CDI.
Con EJB3 y CDI la situación no es tan clara. El modelo de componente EJB3 y la API ofrecen muchos servicios que CDI no ofrece, por lo que normalmente EJB3 no puede ser reemplazado por CDI. Por otro lado, CDI se puede usar en combinación con EJB3, por ejemplo, agregando soporte de alcance a los EJB.
Reza Rahman, miembro del grupo de expertos e implementador de una implementación de CDI llamada CanDI, ha insinuado con frecuencia que los servicios asociados con el modelo de componente EJB3 se pueden actualizar como un conjunto de anotaciones de CDI. Si eso sucediera, todos los beans gestionados en Java EE podrían convertirse en beans CDI. Esto no significa que EJB3 desaparezca o se vuelva obsoleto, sino solo que su funcionalidad se expondrá a través de CDI en lugar de a través de las propias anotaciones de EJB como @Stateless y @EJB.
Actualizar
David Blevins de TomEE y la fama OpenEJB explica muy bien las diferencias y similitudes entre CDI y EJB en su blog: CDI, when to break out the EJBs
* Aunque es solo un incremento en el número de versión, los beans EJB3 eran en su mayor parte un tipo de bean completamente diferente: un pojo simple que se convierte en un "bean administrado" aplicando una sola anotación simple, frente al modelo en EJB2 donde un peso pesado y Se requería un descriptor de implementación XML demasiado detallado para todos y cada uno de los beans, además de que el bean era necesario para implementar varias interfaces de componentes extremadamente pesadas y, en su mayor parte, sin sentido.
** Los beans de sesión sin estado generalmente se agrupan, los beans de sesión con estado generalmente no (pero pueden serlo). Para ambos tipos, la agrupación es opcional y la especificación EJB no lo exige de ninguna manera.