Contenido EJB en módulos WAR

Utilice este tema para conocer los requisitos de empaquetado del contenido EJB (Enterprise JavaBeans) en los módulos de archivado de aplicación web (WAR).

Contenido EJB soportado

Salvo para las restricciones indicadas explícitamente, la función de EJB que está soportada para los beans empaquetados en módulos JAR (Java™ Archive) de EJB también está soportada para los beans empaquetados en módulos WAR. Un bean empaquetado en un módulo WAR puede tener el mismo comportamiento que un bean empaquetado en un módulo JAR de EJB.

Todos los tipos de beans EJB 3.x están soportados en los módulos WAR, así como los beans de sesión de las versiones 2.x y 1.x. Consulte la especificación EJB 3.1 para obtener todos los detalles.

Mecanismos de empaquetado

Las reglas para empaquetar contenido EJB en un módulo WAR son distintas de las reglas para empaquetar contenido EJB en un módulo JAR.

Los archivos de clase de bean deben colocarse en una de las dos ubicaciones en el módulo WAR:
  • Libremente en la estructura de directorios WEB-INF/classes
  • En un archivo JAR que esté colocado en el directorio WEB-INF/lib

Por ejemplo, puede colocar libremente la clase de bean com.foo.MyBean en el módulo WAR en esta ubicación: WEB-INF/classes/com/foo/MyBean.class.

También puede colocar esta clase de bean en el archivo myJar.jar, que se encuentra en esta ubicación: WEB-INF/lib/myJar.jar.

Un módulo WAR puede tener algunos códigos bean colocados libremente en la estructura de directorios WEB-inf/classes y tienen otro código bean dentro de archivos JAR en el directorio WEB-inf/lib . También es válido para un módulo WAR tener todos los códigos bean en la estructura de directorios WEB-INF/classes y nada en el directorio WEB-INF/lib y todo el código bean en archivos JAR del directorio WEB-INF/lib y nada en WEB-INF/classes.

Es válido tener múltiples archivos JAR en el directorio WEB-INF/lib, pudiendo contener todos código bean.

Si la misma clase de bean se coloca libremente en la estructura de directorios WEB-INF/classes y también se coloca en un archivo JAR en el directorio WEB-INF/lib, se cargará la instancia de la clase colocada libremente en la estructura de directorios WEB-INF/classes y se hará caso omiso de la instancia colocada en un archivo JAR del directorio WEB-INF/lib.

Si la misma clase de bean se coloca en dos archivos JAR diferentes en el directorio WEB-INF/lib, no se sabrá qué instancia de clase se cargará y que instancia se pasará por alto. En el tiempo de ejecución, el servidor toma de forma arbitraria una instancia de clase y la carga pasando por alto la otra instancia de clase.

Los archivos del descriptor de despliegue EJB deben colocarse en el directorio WEB-INF. Este directorio contiene el descriptor de despliegue ejb-jar.xml, así como los archivos de extensiones y enlaces XMI o XML ibm-ejb-jar-ext y ibm-ejb-jar-bnd. Los archivos del descriptor de EJB que se encuentran en archivos JAR del directorio WEB-INF/lib se omiten. Al igual que con un módulo JAR de EJB, es posible que haya entre 0 y 1 instancia de cada archivo del descriptor de EJB. No puede haber varias instancias de todos los archivos del descriptor de EJB. Esto no incluye el archivo persistence.xml, si lo hay. Según la especificación Java Persistence API, si hay un archivo persistence.xml, debe permanecer en un directorio META-INF ubicado en el directorio WEB-INF/classes del módulo WAR o en un archivo JAR del directorio WEB-INF/lib del módulo WAR. Por ejemplo:
  • WEB-INF/classes/META-INF/persistence.xml
  • WEB-INF/lib/MyEntity.jar
El archivo MyEntity.jar contiene META-INF/persistence.xml.
Si hay un archivo ejb-jar.xml en un archivo JAR del directorio WEB-INF/lib, se muestra un mensaje de aviso parecido al siguiente: Por ejemplo:
IWAE0068W Se hace caso omiso del descriptor de despliegue EJB META-INF/ejb-jar.xml del archivo de bibliotecas foo.jar. El producto no procesa el descriptor de despliegue META-INF/ejb-jar.xml en los archivos de biblioteca. Mueva el descriptor de despliegue META-INF/ejb-jar.xml del archivo de bibliotecas al directorio WEB-INF del módulo WAR.

Un módulo WAR debe ser de la versión 2.5 o superior para que pueda contener contenido EJB. Se ignora el contenido EJB colocado en un módulo WAR que es de la versión 2.4 o inferior.

