el holgazán

En primer lugar:

• Spring es un framework de aplicaciones Java/J2EE.
• EJB es una arquitectura de componentes para el desarrollo y despliegue de aplicaciones empresariales orientadas a objetos y distribuidas.

Por tanto, Spring y EJB no son una misma cosa: Spring es una implementación y EJB 3.0 es una especificación. Además, EJB soporta el desarrollo de componentes distribuidos, cuestión que no está incluida en la definición de Spring.

Lo que hace que la comparación pueda resultar natural es que Spring fuera desarrollado como una reacción a EJB y que tengan algunas áreas de solapamiento.

A continuación se comparan las características de persistencia, gestión de transacciones y el manejo del estado.


Persistencia

• Ambos soportan la persistencia de una forma funcionalmente equivalente basada en el mapeo objeto-relacional mediante anotaciones en las clases Java o mediante ficheros XML.
• Spring soporta a la vez varios proveedores de persistencia, como Hibernate, JDO, Toplink, iBatis o cualquier otro proveedor compatible con JPA. EJB soporta cualquier proveedor JPA, que es el API estándar implementado por proveedores como Hibernate, Kodo y Toplink.
• Spring soporta la persistencia JDBC. EJB no.
• Para implementar una caché de objetos compartidos por distintas unidades de trabajo (transacciones), lo que se hace en Spring es fijar la sesión (y la transacción) al hilo de ejecución, usando variables locales del hilo de ejecución. Aunque Spring proporciona clases para facilitar la implementación, en EJB el contexto de persistencia se propaga automáticamente en la transacción.
• Para implementar un mecanismo de “lazy loading”, mediante el cual la ejecución de una consulta a base de datos no se realice hasta que realmente sea necesaria, en Spring se usa un interceptor que debe ser configurado (OpenSessionInViewFilter). EJB simplifica esta labor definiendo un nuevo alcance del contexto de persistencia que permite asociar el tiempo de vida de la caché al de un bean de sesión, denominado “extended persistence context”, que puede especificarse mediante anotaciones.

Por tanto, puede decirse que:

Funcionalmente son equivalentes, aunque Spring es más flexible en su compatibilidad con proveedores de persistencia y EJB simplifica el desarrollo en algunos casos concretos.

Gestión de transacciones

• Funcionalmente son similares: en ninguno de los dos casos la lógica de negocio tiene que ocuparse explícitamente de la gestión de transacciones, ya que esto se realiza de forma declarativa.
• En Spring, la demarcación, la propagación y el aislamiento de transacciones se declaran mediante programación orientada aspectos, definiendo proxies para las transacciones en los ficheros de configuración XML.
• EJB 3.0 aplica la semántica de transacciones automáticamente en todos los métodos públicos de los beans de sesión, sin requerir configuración adicional. La propagación de las transacciones puede definirse mediante anotaciones o con XML.
• Spring se integra con diferentes APIs de transacciones, incluyendo JDBC, Hibernate y JTA.
• EJB 3.0 sólo soporta transacciones JTA. Hay que considerar que no todos los contenedores (como Tomcat) soportan JTA, aunque los contenedores EJB sí. En cualquier caso, si se requiere acceder a múltiples recursos en una misma transacción, se requiere una implementación JTA (existen implementaciones open source como JOTM).

Por tanto, puede decirse que:

Funcionalmente son similares, aunque Spring es más flexible en su compatibilidad con las APIs de gestión de transacciones y EJB simplifica el desarrollo en algunos casos concretos.

Manejo del estado

Hay que decir que las arquitecturas con estado no tienen el mismo rendimiento ni se escalan igual que las que no tienen estado. Pero hay que tener en cuenta que el estado es importante para muchas aplicaciones, debido a que la interacción del usuario con el sistema implica a veces una serie de pasos con efecto acumulativo.

• EJB proporciona una construcción de primer nivel denominada “Stateful Session Bean (SFSB)” para gestionar el estado tras diferentes llamadas a una misma instancia, que ha sido diseñado teniendo en cuenta cuestiones de escalabilidad y tolerancia a fallos. Estos beans son gestionados por el servidor.
• Spring no proporciona ninguna construcción equivalente aunque proporciona otros métodos para obtener el mismo resultado. Para que un bean de Spring tenga estado no deben ser compartidos entre llamadas. Para ello, el alcance de los beans debe configurarse como “prototype”, de manera que cada vez que se recupera un bean de la factoría se cree una nueva instancia.

Ventajas de los SFSBs:

• Están diseñados para optimizar el rendimiento, permitiendo el intercambio de beans entre memoria el almacenamiento de persistencia.
• Pueden ser ejecutados en un proceso separado del proceso que lo llama, lo que permite escalar las capas independientemente o separarlas por motivos de seguridad.
• Pueden implementar el interfaz opcional “SessionSynchronization” para poder deshacer los cambios en caso de deshacerse una transacción.

Opciones para implementar el estado:

• Base de datos: Tiene la ventaja de que es compartida por todos los servidores de aplicaciones. Sin embargo, esta es la capa menos escalable. Y si se usa una caché de segundo nivel, los datos tendrán que ser replicados.
• Sesión http: Es fácil de usar, pero los datos deben replicarse y no hay seguridad en las transacciones.
• Caché en memoria: Compartidos por todos los servidores de aplicaciones, potencialmente más eficiente que usar la base de datos. Los datos deben replicarse y no hay seguridad en las transacciones.

Por tanto, puede decirse que:

Ambos permiten las aplicaciones con estado, aunque con Spring había que implementar la forma de gestionar el rendimiento y la escalabilidad tal y como lo hacen los SFSBs.

(Vía DevX.com).