Iniciando un nuevo proyecto y me gustaría saber los pros y los contras de empaquetar EJB en un WAR vs EAR.Embalaje EJB en JavaEE 6 WAR vs EAR
¿Funcionará JNDI cuando los EJB estén en WAR? ¿eficiencia? ¿etc.?
Gracias.
Una motivación importante para tener beans EJB en un frasco separado es para la vejez separación de la lógica de negocio y vista lógica.
Dado que se supone que los EJB se concentran exclusivamente en la lógica comercial, 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 son aislados a través de una jerarquía del cargador de clases. El Web module tiene acceso a los recursos (normalmente frijoles) del EJB module, y el EJB module puede referenciar los recursos (generalmente 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 envolver sus cabezas alrededor de la estructura de lo que necesita 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 obtienen la idea de capas, pueden optar por introducir un EJB module de todos modos.
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 funcione con los servicios mínimos proporcionados por un contenedor EJB. Porque no siempre necesita todos los servicios proporcionados por un contenedor EJB.
Por lo tanto, si se pregunta sobre 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.
Eso es lo que quería saber, todos los servicios que están disponibles cuando los EJB están empaquetados en un EAR (por separado en su propio jar EJB) todavía están disponibles cuando los EJB están empaquetados en un WAR. Hasta ahora sé que no puedes hacer la búsqueda JNDI. – duvo
Hasta ahora esto es lo que obtuve.
EJB en WAR
pros:
Más fácil de desarrollar y desplegar
puede exponer métodos Bean de sesión como servicio REST con @Path anotación. Ver here
contras:
búsqueda JNDI no es compatible, así que creo que no se puede hacer RMI desde otro cliente de la aplicación
Como arjan señaló que carece de la modularidad en el diseño.
Aunque la especificación no requiere que los EJB en WAR se hagan de forma remota, tanto JBoss7 como WebLogic12c le permiten acceder a ellos desde un cliente Java independiente. Entonces, la búsqueda JNDI y la invocación funcionan desde un cliente remoto. – Raylite3
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 el paquete EJB Lite de WAR.
Puede tener un poco 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.
Hice algunos experimentos 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 usando 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 funciona perfecto con los cambios de recarga realizados en el módulo EJB si se implementó 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 el despliegue normal funcionó perfectamente 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.
Entonces, ¿puedo usar ** todas las ** tecnologías Java EE en una aplicación empaquetada en un archivo WAR? –
@MartinAndersson casi todos ellos de hecho. Algunas cosas exóticas todavía tienen que implementarse por sí solas o como parte de un EAR, como un contenedor de aplicaciones de cliente o (un poco menos exótico) un adaptador de recursos JCA. Pero todas las cosas "normales", como CDI, EJB, JPA, JMS, JASPIC, etc. pueden empaquetarse en un archivo WAR. –
puede tener separación y aún poner jar ejb en web inf/lib ¿correcto? –