Avoid trouble Avoid trouble: Si un módulo WAR tiene una versión 2.5 o superior, los archivos de metadatos web que contienen información de enlaces y extensiones deben utilizar la versión XML de los archivos, no la versión XMI. gotcha

Diferencias técnicas para los enterprise beans que se empaquetan en un archivo WAR

La lista siguiente contiene las diferencias técnicas clave que existen entre los beans que se empaquetan en un módulo WAR y los beans que se empaquetan en un módulo JAR EJB:

  • Espacio de nombres de componente compartido

    Todos los componentes de un módulo WAR comparten un espacio de nombres de componentes único. Esto significa que cada componente EJB comparte un espacio de nombres de componentes único con los demás componentes EJB del archivo WAR y los componentes que no son EJB como los servlets. En cambio, un componente EJB que se empaqueta en un módulo JAR EJB tiene su propio espacio de nombres de componentes privado, que no se comparte con ningún otro componente.

    El espacio de nombres de componentes compartidos tiene impactos importantes. En primer lugar, un componente (EJB o no EJB) puede declarar una referencia y un componente diferente puede buscar dicha referencia en el espacio de nombres del componente. Segundo, las referencias declaradas por un componente pueden entrar en conflicto con las referencias declaradas por otro componente. En cambio, un EJB empaquetado en un módulo JAR EJB no puede buscar en el espacio de nombres del componente una referencia declarada por un EJB diferente o un componentes no EJB y es imposible que una referencia declarada por el EJB entre en conflicto con el espacio de nombres del componente que tiene una referencia declarada por algún otro componente, aunque las referencias tengan el mismo nombre.

    Cuando se utiliza el espacio de nombres compartido, es válido para declarar la misma referencia varias veces, siempre que estas declaraciones de referencia no entren en conflicto entre sí. Si las declaraciones de referencia no entran en conflicto, el servidor se comporta como si la referencia se hubiera declarado exactamente una vez.

    Si las declaraciones de referencia no entran en conflicto, se emitirá un mensaje de error y la aplicación no se podrá iniciar. Se emitirá un mensaje de aviso para cada referencia que entre en conflicto. El mensaje de aviso indica el nombre de la referencia en conflicto y los distintos valores asignados a dicha referencia. Después de emitir todos los mensajes de aviso, se generará una excepción.

  • Ubicación de los archivos del descriptor de EJB

    El archivo del descriptor de despliegue ejb-jar.xml, así como cualquier otro archivo descriptor, se deberán colocar en el directorio WEB-INF de WAR. Se hará caso omiso de cualquier instancia de un archivo del descriptor de EJB en WAR, incluido el directorio META-INF de un archivo JAR del directorio WEB-INF/lib.

  • Determinación de si se exploran las anotaciones

    Las reglas para determinar si se exploran las anotaciones son diferentes para los JAR EJB y los módulos WAR. Consulte el tema de visión general del empaquetado de módulos EJB 3.x si desea el conjunto completo de reglas.

  • Carga de clases y visibilidad

    El patrón de uso más común para las clases EJB que se empaquetan en un módulo WAR son las invocaciones de método local desde los componentes web empaquetados en el mismo módulo. No obstante, también se puede acceder a estas clases EJB mediante las invocaciones de método remoto o desde los clientes en otros módulos. En estos casos, es importante comprender las reglas de visibilidad de las clases EJB que se empaquetan en un módulo WAR. Las reglas de visibilidad son diferentes cuando se comparan con las clases EJB que se empaquetan en un módulo JAR.

    En el caso de las invocaciones de método EJB remoto, no se introducen diferencias de visibilidad cuando se empaquetan las clases EJB en un módulo WAR. Los EJB están enlazados con el espacio de nombres global y se pueden realizar búsquedas en ellos desde los componentes de otros módulos o se pueden inyectar en ellos. El cliente remoto debe realizar invocaciones de método con la clase de apéndice adecuada. La generación de clases de apéndice se describe en este tema en la sección "Generación de apéndices".

    En el caso de las invocaciones de método EJB local desde los componentes de otros módulos, existen diferencias de visibilidad porque los EJB se empaquetan en un módulo WAR. Estas diferencias de visibilidad se producen porque hay implicaciones del cargador de clases que deben tenerse en cuenta.

    El contenido que se empaqueta en todos los módulos JAR de EJB para la aplicación completa se carga mediante una instancia única del cargador de clases de aplicación.

    En cambio, todo el contenido que se empaqueta en un módulo WAR se carga en una instancia del cargador de clases que es específica para ese módulo WAR. La instancia única del cargador de clases de aplicación que se utiliza para cargar todo el contenido JAR de EJB es el padre de cada una de las instancias del cargador de clases que se utilizan para cargar el contenido WAR.

    La visibilidad de una clase se ve afectada por la instancia del cargador de clases que la ha cargado. Una instancia del cargador de clases puede ver clases cargadas por sí misma, o por un cargador de clases padre. Sin embargo, un cargador de clases no puede ver una clase cargada en un cargador de clases que no sea él mismo, ni uno de sus padres.

    Como resultado, las clases cargadas por un cargador de clases específico de un módulo WAR puede ver clases de un módulo JAR de EJB, pero no pueden ver clases de otro módulo WAR. Las clases de un módulo JAR de EJB no pueden ver clases de cualquier módulo WAR. Por ejemplo, si hay contenido EJB empaquetado en el módulo JAR de EJB ejb3.jar, y también hay contenido EJB empaquetado en el archivo ejb1.jar y en el archivo ejb2.jar:
    • Si el archivo ejb1.jar y el archivo ejb2.jar se instalan como módulos JAR de EJB, el contenido del archivo ejb1.jar, ejb2.jar y ejb3.jar se carga en la misma instancia del cargador de clases, que también se utiliza para cargar cualquier otros módulos JAR de EJB en la aplicación. En este caso, las clases de los tres archivos JAR puede verse entre sí, puesto que todos los carga la instancia del mismo cargador de clases.
    • Si el archivo ejb1.jar y el archivo ejb2.jar se empaquetan en el directorio WEB-INF/lib de un archivo WAR, el del archivo ejb1.jar y del archivo ejb2.jar se cargará mediante una instancia única del cargador de clases. No obstante, este cargador de clases no es el mismo que el que se utiliza para cargar el contenido del archivo ejb3.jar y cualquier otro archivo JAR de EJB en la aplicación. En este caso, las clases del archivo ejb1.jar y del archivo ejb2.jar pueden verse entre sí y también pueden ver las clases del archivo ejb3.jar. Las clases de del archivo ejb3.jar no pueden ver las clases del archivo ejb1.jar o del archivo ejb2.jar.
    • Si el archivo ejb1.jar se empaqueta en el directorio WEB-INF/lib del archivo firstWar.war, y el archivo ejb2.jar se empaqueta en el directorio WEB-INF/lib del archivo secondWar.war, el contenido del archivo ejb1.jar se cargará en una instancia del cargador de una clase, el contenido del archivo ejb2.jar se cargará en una instancia del cargador de segunda clase y el contenido del archivo ejb3.jar y todos los demás JAR de EJB de la aplicación se cargarán en una instancia del cargador de tercera clase. En este caso, las clases del archivo ejb1.jar y del archivo ejb2.jar no pueden verse entre sí, pero pueden ver las clases del archivo ejb3.jar. Las clases del archivo ejb3.jar no pueden ver las clases del archivo ejb1.jar ni del archivo ejb2.jar.
    Una estrategia para evitar estas complicaciones del cargador de clases es empaquetar las clases de interfaz EJB en una biblioteca compartida.
    Best practice Best practice: No empaquete la misma clase, un módulo JAR de EJB y un módulo WAR, en la misma aplicación. El empaquetado de la misma clase en múltiples ubicaciones dentro de la misma aplicación podría provocar una confusión sobre qué instancia de la clase se carga y se utiliza en el tiempo de ejecución. Esta distinción puede ser importante si los dos archivos .class representan diferentes versiones de la clase. Para evitar esta situación, empaquete el archivo .class en una sola ubicación, o cambie la estructura del paquete de la clase de modo que el nombre completo de la clase que se ha empaquetado en el módulo WAR es diferente del nombre completo de la clase que se ha empaquetado en el módulo JAR de EJB. bprac
  • Extensión de perfil de aplicación

    La extensión del perfil de aplicación no está soportada para las clases EJB que se empaquetan en los módulos WAR.

