java-ee java-ee-6 ejb-3.1

java ee - Embalaje EJB en JavaEE 6 WAR vs EAR



java-ee java-ee-6 (5)

Comenzando un nuevo proyecto y me gustaría saber los pros y los contras de empaquetar EJB en un WAR vs EAR.

¿Funcionará JNDI cuando los EJB estén en WAR? ¿eficiencia? ¿etc.?

Gracias.

Actualmente estoy estudiando una guía para la certificación EJB 3.1 y tengo que probar cada característica de la misma. Y todos están disponibles cuando se usa una guerra.

Es muy diferente a EJB Lite del empaque WAR.

Puede tener algo de modularidad lógica utilizando jills ejb que puede incluir en su proyecto web. Pero todos los módulos comparten el mismo entorno (jndi) por lo que algunas colisiones de nombres podrían suceder. En un proyecto EAR, cada módulo tiene su propio espacio de nombres.

Creo que lo que debes tener en cuenta es que EJB dentro de WAR es parte de EJB Lite, lo cual es un buen esfuerzo para hacer que una aplicación se ejecute con los servicios mínimos proporcionados por un contenedor EJB. Porque no siempre necesita todos los servicios proporcionados por un contenedor EJB.

Entonces, si se pregunta acerca de los pros y los contras de empaquetar EJB en un WAR o en un EAR, entonces debe pensar en la cantidad de servicios que necesita.

HTH.

Hasta ahora esto es lo que obtuve.

EJB en WAR

pros:

  1. Más simple de desarrollar e implementar

  2. Puede exponer los métodos Session Bean como servicio REST con la anotación @Path. Mira here

contras:

  1. La búsqueda JNDI no es compatible, por lo que creo que no puede hacer RMI desde otra aplicación cliente

  2. Como arjan señaló que carece de modularidad en el diseño.

Hice un experimento sobre este tema y realmente me sorprendió el resultado. Mi conclusión nunca fue usar EJB en WAR. Dejemos el trabajo para el contenedor EJB, así que si alguien quiere obtener el mejor desarrollo sin errores, use EAR.

Cuando trabajé EJB en WAR utilizando NetBeans 7.1.3, Glassfish 3.1.2.2 y JRebel para un desarrollo más rápido, me di cuenta de que JRebel solo funcionaba perfectamente con los cambios de recarga realizados en el módulo EJB si se implementaba en un paquete EAR. Si hice un paquete WAR simple, el cargador de clases se comportó de una manera absolutamente extraña durante la fase de desarrollo y causó una gran cantidad de errores al azar.

De todos modos, el paquete de guerra en despliegue normal funcionó perfecto como mentiod por otros.

También en un paquete WAR, los cambios en las cadenas NamedQuery no aparecieron después de guardar y compilar. Si empaqué en EAR, el desarrollo fue fluido y rápido. Por supuesto, esto también podría ser un error en JRebel.

Una motivación importante para tener beans EJB en un JAR separado es la antigua separación entre la lógica de negocios y la lógica de visualización .

Como se supone que los EJB se concentran exclusivamente en la lógica de negocios, tiene sentido colocarlos en un módulo aparte.

Esto es exactamente lo que facilita el Java Enterprise Archive tradicional. Los beans EJB van a un archivo JAR que representa el EJB module , mientras que los artefactos relacionados con la web (facelets, backing beans, código de utilidad) van a un archivo de Web Archive (WAR) que representa el Web module . Tenga en cuenta que un WAR no tiene que ser un archivo. En el llamado formato de explosión, son meramente directorios.

Un aspecto clave de esta separación es que esos dos módulos están aislados a través de una jerarquía de cargador de clases. El Web module tiene acceso a los recursos (típicamente beans) del EJB module , y el EJB module puede hacer referencia a los recursos (típicamente bibliotecas) definidos en el paraguas general EAR. La otra dirección no es posible. Específicamente, el EJB module no puede acceder a ningún recurso definido en el Web module .

Esta aplicación es deliberada.

La lógica empresarial debe ser completamente independiente de cualquier tecnología de visualización . La aplicación de este aislamiento evita que los desarrolladores accidentalmente o cuando están bajo presión mezclen esas preocupaciones de todos modos. Los beneficios de esta separación es que la lógica de negocios puede ser utilizada trivialmente por otros clientes Java SE, clientes de módulos web, clientes JAX-RS, etc. Si la lógica de negocios tuviera accidentalmente dependencias JSF o Servlet, sería muy difícil usarla de los clientes de Java SE.

Compare esto con Facelets que no permite el uso de scriptlets. Esto mantiene las Facelets limpias y les permite enfocarse exclusivamente en el diseño y marcado de los componentes. Otra analogía es con la codificación de interfaces, que separa el contrato de la implementación.

Por lo tanto, tener un módulo EJB separado es en realidad una mejor práctica . Sin embargo...

Para proyectos más pequeños, puede que no sea necesario tener esta separación, y para los programadores principiantes puede ser difícil comprender la estructura de lo que debe ir a donde. Al eliminar la separación obligatoria, por lo tanto, es más fácil para los desarrolladores sin experiencia comenzar con Java EE. Les da una introducción suave a Java EE y más tarde una vez que tienen la idea de aplicar capas, pueden optar por introducir un EJB module todos modos.