¿Qué es realmente Enterprise Java Bean?

Question

En las preguntas frecuentes de Tomcat dice: "Tomcat no es un servidor EJB. Tomcat no es un servidor J2EE completo".

Pero si yo:

• uso de Primavera para suministrar un contexto de aplicación
• anotar mis entidades con las APP anotaciones (y el uso de Hibernate como proveedor APP)
• C3P0 configure como una agrupación de conexiones datos fuente
• anotar mis métodos de servicio con @Transactional (y utilizar Atomikos como proveedor JTA)
• Uso JAXB para la clasificación y el unmarshalling
• y posiblemente añadir mi propia capacidad JNDI

Entonces no tengo efectivamente un servidor de aplicaciones Java EE? Y entonces, ¿no son mis ejotes EJB? ¿O hay alguna otra característica definitoria?

¿Qué es lo que un servidor de aplicaciones compatible con Java EE le ofrece que no puede obtener fácilmente/fácilmente de Tomcat con algunos subsistemas de terceros?

Answer 1

Pero si añadir (...) entonces no tengo que efectivamente un servidor de aplicaciones Java EE? Y entonces, ¿no son mis ejotes EJB? ¿O hay alguna otra característica definitoria?

No, no tiene un servidor de aplicaciones Java EE, un servidor de aplicaciones Java EE completo es más que Tomcat + Spring + un administrador de transacciones independiente. E incluso si agrega un proveedor JMS y un contenedor EJB, aún no tendrá un servidor Java EE. El pegamento entre todas las partes es importante para IMO y es parte del valor agregado de un contenedor Java EE.

En cuanto a los EJB, la especificación EJB es mucho más que JPA y especifica también beans de sesión y beans controlados por mensajes (en realidad, realmente no considero entidades JPA como EJB incluso si JPA es parte de la especificación EJB 3.0 en Java EE 5 por razones históricas, lo que ya no es cierto en Java EE 6, JPA 2.0 y EJB 3.1 son especificaciones separadas). También debería mencionar que un bean Spring anotado con @Transactional no es equivalente a un Session Bean. Un contenedor Java EE puede hacer más cosas con Session Beans (ver a continuación). Puede que no los necesites, pero aún así, no son estrictamente equivalentes.

Por último, los contenedores Java EE implementan un estándar, el contenedor Spring no, es propietario.

¿Qué es lo que un servidor de aplicaciones compatible con Java EE le ofrece que no puede obtener fácilmente/fácilmente de Tomcat con algunos subsistemas de terceros?

Como dije, creo que el "pegamento" es una parte del valor agregado y contribuye en gran medida a la robustez del conjunto. Entonces, el answer de ewernli subrayó muy bien lo que es difícil de lograr.Yo sólo añadiría:

• agrupación y Fail-over (para lograr la tolerancia a fallos)
• instalaciones de la Administración

Sí, un buen servidor Java EE hará cosas con buena pinta a mejorar la tolerancia a fallas (clustering de pools de conexión, árbol JNDI, destinos JMS, reintento automático con beans idempotentes, clientes EJB inteligentes, recuperación de transacciones, migración de servicios, etc.). Para aplicaciones de "misión crítica", la gran mayoría no lo son, esto es importante. Y en tales casos, las bibliotecas en la parte superior de la API de Servlet son IMO no un reemplazo.

Answer 2

Una implementación EJB sería un bean escrito y empaquetado para ejecutarse en cualquier servidor EJB compatible. Si hace lo que describe, puede funcionar, pero no será portátil para el servidor de aplicaciones de otro proveedor.

Así que EJB es un estándar que se adhiere a una especificación específica y, por lo tanto, es portátil.

En la práctica, muchos EJB no son totalmente compatibles o el servidor de aplicaciones es neutral. Sin embargo, en general, sí, por lo que las pequeñas incompatibilidades serían mucho más fáciles de corregir si cambiara los proveedores del servidor de aplicaciones que intentar mover la arquitectura que describió a un servidor GlassFish, JBoss o Weblogic.

EDITAR: En respuesta a su comentario, no tendría un EJB adecuadamente anotado y/o configurado a través de XML de tal manera que el código que lo accedió en formas compatibles con EJB podría usarlo sin cambios.