Generación de apéndices

El acceso remoto de métodos EJB requiere el uso de las clases de apéndice del lado cliente. Para la mayoría de los entornos de cliente, el tiempo de ejecución del producto genera automáticamente las clases de apéndice necesarias. Una excepción es el entorno del cliente ligero. Para los clientes ligeros, las clases de apéndice deben generarse manualmente y empaquetarse con el cliente.

Utilice la herramienta createEJBStubs para generar apéndices cuando el contenido EJB esté empaquetado en un módulo WAR, independientemente de la versión de EJB.

Consulte el tema, Mandato de creación de apéndices, para obtener más información.

Avoid trouble Avoid trouble: Cuando empaquete clases EJB 2.1 en un módulo WAR, no incluya las clases de apéndice generadas por la herramienta EJBDeploy. Estas clases de apéndice son distintas de las clases de apéndice generadas automáticamente por el tiempo de ejecución del producto y puede provocar errores. En la mayoría de los casos, las clases de apéndice generadas automáticamente son suficientes. La excepción se produce cuando un componente en el módulo web debe realizar una invocación de método remoto en una clase EJB 2.1 empaquetada en otro módulo JAR. En este caso, la clase de apéndice generada por EJBDeploy para el EJB en el otro módulo JAR debe empaquetarse en el módulo WAR. gotcha

