Visión general del empaquetado de módulos EJB 3.x
Este tema describe el empaquetado de aplicaciones cuando se utilizan beans EJB (Enterprise JavaBeans) 3.x.
El empaquetado de aplicaciones que utilizan beans EJB 3.x es similar a los requisitos de ensamblaje para aplicaciones Java™ EE (Java Platform, Enterprise Edition) 1.4: los componentes se empaquetan en módulos y los módulos se empaquetan en archivos EAR (Enterprise Archive - archivador empresarial) de aplicación. En un descriptor de despliegue XML (Extensible Markup Language) se proporciona a los componentes y los módulos metadatos descriptivos. Las especificaciones EJB 3.x dan soporte a un método adicional para describir metadatos y empaquetar unidades de persistencia.
- Archivos JAR (Java Application Archive) para módulos EJB. Módulos de clase de programa de utilidad y módulos de cliente de aplicaciones Java EE.
- Archivos WAR (Web Application Archive) para módulos web o contenido EJB. El archivo WAR debe ser de la versión 2.5 o superior para contener contenido de EJB.
- Otros módulos específicos de tecnología como por ejemplo archivos RAR (Resource Application Archive) y otros tipos de módulos.
Módulos EJB sin descriptores de despliegue
Puede empaquetar módulos EJB sin un descriptor de despliegue si utiliza beans EJB 3.x. Para hacer esto, debe crear un archivo JAR o el archivo WAR con metadatos en una anotación que se encuentra en el componente EJB. Los beans EJB 3.x no necesitan una entrada en el archivo ejb-jar.xml para metadatos que ha definido mediante anotaciones.
Con EJB 3.0, el valor predeterminado consiste en explorar las anotaciones durante la instalación de un módulo EJB 3.0. Para WebSphere Application Server, Versión 9.0, el valor predeterminado no es explorar módulos anteriores a Java EE 5 durante la instalación de la aplicación o al arrancar el servidor.
Para conservar la compatibilidad con versiones anteriores con el paquete de características para EJB 3.0 y el paquete de características para servicios web, tiene la opción de explorar o no los módulos web heredados para obtener metadatos adicionales. Se define un conmutador de nivel de servicio para el comportamiento de exploración de cada paquete de características. Si el valor predeterminado no es el correcto, el conmutador debe establecerse en cada servidor y servidor administrativo que necesite un cambio en el valor predeterminado. Los conmutadores son las propiedades personalizadas del servidor com.ibm.websphere.webservices.UseWSFEP61ScanPolicy={true|false} y com.ibm.websphere.ejb.UseEJB61FEPScanPolicy={true|false}. Para definir estas propiedades en la consola administrativa, pulse
.Módulos EJB con descriptores de despliegue
Puede continuar utilizando módulos EJB con descriptores de despliegue. Los módulos con descriptores de despliegue pueden dar soporte a cualquier nivel de versión de especificación EJB, incluyendo EJB 3.x, pero normalmente estos descriptores deben reflejar los requisitos de implementación de los componentes en el módulo.
Un módulo EJB puede tener un descriptor de despliegue EJB 3.x, 2.x o 1.x.
Para los descriptores de despliegue 2.x o 1.x, se presupone que el descriptor de despliegue contiene todos los metadatos para el módulo y no se produce ninguna exploración adicional de datos de anotación.
La exploración de anotaciones de contenedor de EJBse realiza en módulos EJB que no tienen ningún descriptor de despliegue o que tienen un descriptor de despliegue ejb-jar.xml en el nivel de esquema de EJB 3.0 con el atributo XML metadata-complete establecido en false u omitido. Consulte la sección sobre el comportamiento de la exploración de anotaciones para ver el conjunto completo de normas utilizadas por el servidor para determinar si se realiza la exploración de anotaciones.
Comportamiento de exploración de anotaciones
El servidor puede inspeccionar los archivos de clase en el módulo de contenido de anotaciones. El servidor busca contenido de anotaciones que pueda definir un componente, una referencia a un recurso o un comportamiento concreto. Por ejemplo, se pueden utilizar anotaciones para definir un componente EJB o para declarar una referencia a un origen de datos que un componente EJB debe utilizar, o para declarar los atributos transaccionales o de seguridad asociados con un método de EJB. Este proceso de inspección se conoce como exploración de anotaciones. Si los archivos de clase del módulo contienen anotaciones que deben ser respetadas por el servidor, el servidor debe estar configurado de modo que se produzca la exploración de anotaciones. Si los archivos de clase del módulo no contienen anotaciones, entonces puede configurar el servidor, por motivos de rendimiento, de forma que la exploración de anotaciones no se produzca.
- Si existe el archivo de descriptor de despliegue ejb-jar.xml
- Versión del descriptor de despliegue ejb-jar.xml, si existe
- El valor de configuración metadata-complete en el descriptor de despliegue ejb-jar.xml, si existe
- Versión del descriptor de despliegue web.xml, cuando el contenido EJB se empaqueta en un módulo WAR, y el descriptor de despliegue ejb-jar.xml no existe
- El valor de configuración metadata-complete en el descriptor de despliegue web.xml, cuando el contenido EJB se empaqueta en un módulo WAR y el descriptor de despliegue ejb-jar.xml no existe
Las tablas siguientes indican cómo se toma la decisión de explorar, o no explorar, anotaciones para contenido EJB empaquetado en un módulo WAR o en un módulo JAR EJB.
ejb-jar.xml | Valor de metadata-complete en ejb-jar.xml | ¿Se exploran las anotaciones? |
---|---|---|
Existe, con una versión de 2.x o inferior | NA | No |
Existe, con una versión de 3.x o inferior | true | No |
Existe, con una versión de 3.x o inferior | false (o se omite) | Sí |
No existe | NA | Sí |
Archivo ejb-jar.xml | Valor de metadata-complete en ejb-jar.xml | Archivo web.xml | Valor de metadata-complete en web.xml | ¿Se exploran las anotaciones? |
---|---|---|---|---|
Existe, con una versión de 3.x o inferior | true | NA | NA | No |
Existe, con una versión de 3.x o inferior | false (o se omite) | NA | NA | Sí |
Existe, con una versión de 2.x o inferior | NA | NA | NA | No |
No existe | NA | Existe, con una versión de 2.5 o posterior | true | No |
No existe | NA | Existe, con una versión de 2.5 o posterior | false (o se omite) | Sí |
No existe | NA | Existe, con una versión de 2.4 o inferior | NA | No |
No existe | NA | No existe | NA | Sí |
Es importante entender la diferencia entre el atributo metadata-complete del elemento ejb-jar del descriptor de despliegue ejb-jar.xml y el valor de instalación metadata-complete que se puede especificar durante el proceso de instalación de la aplicación o el módulo.
El atributo metadata-complete del elemento ejb-jar del archivo ejb-jar.xml es un atributo XML. Lo utiliza el servidor para determinar si deben explorarse las clases para los datos de anotaciones, como se acaba de definir mediante las reglas de las tablas Exploración de anotaciones para contenido EJB.
En cambio, el servidor utiliza el valor metadata-complete que se puede especificar en el momento de la instalación para ayudar a generar el archivo ejb-jar.xml. Si no hay ningún archivo ejb-jar.xml en el módulo y se asigna al valor de instalación metadata-complete el valor true, el servidor explorará el contenido de las anotaciones y lo utilizará para generar un archivo ejb-jar.xml y, a continuación, establecerá el atributo XML metadata-complete de ese archivo en un valor de true.
Unidades de persistencia
Las unidades de persistencia, incluyendo el archivo persistence.xml y las clases asociadas con el mismo, se pueden empaquetar en el módulo para el que son necesarias. También se pueden empaquetar en un archivo JAR de programa de utilidad aparte empaquetado en el archivo EAR con su módulo dependiente.
Empaquetado de aplicaciones
Puede combinar beans EJB 2.x y anteriores con beans EJB 3.x en la misma aplicación. No obstante, los beans EJB 3.x no se reconocen en los módulos EJB 2.x o EJB 1.x.
- Se presupone que el nombre de aplicación es el nombre del archivo EAR, pero eliminando la extensión del archivo EAR.
- Los archivos que acaban en .war se supone que son módulos web. La raíz de contexto del módulo web es el nombre del archivo relativo a la raíz del paquete de aplicaciones, pero sin la extensión de archivo WAR.
- Los archivos que acaban en .jar que no están en el directorio /lib y que contienen un archivo ejb-jar.xml o al menos una clase que define una anotación @Stateful, @Stateless, @Singleton o @MessageDriven, se supone que son módulos EJB.
- No se presupone que otros archivos JAR que no están en el directorio /lib son módulos EJB.
Empaquetado JPA
Se recomienda que las unidades de persistencia se empaqueten en archivos JAR separados para hacerlas más accesibles y reutilizables. Estas se pueden probar fuera del contenedor, se produzca o no la persistencia real de la base de datos. Las unidades de persistencia se pueden incluir en aplicaciones autónomas o en archivos EAR como archivos JAR de programa de utilidad. Debido a la variedad de casos de uso y problemas de rendimiento que se podrían producir al explorar cantidades grandes de clases, se recomienda que las unidades de persistencia definan las clases de las unidades de persistencia.
Fachadas de sesión utilizadas para el escenario de persistencia
Un patrón común es utilizar fachadas de sesión para la persistencia. Se da soporte a la utilización de fachadas de bean de sesión para controlar JPA. La interfaz EntityManager no tiene seguridad de hebras y, por lo tanto, los servlets no deben inyectar nunca @PersistenceContext. Los servlets deben utilizar el patrón de fechada o bien utilizar una instancia de EntityManagerFactory para crear un EntityManager en cada solicitud.
Se recomienda que las unidades de persistencia JPA se definan en un archivo JAR aparte, separado de las fachadas de bean de sesión. No solamente este es el procedimiento recomendado que proporciona mayor flexibilidad en la compartición, sino que también evita problemas al mezclar clases anotadas JPA y no JPA.
Normalmente, un archivo JAR se crea para mantener las clases de entidad y la definición persistence.xml de JPA y se añade el archivo EAR como archivo JAR de programa de utilidad. El módulo EJB 3.x añade una dependencia del archivo JAR declarándola en el módulo EJB 3.x MANIFEST.MF. Por ejemplo, si un EAR contiene un archivo TradeApp.ear, TradeWeb.war, EJB3Trade.jar y TradeInfo.jar, el archivo EJB3Trade.jar tendrá un MANIFEST.MF con el aspecto siguiente:
Manifest-Version: 1.0
Class-Path: TradeInfo.jar
La fachada de sesión del archivo EJB3Trade.jar hace referencia a las clases de entidad JPA y las unidades de persistencia del archivo TradeInfo.jar. La aplicación web definida en el archivo TradeWeb.war puede realizar el mismo trabajo con los objetos de entidad JPA que los Objetos de transferencia de datos que fluyen entre las capas de web y de contenedores EJB.
Escenario de referencias de beans de sesión entre niveles y entre versiones
Existen varias formas de definir y utilizar referencias a los beans de sesión EJB 3.x. En el caso de ser de una sesión EJB 3.x a otra sesión EJB 3.x, se puede utilizar la inyección @EJB. En el caso de ser entre niveles, por ejemplo, de aplicación web a sesión EJB 3.x, o entre versiones, por ejemplo, de una sesión EJB 2.1 a una sesión EJB 3.x, se puede utilizar una referencia de descriptor de despliegue XML para definir ejb-refs y ejb-local-refs. Existen dos variaciones de estos, en función de si se hace referencia a una interfaz de empresa EJB 3.x o a una interfaz de estilo de componente anterior a EJB 3.x que también define un EJBLocalHome. Las aplicaciones web y las aplicaciones cliente también pueden utilizar la anotación de @EJB si el componente al que se hace referencia se puede resolver utilizando autolink.
El escenario anterior utiliza un patrón de cliente de estilo EJB 2.1 con una implementación de bean de sesión de estilo EJB 3.x. Para obtener un estilo de cliente más actual, se puede limpiar la parte del cliente para buscar directamente la interfaz de empresa del bean de sesión, en lugar de ir a través de la interfaz de inicio. En este caso, no es necesario definir la anotación @LocalHome(<localhome>.class). Para hacer esto, puede utilizar una definición de variante de ejb-ref y ejb-local-ref. Utilice un valor nulo para el valor del elemento local-home y enlace el ejb-local-ref con el enlace ejblocal: del bean de sesión en lugar de hacerlo con el enlace de inicio. Por ejemplo:
<ejb-local-ref id="EJBLocalRef_1154112538064">
<description>com.ibm.persistence.ejb3.order.facadecom.ibm.persistence.ejb3.order.facade</description>
<ejb-ref-name>ejb/OrderEJB</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local-home></local-home>
<local>com.ibm.persistence.ejb3.order.facade.OrderProcessor</local>
</ejb-local-ref>
También se debe ajustar el código de cliente para realizar la conversión adecuada para el objeto que se está buscando. En este caso, la interfaz de empresa en lugar de la interfaz de inicio:
try {
InitialContext ctx = new InitialContext();
orderProcessor = (OrderProcessor)ctx.lookup("java:comp/env/ejb/OrderEJB");
}
catch(Exception e){
e.printStackTrace(System.out);
throw new ServletException(e);
}