¿Debo usar EJB3 o Spring para mi capa empresarial?

Question

Mi equipo está desarrollando un nuevo producto orientado a servicios con una interfaz web.En las discusiones sobre qué tecnologías usaremos, decidimos ejecutar un servidor de aplicaciones JBoss y una interfaz Flex (con posible implementación de escritorio usando Adobe AIR) y servicios web para interconectar 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 empresarial.La gran discusión es entre EJB3 y Spring, siendo nuestras mayores preocupaciones la escalabilidad y el rendimiento, y también la mantenibilidad del código base.

Aquí están mis preguntas:

1. ¿Cuáles son los argumentos a favor o en contra de EJB3 vs Spring?
   • ¿Qué peligros puedo esperar de cada uno?
   • ¿Dónde puedo encontrar buena información de referencia?

Answer 1

No habrá mucha diferencia entre EJB3 y Spring según el rendimiento.Elegimos Spring por las siguientes razones (no mencionadas 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 para realizar una prueba unitaria de su capa empresarial, o utilice el objeto MockHttpRequest de Spring para realizar una prueba unitaria de un servlet.Mantenemos una configuración de Spring separada para pruebas unitarias que nos permite aislar pruebas en capas específicas.
• Un factor primordial fue la compatibilidad.Si necesita admitir más de un servidor de aplicaciones (o eventualmente desea tener la opción de pasar de JBoss a Glassfish, etc.), esencialmente llevará consigo su contenedor (Spring), en lugar de depender de la compatibilidad entre diferentes implementaciones del Especificación EJB3.
• Spring permite opciones tecnológicas para persistencia, comunicación remota de objetos, etc.Por ejemplo, también utilizamos una interfaz Flex y utilizamos el protocolo Hessian para las comunicaciones entre Flex y Spring.

Answer 2

La brecha entre EJB3 y Spring es claramente mucho menor de lo que era.Dicho esto, una de las desventajas de EJB3 ahora es que solo puedes inyectar en un bean, por lo que puedes terminar convirtiendo componentes en beans que no necesitan serlo.

El argumento sobre las pruebas unitarias es bastante irrelevante ahora: EJB3 está claramente diseñado para ser más fácilmente comprobable por unidades.

El argumento de compatibilidad anterior también es algo irrelevante:Ya sea que use EJB3 o Spring, aún depende de implementaciones de administradores de transacciones, JMS, etc. proporcionadas por terceros.

Sin embargo, lo que me haría cambiar es el apoyo de la comunidad.Trabajando en un proyecto EJB3 el año pasado, simplemente no había mucha gente usándolo y hablando de sus problemas.Spring, con razón o sin ella, es extremadamente omnipresente, particularmente 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.

Answer 3

¿Cuáles son los argumentos a favor o en contra de EJB3 vs Spring?Spring siempre está innovando y reconoce las limitaciones 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 tenía acceso en 2004 - 2006.En este punto, es casi un debate religioso en el que uno puede dejarse atrapar: Spring + abstracción + código abierto versus especificaciones Java Enterprise Edition (Java EE) 5.0.

creo que primavera complementa más que compite con las especificaciones Java EE.A medida que las características que alguna vez fueron exclusivas de Spring continúen incorporándose a la especificación, muchos argumentarán que EJB 3 ofrece un conjunto de características "suficientemente bueno" para la mayoría de las aplicaciones comerciales internas.

¿Qué peligros puedo esperar de cada uno?Si tratas esto como un problema de persistencia (Spring+JPA) versus EJB3, realmente no estás tomando una decisión tan importante.

¿Dónde puedo encontrar buena información de referencia?no he seguido el resultados de referencia de specj por algún tiempo, pero fueron populares por un tiempo.Parece que cada proveedor (IBM, JBOSS, Oracle y Sun) está cada vez menos interesado en tener un servidor compatible.Las listas de proveedores certificados se vuelven cada vez más cortas a medida que avanza desde 1.3, 1.4.1.5 Edición empresarial Java.Creo que se acabaron los días de un servidor gigante que cumplía totalmente con todas las especificaciones.

Answer 4

Definitivamente recomendaría EJB3 durante la primavera.Descubrimos que es más sencillo, más agradable de codificar y mejor compatible.En el pasado usé Spring y lo encontré muy confuso y no tan bien documentado como EJB3 (o JPA, supongo, al final del día).

1. A partir de EJB3, ya no tiene que lidiar con archivos de configuración externos y solo hay un POJO que puede 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 usted.Hemos utilizado EJB3 ahora como back-end para bastantes aplicaciones a gran escala y no hemos notado ningún problema de rendimiento.Sus Session Beans pueden exponerse fácilmente como servicios web que podría exponer en su interfaz Flex.Los beans de sesión son fáciles de bloquear a nivel de método o de clase para asignar roles y cosas así si es necesario.

No puedo hablar mucho de la primavera, ya que sólo lo probé durante unas semanas.Pero mi impresión general fue muy pobre.Eso no significa que sea un mal marco, pero nuestro equipo ha descubierto que EJB3 es el mejor para la capa de persistencia/negocio.

Answer 5

Tiendo a preferir Spring a EJB3, pero mi recomendación sería, independientemente del enfoque que adopte, intentar seguir escribiendo POJO y utilizar las anotaciones estándar siempre que sea posible, como las anotaciones JSR como @PostConstruct, @PreDestroy y @Resource, que funcionan con ambos EJB3. o Spring para que puedas elegir el marco que prefieras.

p.ej.podrías decidir en algún proyecto usar Guice en lugar de IoC.

Si desea utilizar la inyección previa a la solicitud, como en una aplicación web, es posible que Guice sea un poco más rápido para la inyección de dependencias que Spring.

Los beans de sesión se reducen principalmente a inyección de dependencia y transacciones;entonces EJB3 y Spring son bastante similares en eso.Donde Spring tiene ventaja es en una mejor inyección de dependencia y mejores abstracciones para cosas como JMS.

Answer 6

He usado una arquitectura muy similar en el pasado.Spring + Java 1.5 + Actionscript 2/3 cuando se combinan con Flex Data Services hicieron que codificar fuera muy fácil (¡y divertido!).sin embargo, una interfaz Flex significa que necesita máquinas cliente suficientemente potentes.

Answer 7

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: UNA RESPUESTA A:ANÁLISIS COMPARATIVO DE EJB 3 Y RESORTE por Mark Fisher.Lea los comentarios para encontrar los comentarios de Reza Rahman (EJB 3.0).

Answer 8

Otra cosa a favor de Spring es que la mayoría de las otras herramientas/marcos que existen tienen un mejor soporte para la integración con Spring, la mayoría de ellos también usan Spring internamente (p. ej.activemq, camello, 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.

Answer 9

Creo que EJB es una buena tecnología de componentes pero no un buen marco. Spring es el mejor marco disponible en la actualidad. Por lo tanto, debería considerar Spring como la mejor implementación de JEE en el sentido de un marco y mi recomendación es usar Spring en todos Proyecto que nos brinda la flexibilidad de integrarnos fácilmente con cualquier tecnología de componente.