Contenido EJB de la versión 2.x y 1.x en un módulo WAR

Excepto para los beans de entidad, el contenido de EJB de la versión 2.x y 1.x recibe soporte en un módulo WAR.

Un módulo 2.x o 1.x empaquetado en un archivo WAR requiere un descriptor de despliegue ejb-jar.xml en la versión 2.x o 1.x en el directorio WEB-INF del módulo WAR. Si existen enlaces XMI y archivos de extensión, también debe empaquetar estos enlaces y archivos en el directorio WEB-INF de un módulo WAR.

Los beans de sesión y beans controlados por mensajes que el usuario implementa de acuerdo con el estilo de codificación de la versión 2.x o 1.x se pueden empaquetar en un módulo WAR.

Tanto los beans de entidad de la persistencia gestionada por bean (BMP) como de la de persistencia gestionada por contenedor (CMP) no están soportados en un módulo WAR.

Los servicios de perfilado de aplicaciones e intento de acceso no están soportados en un módulo WAR. Los beans de sesión que se encuentran en un módulo WAR no pueden acceder a las tareas de perfilado de aplicaciones.

El contenido de EJB que se implemente de acuerdo con los estilos de codificación de la versión 3.x y así como de los estilos de codificación de la versión 2.x y 1.x se puede empaquetar conjuntamente en un módulo WAR único. Sin embargo, en este caso, debe declarar cualquier información de enlaces y extensiones con la versión XML de los archivos, no la versión XMI.

Traslado del contenido EJB existente de módulos JAR de EJB a módulos WAR

Un enfoque consiste en colocar el archivo JAR de EJB existente en el directorio WEB-INF/lib del archivo WAR. A continuación, elimine los archivos del descriptor del directorio META-INF del archivo JAR y colóquelos en el directorio WEB-INF del archivo WAR.

Un segundo planteamiento es colocar los archivos de clase del archivo JAR de EJB en la ubicación correcta en el directorio WEB-INF/classes del módulo WAR. A continuación, elimine los archivos de descriptor del directorio META-INF del archivo JAR y colóquelos en el directorio WEB-INF del archivo WAR.

Si varios módulos JAR de EJB se trasladan a un módulo WAR único, debe fusionar el contenido de cada uno de los archivos del descriptor que anteriormente se encontraban en los directorios META-INF de los módulos JAR de EJB en la versión única de los archivos del descriptor que ahora se colocan en el directorio WEB-INF del archivo WAR. Algunos ejemplos de archivos de descriptor que pueden fusionarse son, sin limitarse a ellos, ejb-jar.xml, ibm-ejb-jar-bnd, ibm-ejb-jar-ext e ibm-ejb-jar-ext-pme.

Debe inspeccionar las referencias declaradas por los diversos componentes en el módulo WAR, tanto los EJB y como los no EJB, para asegurarse de que no entren en conflicto entre sí, puesto que todo en el módulo WAR comparte un espacio de nombres de componente único.

Debe modificar los enlaces y los archivos XMI de extensión que se trasladan de un módulo JAR de EJB a un módulo WAR en varios lugares para eliminar las referencias a META-INF/ejb-jar.xml y sustitúyalos por WEB-INF/ejb-jar.xml.

Función de EJB que se admite en módulos JAR de EJB, pero no en los módulos WAR

La función de EJB siguiente no está soportada en los módulos WAR:
  • Los beans de entidad BMP y CMP
  • Los beans de arranque de estilos previos de EJB 3.1
    Atención: Los beans de arranque singleton definidos por EJB 3.1 están soportados.
Si un bean de entidad se coloca en un módulo WAR, aparecen mensajes de error y la aplicación no se inicia. Por ejemplo, el bean de entidad foo se coloca en el módulo foo.war de la aplicación FooApp. El resultado son los mensajes siguientes:
CWMDF0025E: Los beans de entidad en los módulos WAR (archivador de aplicación web) de EJB no están permitidos según la especificación EJB 3.1. 
WSVR0039E: No se ha podido iniciar el archivo JAR de EJB, foo.war: Los beans de entidad en los módulos WAR (archivador de aplicación web) de EJB no están permitidos según la especificación EJB 3.1. El bean foo en el módulo foo.war se debe trasladar a un módulo EJB autónomo. Examine el registro para ver una lista completa de los beans de entidad no válidos en un módulo WAR.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_ejbinwar
File name: cejb_ejbinwar.html