Un módulo Enterprise JavaBeans (EJB)
se utiliza para ensamblar uno o más enterprise beans en una sola unidad desplegable. Un módulo EJB se almacena en un archivo JAR (Java™ archive) estándar.
Un módulo EJB consta de lo siguiente:
- Uno o más enterprise beans desplegables.
- Un descriptor de despliegue, almacenado en un archivo XML (Extensible Markup Language). Este archivo declara el contenido del módulo, define la estructura y las
dependencias externas de los beans del módulo, y describe cómo se tienen que
utilizar los módulos durante su ejecución.
No es necesario utilizar descriptores de despliegue XML en los módulos EJB 3.x, aunque se dé soporte a los descriptores XML. En lugar de proporcionar descriptores de despliegue, puede utilizar anotaciones
para proporcionar metadatos del componente.
Puede desplegar un módulo EJB como una aplicación autónoma, o combinarlo con otros
módulos EJB o con módulos web para crear una aplicación Java. Un
módulo EJB se instala y se ejecuta en un contenedor de enterprise bean.
Si desea empaquetar un módulo EJB 3.x con un descriptor de despliegue, existen distintas formas
de hacerlo. Puede empaquetar un módulo EJB 3.x con una sesión y/o beans controlados por mensajes
exclusivamente de estilo EJB 3.x; con una sesión y/o beans controlados por mensajes
exclusivamente de estilo EJB 2.1, o una combinación de beans de estilo 2.1 y
3.x. El descriptor de despliegue XML debe ser un descriptor de despliegue de la
versión 3.x. Es necesario que los beans de entidad 2.1 se empaqueten en módulos con
descriptores de despliegue 2.1.
Los módulos EJB que contienen beans EJB 3.x deben estar en el nivel de especificación EJB 3.x al ejecutarse en el producto. Para establecer el módulo EJB
para que proporcione soporte a beans EJB 3.x, puede establecer el nivel del descriptor de
despliegue ejb-jar.xml en 3.0 o 3.1, o puede asegurarse de que el módulo no contenga un
descriptor de despliegue ejb-jar.xml. Si el nivel del módulo es EJB 2.1 o anterior,
ninguna función de EJB 3.x, incluyendo la exploración de anotaciones o la inyección de
recursos, se realizará durante el tiempo de ejecución.
Para obtener más información sobre el empaquetado y despliegue de beans EJB 3.x,
consulte el tema Visión general del empaquetado de módulos EJB 3.x.
Vistas de clientes locales
La especificación EJB sólo requiere que se dé soporte a vistas de cliente local para los EJB empaquetados en la misma aplicación. Esto incluye las factorías locales, las interfaces empresariales locals y la vista sin interfaz. El producto permite el acceso a vistas de cliente local para los EJB empaquetados en una aplicación independiente con algunas restricciones:
- La interfaz local y todos tipos de parámetros, devoluciones y excepciones que utiliza la interfaz local deben estar visibles para el cargador de clases tanto de la aplicación de llamada como de la aplicación de EJB de destino.
Puede asegurarse de que sea así utilizando una biblioteca compartida asociada a un cargador de clases de servidor o mediante una biblioteca compartida aislada asociada a ambas aplicaciones. Lea el tema Creación de bibliotecas compartidas para obtener más información.
- Cuando se detiene la aplicación EJB de destino, se deben renovar todas las referencias de memoria caché al EJB. Puede completar una de las acciones siguientes:
- Reiniciar la aplicación de llamada. La solución más sencilla es reiniciar la aplicación de llamada cada vez que reinicie una aplicación EJB de destino en la que se basa.
- Obtener una referencia nueva de JNDI. De forma predeterminada, las búsquedas JNDI desde el espacio de nombres java están en la memoria caché y la memoria caché debe estar inhabilitada o borrada para obtener una referencia nueva. Lea el tema Desarrollo de aplicaciones que utilizan el tema JNDI para obtener más información.
Las invocaciones de método EJB emiten com.ibm.websphere.ejbcontainer.EJBStoppedException cuando se ha detenido la aplicación EJB de destino.
Si ha almacenado en memoria caché la referencia de EJB en una variable de instancia utilizando la inyección
@EJB o la búsqueda JNDI, podrá captar esta excepción y renovar la referencia EJB llevando a cabo una búsqueda no almacenada en memoria caché.
- Habilitar los proxys EJB locales indirectos para la aplicación EJB de destino. Esto hace que el proxy EJB local se renueve automáticamente cuando se reinicia la aplicación. La habilitación de proxys locales indirectos provoca sobrecarga adicional para cada invocación de método EJB.
Puede habilitar proxys locales indirectos utilizando, por ejemplo, una consola administrativa. Pulse . Especifique un nombre de com.ibm.websphere.ejbcontainer.indirectLocalProxies y un valor de true para la propiedad personalizada y, a continuación, aplique y guarde los cambios.