Hay dos ángulos para su comentario. Una es, ¿qué funcionalidad perdería implementando en un JBoss o cualquiera de los otros en lugar de Tomcat? Probablemente no haya nada, si trajiste todos los marcos en los que confiabas. Sin embargo, si quiere mover su código a Weblogic, por ejemplo, para usar algunas de sus características, entonces su código necesitaría algunos cambios importantes para mantenerse al día.

No digo que no pueda replicar todas las funciones de EJB (ciertamente el subconjunto que le importa) por otros medios, solo que no es la especificación, y por lo tanto no es independiente de la implementación.

Answer 3

Los EJB son componentes de JavaEE que se ajustan a la API javax.ejb.

JavaEE es una colección de API, no necesita usarlas todas.

Tomcat es un servidor JavaEE "parcial", ya que solo implementa algunas de las API de JavaEE, como Servlets y JNDI. No implementa, p. EJB y JMS, por lo que no es una implementación completa de JavaEE.

Si agregaste algunos fragmentos y piezas adicionales (por ejemplo, OpenEJB, HornetQ), agregarías las partes faltantes, y terminarías con un servidor completo JavaEE. Pero fuera de la caja, Tomcat no es eso, y no trata de serlo.

Answer 4

1) Está confundiendo entidades JPA con EJB. Si bien JPA pertenece a la especificación EJB3, siempre fue una tecnología independiente.

2) Los EJB son: beans sin estado, beans con estado y beans controlados por mensajes. Si bien cada una de estas funcionalidades se puede lograr fácilmente usando la primavera, la primavera simplemente no utiliza esta terminología. En Spring, no tienes POJO + "magia" como en EJB, en Spring es POJO + tu propia configuración (que a veces también se siente como magia). La principal diferencia es que la primavera hace más y el servidor de aplicaciones hace menos, por lo que una aplicación de primavera está contenta con un tomcat, mientras que una aplicación ejb3 necesita un servidor de aplicaciones "real".

En mi opinión, el 90% de las aplicaciones se pueden implementar usando spring + tomcat, ejb3 raramente es necesario.

Answer 5

¿no tengo efectivamente un servidor de aplicaciones Java EE ? ¿Y entonces no son mis EJB de frijoles ? ¿O hay alguna otra característica de definición de ?

Respuesta rápida Los EJB en realidad tienen que seguir una especificación Java EE. Tomcat es un contenedor de Java EE, no un servidor de aplicaciones.

Qué es lo que una queja servidor Java EE aplicación le da cuenta que no puede facilidad/fácilmente obtener de Tomcat con algunos subsistemas de 3 ª parte?

Respuesta rápida a su segunda pregunta. En tu caso, probablemente nada.

Los EJB tienden a ser objetos muy pesados ​​y las personas terminan usándolos para resolver problemas cuando eran esencialmente exagerados. Frameworks como Spring se crearon para resolver esos problemas sin usar EJB. Creo que el primer libro donde se introdujo Spring fue llamado "desarrollo J2EE sin EJB".

Answer 6

Fuera de la estricta definición de lo que es y no es un EJB, está agregando muchas cosas a Tomcat. Incluso si lo que tienes es un servidor EJB, ya no es realmente simple Tomcat.

La pregunta frecuente es correcta: Tomcat no es un servidor EJB. Sin embargo, puede ser eso o muchas otras cosas si acumula suficientes bibliotecas y códigos adicionales.

Answer 7

De hecho, si se pone suficiente esfuerzo casi se puede convertir Tomcat/primavera en un servidor de aplicaciones de peso pesado en toda regla :) Usted podría incluso incrustar un contenedor EJB3 portátil ...

Qué es lo que una La aplicación compatible con Java EE servidor le ofrece que no puede obtener fácilmente/fácilmente de Tomcat con algunos subsistemas de terceros?

Todavía hay algunas características que son difíciles de obtener con módulos de 3 ª parte:

• beans de sesión con estado (SFSB)
• contexto de persistencia extendido
contenedor de cliente
• application/java Web Start
• clústeres según la aplicación. servidor
• interoperabilidad CORBA
integración
• JCA ~
• interacción remota ~
• transacciones gestionadas por contenedor ~
• gestión decente de transacciones distribuidas (por ejemplo recuperar tx heurístico)

entradas con ~ son también apoyado por Spring, pero no tan trivialmente, al menos según mi mejor conocimiento.

Algunos detalles más en esta respuesta: EJB vs Spring