EJB 3.0 vs JSF2+Spring+Hibernate

Vamos a comentar brevemente lo que se define en la especificación EJB 3.0, para luego compararlo con las funcionlidades equivalentes ofrecidas por la terna JSF2+Spring+Hibernate que aplicamos en nuestro equipo de desarrollo:

EJB 3.0.

Es una de los apartados de la especificación J2EE. La especificación define los objetos de negocio (los EJB) y el comportamiento que deben tener los servidores de aplicaciones que quieran cumplir la especificación en su área de gestión de estos EJB, a este área de gestión se le llama comunmente Contenedor.

Entity Bean: Son los objetos del lado del servidor que almacena los datos. Hay dos tipos:

• Container Managed Bean. El contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante el mapeo de las columnas de una tabla con los atributos de un objeto.
• Bean Managed Persistence. El propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere, esto es los mecanismos de persistencia los ha generado el programador.

Session Bean: EJB de Sesión (Session EJBs): gestionan el flujo de la información entre el servidor y el usuario. Puede haber dos tipos:

• Statefull. Cada bean de sesión con estado, almacena los datos que persisten de una pantalla a otra como un carrito de la compra. Ofrece la funcionalidad común a N pantallas. Cuando el cliente termina el bean se borra.
• Stateless. Cada bean de sesión sin estado, almacena los datos asociados a una pantalla y la lógica de negocio asociada a una pantalla. La pantalla X visualizada por cada uno de los 1000 usuarios conectados simultáneamente a la página del detalle de un banco tienen su propio bean. Los contenidos de las variables no se conservan entre llamada y llamada.

Message-Drive Bean: Son beans para tareas asíncrono. Usan el API JMS (Java Messaging System). Los hay de varios tipos:

• Queue. N-Productores -> 1-Consumidor. Hay N generadores de mensajes que se apuntan a una cola donde dejan sus peticiones y un solo consumidor las va atendiendo por orden de llegada.
• Topic. N-Productores -> N-Consumidores. Hay N generadores de mensajes que se envían al topic, desde allí se envía una copia para cada uno de los consumidores, todos ellos reciben cada mensaje.

Equivalencias con nuestra infraestructura (JSF+Spring+Hibernate):

Container Managed Bean. Clases mapeadas con JPA + hibernate. Usamos hibernate como motor de HQL e implementador de JPA. Utilizamos este tipo de objetos en la capa de acceso a datos cuando la BBDD es relacional.
Bean Managed Persistence. Spring JDBC Template. Utilizamos este tipo de objetos en la capa de acceso a datos cuando la BBDD no es relacional.
Statefull. Los SessionBean de JSF (JSF ofrece además los ApplicationBean, que viven durante el tiempo que el portal está levantado)
Stateless. Los RequestBean de JSF (JSF ofrece también algo mas, los ViewBean que dan respaldo a N peticiones siempre que se navegue en la misma pantalla)
Queue. No usamos JMS en ningún proyecto, usamos el planificador Quartz que viene con Spring para los tratamientos asíncronos donde cierto "consumidor" debe tratar las peticiones que se han almacenado en una cola, en nuestro caso esta cola es la BBDD. Si quisiésemos trabajar con JMS usaríamos el JmsTemplate de Spring.
Topic. Esta funcionalidad no se nos ha planteado en ningún proyecto, pero si se plantease usaríamos el JmsTemplate de Spring.