comparison - usar - java ejb container

EJB 3.1 o Spring 3.. ¿Cuándo elegir cuál?

Question

EJB logró muchas mejoras en las versiones 3.x, Spring también se usa comúnmente y la versión 3 es una buena alternativa.

Hay muchos artículos en la web, pero no hay una comparación exacta sobre ejb3x versus spring3x ... ¿Tiene alguna idea sobre ellos, en los ejemplos del mundo real, cuál es mejor en qué condiciones?

Por ejemplo, queremos separar db y servidor, lo que significa que nuestra aplicación estará en un servidor, nuestra base de datos estará en otro servidor ... ¿Ejecución remota de EJB contra Cluster4Spring, etc.?

¿Hacer todo @Annotation siempre es bueno? ¿Configuración nunca necesaria?

Answer 1

A menudo no es Spring vs EJB, sino Spring vs Java EE. EJB en sí se compara con los frijoles de primavera. Ambos son un tipo de beans administrados que se ejecutan dentro de un contenedor (el contenedor EJB o el contenedor Spring).

En general, las dos tecnologías son bastante similares. Reza Rahman hizo una gran comparación entre los dos hace un tiempo.

Answer 2

EJB 3.1 es el mejor y es el estándar para las aplicaciones Java 6 EE.

Spring aún no es compatible con Java 6 CDI (weld) también depende mucho de la configuración XML. EJB 3.1 es potente e inteligente.

Creo que Spring 3.1 no necesita ninguna configuración XML. Tienes la opción de usar anotaciones para la configuración.

Answer 3

Elija uno u otro, pero no ambos.

Mi preferencia personal es la primavera. He utilizado en proyectos con gran éxito durante los últimos seis años. Es tan sólido como cualquier otro software por ahí.

Spring puede trabajar con EJB si eliges tenerlos en tu aplicación, pero no creo que lo contrario sea cierto.

Recomendaría máquinas físicas separadas para servidores web, de aplicaciones y de bases de datos si se lo puede permitir.

Spring puede trabajar con varias opciones remotas, incluidos los servicios web SOAP y REST. Una comparación de Spring beans con EJB está fuera del alcance de esta pregunta. No veo qué tiene que ver con tu implementación. Si utiliza los servicios Spring POJO, están en la memoria en lugar de requerir otro salto de red como los EJB remotos. Piensa en la Ley de objetos distribuidos de Fowler: "No". Solo introducir la latencia con buena razón.

Answer 4

La verdadera pregunta que debe hacerse es CDI / EJB o Spring

Answer 5

Los EJB son más ventajosos debido a la estandarización. Si está trabajando con una aplicación liviana, creo que ir con Spring está bien, pero si espera que su aplicación sea grande y requiera una gran cantidad de acceso a la memoria y acceso a las conexiones de datos, puede considerar comenzar su desarrollo con EJB. La razón principal es que el agrupamiento y el equilibrio de carga están integrados en el marco de EJB.

En un entorno EJB, cuando se implementa un EAR (''E''nterprise'' AR''chive), se puede implementar con múltiples beans EJB que cada uno podría tener un propósito específico. Digamos que usted escribió un bean para la gestión de usuarios y otro bean para la gestión de productos. Tal vez un día encuentre que sus servicios de usuario superan los servicios de acceso a sus productos y desea mover su bean de usuario a un servidor diferente en una máquina diferente. Esto se puede hacer en tiempo de ejecución sin alterar su código. Los beans se pueden mover entre servidores y bases de datos, para acomodar la agrupación en clústeres y el equilibrio de carga / datos sin afectar a sus desarrolladores o usuarios, ya que la mayoría de ellos se pueden configurar en el nivel de implementación.

Otra razón para respaldar un estándar es saber que la mayoría de los proveedores externos grandes lo respaldarán, lo que resultará en menos problemas al integrarse con un nuevo estándar / servicio / tecnología; Y si está en una especificación pública, las nuevas empresas de inicio o los desarrolladores de tipo pueden crear una versión de código abierto.

http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

