Primavera vs EJB. ¿Puede Spring reemplazar a EJB? [cerrado]

Respuestas:

201

Spring se desarrolló como una alternativa a EJB desde su inicio, por lo que la respuesta es, por supuesto, que puede usar Spring en lugar de EJB.

Si hay una "ventaja" en el uso de EJB, diría que dependería de las habilidades de su equipo. Si no tiene experiencia en Spring y mucha experiencia en EJB, entonces tal vez quedarse con EJB 3.0 sea una buena decisión.

Los servidores de aplicaciones escritos para admitir el estándar EJB pueden, en teoría, trasladarse de un servidor de aplicaciones Java EE compatible a otro. Pero eso significa mantenerse alejado de todas y cada una de las extensiones específicas del proveedor que lo bloquean en un solo proveedor.

Spring realiza puertos fácilmente entre servidores de aplicaciones (por ejemplo, WebLogic, Tomcat, JBOSS, etc.) porque no depende de ellos.

Sin embargo, estás encerrado en Spring.

Spring fomenta las buenas prácticas de diseño de OO (por ejemplo, interfaces, capas, separación de preocupaciones) que benefician cualquier problema que tocan, incluso si decide cambiar a Guice u otro marco DI.

Actualización: Esta pregunta y respuesta tienen cinco años en 2014. Es necesario decir que el mundo de la programación y el desarrollo de aplicaciones ha cambiado mucho en ese tiempo.

Ya no es solo una elección entre Java o C #, Spring o EJB. Con vert.x es posible evitar Java EE por completo. Puede escribir aplicaciones políglotas altamente escalables sin un servidor de aplicaciones.

Actualización: es marzo de 2016 ahora. Spring Boot ofrece una forma aún mejor de escribir aplicaciones sin servidores de aplicaciones Java EE. Puede crear un JAR ejecutable y ejecutarlo en una JVM.

Me pregunto si Oracle seguirá admitiendo la especificación Java EE. Los servicios web han reemplazado a los EJB. La solución EJB está muerta. (Solo es mi opinión.)

duffymo
fuente
7
En mi opinión, "bloquear" es una frase demasiado fuerte para describir Spring. Después de todo, Spring está diseñado para unir todo, no para reemplazarlos, siempre puede elegir con qué desea integrarse. Además, todo tiene bloqueos, incluso el Apache Commons más simple nos encierra, pero todavía lo usamos todos los días.
Christopher Yang
3
No hay proveedores alternativos a VMWare / Spring de la forma en que puede elegir entre las plataformas Oracle, Red Hat e IBM para Java EE. Eso es todo lo que quise decir. No es un comentario sobre la capacidad o utilidad de Spring. Me gusta mucho. Lo uso todos los días y duermo por la noche.
duffymo
1
@ChristopherYang eso es correcto. Quiero decir, "Java" sería un proveedor lock-n. Entonces, eventualmente, solo tenemos que dejar de discutir y hacer algo. :-)
cbmeeks
4
Esta pregunta tiene casi cinco años. Personalmente, creo que los EJB son tecnologías anticuadas que han perdido en todos los sentidos a los servicios web HTTP. Victoria simple y abierta. Dame servicios REST y podrás quedarte con tus EJB. Spring los apoya muy bien. Ahí es donde se ha ido el mundo.
duffymo
1
gracias por la respuesta. Solo busco los beneficios al evaluar el mejor (SPRING, EJB 3.x) para la migración desde la aplicación EJB 2.1 existente. Una pregunta más, EJB 3.x también es compatible con WebService. Entonces, ¿podríamos obtener los beneficios de JNDI / RMI para la distribución de aplicaciones Java y WS para otras aplicaciones?
fronteras
48

Primero, déjame decirlo claramente, no estoy diciendo que no debas usar Spring pero, como estás pidiendo algunas ventajas, aquí hay al menos dos de ellas:

  • EJB 3 es un estándar, mientras que Spring no lo es (es un estándar de facto pero no es lo mismo) y esto no cambiará en el futuro previsible. Aunque puede usar el marco Spring con cualquier servidor de aplicaciones, las aplicaciones Spring están bloqueadas tanto en Spring como en los servicios específicos que elija integrar en Spring.

  • El marco Spring se encuentra en la parte superior de los servidores de aplicaciones y las bibliotecas de servicios. El código de integración de servicios (por ejemplo, plantillas de acceso a datos) reside en el marco y está expuesto a los desarrolladores de aplicaciones. Por el contrario, el marco EJB 3 está integrado en el servidor de aplicaciones y el código de integración de servicios está encapsulado detrás de una interfaz. Los proveedores de EJB 3 pueden optimizar el rendimiento y la experiencia del desarrollador trabajando a nivel de servidor de aplicaciones. Por ejemplo, pueden vincular estrechamente el motor JPA a la gestión de transacciones JTA. Otro ejemplo es el soporte de agrupamiento que es transparente para los desarrolladores de EJB 3.

