¿Debo usar EJB3 o Spring para mi capa empresarial?
Mi equipo está desarrollando un nuevo producto orientado a servicios con un front-end web. En las discusiones sobre las tecnologías que usaremos, nos hemos decidido a ejecutar un servidor de aplicaciones JBoss, una interfaz Flex (con una posible implementación de escritorio con Adobe AIR) y servicios web para interactuar con el cliente y el servidor.
Hemos llegado a un punto muerto en lo que respecta a qué tecnología de servidor utilizar para nuestra lógica de negocios. El gran argumento se encuentra entre EJB3 y Spring, y nuestras principales preocupaciones son la escalabilidad y el rendimiento, y también la capacidad de mantenimiento del código base.
Aquí están mis preguntas:
- ¿Cuáles son los argumentos a favor o en contra de EJB3 vs Spring?
- ¿Qué escollos puedo esperar con cada uno?
- ¿Dónde puedo encontrar buena información de referencia?
No habrá mucha diferencia entre EJB3 y Spring en función del rendimiento. Elegimos Spring por los siguientes motivos (no mencionados en la pregunta):
- Spring impulsa la arquitectura en una dirección que admite más fácilmente las pruebas unitarias. Por ejemplo, inyecte un objeto DAO simulado en la prueba de unidad de su capa empresarial o utilice el objeto MockHttpRequest de Spring para probar un servlet de unidad. Mantenemos una configuración Spring independiente para las pruebas unitarias que nos permite aislar las pruebas a las capas específicas.
- Un controlador primordial era la compatibilidad. Si necesita admitir más de un Servidor de aplicaciones (o eventualmente desea que la opción pase de JBoss a Glassfish, etc.), esencialmente llevará su contenedor (Spring) con usted, en lugar de confiar en la compatibilidad entre diferentes implementaciones de Especificación EJB3.
- Spring permite opciones de tecnología para Persistence, control remoto de objetos, etc. Por ejemplo, también estamos usando un extremo delantero Flex, y estamos usando el protocolo Hessian para las comunicaciones entre Flex y Spring.
La brecha entre EJB3 y Spring es mucho más pequeña de lo que era, claramente. Dicho esto, una de las desventajas de EJB3 ahora es que solo puede inyectar en un bean, por lo que puede terminar convirtiendo componentes en beans que no necesitan serlo.
El argumento sobre la prueba de unidad es bastante irrelevante ahora: EJB3 está claramente diseñado para que sea más fácil de probar por unidad.
El argumento de compatibilidad anterior también es algo irrelevante: ya sea que use EJB3 o Spring, aún depende de implementaciones de terceros de gestores de transacciones, JMS, etc.
Sin embargo, lo que para mí sería un gran apoyo es el apoyo de la comunidad. Trabajando en un proyecto EJB3 el año pasado, no había mucha gente usándolo y hablando de sus problemas. La primavera, con razón o sin ella, es extremadamente generalizada, especialmente en la empresa, y eso hace que sea más fácil encontrar a alguien que tenga el mismo problema que usted está tratando de resolver.
¿Cuáles son los argumentos a favor o en contra de EJB3 vs Spring? Spring siempre está innovando y reconoce las restricciones del mundo real. Spring ofrecía simplicidad y elegancia para los servidores de aplicaciones Java 1.4 y no requería una versión de la especificación J2EE a la que nadie tuvo acceso en el período 2004-2006. En este punto, es casi un debate religioso al que puede aspirar: la primavera + abstracción + de código abierto frente a las especificaciones Java Enterprise Edition (Java EE) 5.0.
Creo que Spring complementa más que compite con las especificaciones de Java EE. A medida que las características que alguna vez fueron exclusivas de Spring continúan incorporándose a la especificación, muchos argumentarán que EJB 3 ofrece un conjunto de características "lo suficientemente bueno" para la mayoría de las aplicaciones comerciales internas.
¿Qué inconvenientes puedo esperar de cada uno? Si trata esto como un problema de persistencia (Primavera + JPA) versus EJB3, realmente no está haciendo una elección tan grande.
¿Dónde puedo encontrar una buena información de referencia? No he seguido la resultados de referencia de specj por algún tiempo, pero fueron populares por Un rato. Parece que cada proveedor (IBM, JBOSS, Oracle y Sun) se interesa cada vez menos en tener un servidor compatible. Las listas se vuelven más cortas y más cortas de proveedores certificados a medida que avanza desde 1.3, 1.4. 1.5 Java Enterprise Edition. Creo que los días de un servidor gigante que es totalmente compatible con todas las especificaciones han terminado.
Definitivamente recomendaría EJB3 durante la primavera. Encontramos que es más ágil, más agradable de codificar y mejor soportado. En el pasado usé Spring y me pareció muy confuso, y no tan bien documentado como EJB3 (o JPA, supongo que al final del día)
- A partir de EJB3 ya no tiene que lidiar con archivos de configuración externos, y solo hay un POJO que anotará por tabla de base de datos. Este POJO se puede pasar a su nivel web sin ningún problema. Los IDE como Netbeans pueden incluso generar automáticamente estos POJO por ti. Hemos usado EJB3 ahora como el back-end para bastantes aplicaciones a gran escala, y no hemos notado ningún problema de rendimiento. Sus Session Beans se pueden exponer fácilmente como servicios web que podría exponer a su interfaz Flex. Los beans de sesión son fáciles de bloquear, ya sea a nivel de método o clase, para asignar roles y cosas así, si es necesario.
No puedo hablar mucho sobre la primavera, ya que solo la probé durante unas semanas. Pero mi impresión general de que era muy pobre. Eso no significa que sea un marco defectuoso, pero nuestro equipo aquí ha encontrado que EJB3 es el mejor para la capa de persistencia/negocio.
Tiendo a preferir Spring en lugar de EJB3, pero mi recomendación sería cualquiera que sea el enfoque que adopte, intente seguir escribiendo POJO y utilice las anotaciones estándar siempre que sea posible, como las anotaciones JSR como @PostConstruct, @PreDestroy y @Resource que funcionan con EJB3 o Spring para que pueda elegir el marco que prefiera.
p.ej. usted podría decidir sobre algún proyecto para usar Guice en lugar de IoC.
Si desea utilizar la inyección previa a la solicitud, como en una aplicación web, puede encontrar que Guice es un poco más rápido para la inyección de dependencia que Spring.
Los beans de sesión se reducen principalmente a la inyección de dependencia y las transacciones; Así que EJB3 y Spring son bastante similares para eso. Donde Spring tiene la ventaja es en una mejor inyección de dependencia y mejores abstracciones para cosas como JMS
he utilizado una arquitectura muy similar en el pasado. Spring + Java 1.5 + Actionscript 2/3 cuando se combinó con Flex Data Services hizo que todo fuera muy fácil (¡y divertido!) Para codificar. sin embargo, un extremo delantero de Flex significa que necesita máquinas cliente suficientemente potentes.
Con respecto a su pregunta:
¿Cuáles son los argumentos a favor o en contra de EJB3 vs Spring?
Sugiero leer la respuesta de los expertos: NA RESPUESTA A: EJB 3 Y ANÁLISIS COMPARATIVO DE PRIMAVERA por Mark Fisher . Lea los comentarios para encontrar los comentarios de Reza Rahman (EJB 3.0).
Otra cosa a favor de spring es que la mayoría de las otras herramientas/marcos por ahí tienen un mejor soporte para la integración con spring, la mayoría de ellos también usan spring internamente (por ejemplo, activemq, camel, CXF, etc.).
También es más maduro y hay muchos más recursos (libros, artículos, mejores prácticas, etc.) y desarrolladores experimentados disponibles que para EJB3.