Es muy desafortunado que incluso los diseñadores o programadores más inteligentes no pueden predecir cuál de sus características puede o no ser aceptada por la comunidad de desarrollo, que es la razón principal por la que el software se infla ... ¡Java EE es definitivamente eso!

Answer 6

Mencionaría las pruebas de unidad aquí. En la aplicación web común (controlador-> servicio-> datos -> ...-> vista) EJB y Spring proporcionan resultados similares, pero Spring ofrece pruebas más fáciles.

En mi humilde experiencia, la forma en que se desarrollan es diferente en algunos aspectos:

• Prueba unitaria (gana la primavera). En primavera se hace bastante bien hacia adelante, mientras que en ejb tienes que usar Arqullian con ShrinkWrap (¡sic!) Que es lento en cada compilación.
• Persistencia (ejb gana). En la primavera hay una lucha a su alrededor, es decir, Google "cómo autowire la persistencia en la escucha de la entidad" http://bit.ly/1P6u5WO
• Configuración (ejb gana). Cuando el novato llegaba a la primavera de ejb, me sorprendió un enjambre de anotaciones y archivos .xml.

Answer 7

Para su caso de uso donde la aplicación se ejecuta en un servidor y la base de datos se ejecuta en otro, la elección entre EJB y Spring es irrelevante. Todas las plataformas lo admiten, ya sea una aplicación Java SE, un contenedor de Servlet simple como Tomcat o Jetty, PHP, Ruby on Rails, o lo que sea.

No necesitas ningún tipo de comunicación remota explícita para eso. Solo define un origen de datos, proporcione la URL donde vive su servidor de base de datos y eso es todo.

Dicho esto, tanto EJB como Spring Beans hacen que sea más fácil trabajar con fuentes de datos. Ambos le ayudan a definir una fuente de datos, inyectándola en beans y administrando las transacciones asociadas con ellos.

De los dos, EJB (y Java EE en general) es más ligero y se adhiere más al principio de la convención sobre la configuración. Spring requiere más verbosidad para obtener las mismas cosas y depende mucho de los archivos XML que pueden volverse muy grandes y difíciles de manejar rápidamente. La otra cara de la moneda es que la primavera puede ser menos mágica y puede que te sientas más en control después de haber explicado todo lo que quieres.

Otro problema es la forma en que se desarrollan EJB y Spring.

EJB es gratis (como en la cerveza gratis), de código abierto y no propietario. Hay implementaciones de EJB realizadas por organizaciones sin fines de lucro (Apache), compañías de código abierto (Redhat / JBoss) y empresas de código cerrado (IBM) profundamente comerciales. Personalmente evitaría esto último, pero a cada uno lo suyo.

La primavera, por otro lado, es gratuita y de código abierto, pero muy patentada. Solo hay una compañía que hace Spring y esa es Springsource. Si no estás de acuerdo con Rod, entonces mala suerte para ti. Esto no es necesariamente algo malo, pero es una diferencia de la que deberías estar consciente.

¿Hacer todo @Annotation siempre es bueno? ¿Configuración nunca necesaria?

Realmente es un debate interminable. Algunos argumentan que XML es difícil de mantener, otros argumentan que las anotaciones contaminan un modelo POJO de otro modo puro.

Creo que anotar un bean como ser un bean sin estado EJB (@Stateless) o una entidad JPA (@Entity) se hace de forma más limpia utilizando anotaciones. Lo mismo ocurre con las inyecciones de dependencia @EJB o @Inject. Por otro lado, prefiero que las consultas con nombre de JPQL estén en archivos XML en lugar de anotaciones, y las inyecciones que representan datos de configuración pura (como un valor máximo para algo) también estén en XML.

En Java EE, cada anotación también se puede especificar en XML. Si tanto la anotación como el equivalente de XML están presentes, el XML anula la anotación. Esto hace que sea realmente conveniente comenzar con una anotación para el caso predeterminado, pero anularlo más adelante a través de XML para un caso de uso específico.

La preferencia actual en Java EE parece ser más hacia anotaciones (simples) combinadas con una gran cantidad de convenciones sobre configuración.