Sin embargo, EJB 3 no es perfecto, todavía le faltan algunas características (por ejemplo, inyección de componentes no administrados como POJO simples).

Pascal Thivent
fuente
1
Respuesta educativa, pero me pregunto por qué / cuándo necesita inyectar un POJO simple en lugar de inicializar uno nuevo.
Ömer Faruk Almalı
4
Con fines de prueba.
Philip
22

Los puntos de Pascal son válidos. Sin embargo, existen los siguientes a favor de Spring.

  • La especificación EJB es en realidad un poco floja y, por lo tanto, se pueden observar diferentes comportamientos con diferentes servidores de aplicaciones. Esto no será cierto en la mayoría de los casos, por supuesto, pero he tenido ese problema con algunos "rincones oscuros".

  • Spring tiene muchas ventajas adicionales, como spring-test, AOP, MVC, integración JSF, etc. EJB tiene algunos de esos (interceptores, por ejemplo), pero en mi opinión no están tan desarrollados.

En conclusión, depende principalmente de tu caso exacto.

Bozho
fuente
Tal vez algo como Spring solo necesita un motor de servlet sería más preciso (EJB se puede usar en cualquier contenedor JEE, motor de servlet! = Contenedor JEE).
Pascal Thivent
1
Bueno, técnicamente, Spring tampoco requiere un motor de servlet. Por ejemplo, spring-test usa un contexto en memoria.
Bozho
3
Bueno, técnicamente, los EJB no requieren un contenedor independiente ni si va de esta manera. Desde EJB 3.1 existe la EJBContainer.createEJBContainer()API estándar para usar un contenedor integrado. Entonces, aún así, su declaración es incorrecta.
Pascal Thivent
ok, 3.1 es bastante nuevo y obviamente me olvidé de las adiciones. Eliminé ese punto de mi respuesta.
Bozho
-30

Spring está destinado a complementar EJB, no a reemplazarlo. Spring es una capa encima de EJB. Como sabemos, la codificación de EJB se realiza mediante API, lo que significa que tenemos que implementar todo en las API utilizando el marco Spring. Podemos crear un código de placa de caldera, luego simplemente tomar esa placa, agregarle algunas cosas, luego todo está hecho. Internamente, Spring está conectado con EJB: Spring no existiría sin EJB.

La principal ventaja de usar Spring es que no hay ningún acoplamiento entre clases.

Sasi
fuente
8
estás totalmente equivocado, lo siento
Jakub H
2
lo siento @sasi, esto ni siquiera se acerca a una respuesta correcta o agradable .......
Prakash
4
"Spring no existiría sin EJB". Hombre, ¿eres de verdad? ¿Alguna vez en su vida ha utilizado "\ @Stateless" en la declaración de un EJB, o ha utilizado la anotación \ @EJB para inyección? ¿Crees que funcionarían en Jetty o Tomcat? ¿Cómo cree que se gestionan las transacciones en primavera? ¿Sabes que puedes implementar una aplicación Spring en un contenedor de servlets, verdad?
99Sono
Lo siento, pero no tiene una comprensión bien estructurada de ambos, EJB como parte de Java EE y Spring como principio de convención sobre configuración. En realidad, si no profundizas en las profundidades, puedes terminar pensando que son de alguna manera lo mismo o relacionado o lo que sea de ese tipo. ¿Por qué? Ambos tienen similitudes como la inyección y la diferencia entre ellos es enorme. Es cierto que Spring nació como una alternativa al pasado de EJB debido a la complejidad de EJB, pero así fue. Lo suficientemente bueno durante la época de Java EE 5 (EJB 3) también se retocó haciendo como lo hacía la primavera con su COC
Ishimwe Aubain Consolateur