Visión general de los enlaces de aplicación EJB 3.0 y EJB 3.1

Para poder iniciar una aplicación que está instalada en un servidor de aplicaciones, todas las referencias de Enterprise JavaBeans (EJB) y las referencias de recursos definidas en la aplicación deben enlazarse con los artefactos reales (enterprise beans o recursos) definidos en el servidor de aplicaciones.

A partir de la versión 8.0, el soporte de enlaces en el contenedor EJB se expande. El contenedor EJB asigna enlaces JNDI predeterminados para interfaces empresariales EJB 3.x basadas en el nombre de la aplicación, el nombre del módulo y el nombre del componente. No es necesario que defina explícitamente nombres de enlaces JNDI para cada una de las interfaces o ubicaciones iniciales de EJB de un módulo EJB 3.x o vistas sin interfaz en un módulo EJB 3.1.

Cuando se definen enlaces, se especifican nombres JNDI (Java™ Naming and Directory Interface) para los artefactos a los que se puede hacer referencia y a los que se hace referencia en una aplicación. Los valores de jndiName especificados para los artefactos deben ser nombres de búsqueda calificados.

No es necesario que asigne manualmente nombres de enlaces JNDI para cada una de las interfaces, ubicaciones iniciales de EJB o vistas que no sean de interfaz en los enterprise beans en los módulos EJB 3.x. Si no asigna explícitamente enlaces, el contenedor EJB asigna los enlaces predeterminados.

Espacios de nombres para los enlaces JNDI EJB predeterminados

El servidor de aplicaciones puede poner los enlaces EJB predeterminados en los conjuntos de espacios de nombres clásico y java:[ámbito].

El conjunto de espacios de nombres clásico consta de los espacios de nombres ejblocal: y JNDI global. Los espacios de nombres clásicos incluyen una extensión de WebSphere y existían en el servidor de aplicaciones anterior a la versión 8.0.

El conjunto de espacios de nombres java:[ámbito] consta de los espacios de nombres java:global, java:app y java:module. Los espacios de nombres java:[ámbito] se definen mediante la especificación Java EE 6 y se introducen en WebSphere Application Server en la versión 8. No son una sustitución para los espacios de nombres clásicos. Por el contrario, se añaden además de los espacios de nombres clásicos.

Detalles de los espacios de nombres clásicos

Para el nivel de EJB 3.x, el producto proporciona dos espacios de nombres clásicos diferentes para las interfaces EJB, en función de si la interfaz es local o remota. La misma provisión se aplica a las ubicaciones iniciales de EJB y a las vistas sin interfaz, que se pueden considerar tipos especiales de interfaces. Existen los siguientes espacios de nombres clásicos:
  • Espacio de nombres de ámbito de JVM (máquina virtual Java), ejblocal:
  • Espacio de nombres JNDI global

Las interfaces EJB locales, las ubicaciones iniciales y las vistas sin interfaz deben estar enlazadas a un espacio de nombres clásico ejblocal: con ámbito de JVM; solamente son accesibles desde el mismo proceso del servidor de aplicaciones.

En cambio, las ubicaciones iniciales y las interfaces EJB remotas deben estar siempre enlazadas a un espacio de nombres JNDI de WebSphere de ámbito global clásico; se puede acceder a ellas desde cualquier lugar, incluyendo otros procesos de servidor y otros clientes remotos. Las interfaces locales y las vistas sin interfaz no se pueden enlazar a un espacio de nombres JNDI con ámbito global clásico, ni las interfaces remotas se pueden enlazar en un espacio de nombres ejblocal: clásico con ámbito de JVM.

Los espacios de nombres clásicos ejblocal: y JNDI con ámbito global son dos cosas distintas y diferenciadas. Por ejemplo, una interfaz local EJB o una vista sin interfaz enlazada en "ejblocal:AccountHome" no es lo mismo que una interfaz remota enlazada en "AccountHome" en el espacio de nombres con ámbito global clásico. Este comportamiento permite mantener la distinción entre las referencias de la interfaz remota y de la interfaz local. Si se dispone de un espacio de nombres local con ámbito de JVM, también es posible que las aplicaciones busquen las interfaces EJB locales y las vistas sin interfaz o hagan referencia a las mismas directamente desde cualquier lugar del proceso del servidor JVM, incluyendo más allá de los límites de aplicaciones Java Platform, Enterprise Edition (Java EE).

Enlaces JNDI clásicos predeterminados para interfaces de empresa EJB en el contenedor EJB 3.x con nombres de aplicación, módulo y componente

El contenedor EJB asigna enlaces clásicos JNDI predeterminados para interfaces de empresa EJB 3.x en función del nombre de la aplicación, el nombre del módulo y el nombre del componente, por lo que es importante comprender cómo se definen estos nombres. Cada uno de estos nombres es una serie de caracteres.

Las aplicaciones Java EE se empaquetan en un formato estandarizado denominado archivo EAR (Enterprise Application Archive). El EAR es un formato de archivo empaquetado parecido a un formato de archivo .zip o .tar y, por lo tanto, se puede visualizar como una colección de directorios y archivos lógicos empaquetados conjuntamente en un único archivo físico. Dentro de cada archivo EAR se encuentran uno o más archivos de módulo Java EE, que pueden incluir:
  • Archivos JAR (Java Application Archive) para módulos EJB, módulos de cliente de aplicaciones Java EE y módulos de clase de programa de utilidad
  • Archivos WAR (Web Application Archive) para módulos web
  • Otros módulos específicos de tecnología como por ejemplo archivos RAR (Resource Application Archive) y otros tipos de módulos
Dentro de cada archivo de módulo se encuentran normalmente uno o más componentes Java EE. Son ejemplos de componentes Java EE los enterprise beans, los servlets y las clases principales de cliente de aplicaciones.

Dado que los módulos Java EE están empaquetados dentro de archivos de aplicación Java EE y que los componentes Java EE están a su vez empaquetados dentro de módulos Java EE, la "vía de acceso anidada" de cada componente se puede utilizar para identificar de forma exclusiva cada componente dentro de un archivo de aplicación Java EE, de acuerdo con el nombre de aplicación, el nombre de módulo y el nombre de componente.

Nombre de la aplicación que se utiliza en enlaces clásicos

El nombre de una aplicación se define por lo siguiente (en orden de prioridad):
  • El valor del nombre de aplicación especificado en la consola administrativa del producto o el parámetro appname proporcionado en la herramienta de scripts de la línea de mandatos de wsadmin, durante la instalación de la aplicación en el producto.
  • El valor del parámetro <display-name> del descriptor de despliegue META-INF/application.xml para la aplicación.
  • El nombre de archivo EAR, excluyendo el sufijo de archivo .ear. Por ejemplo, un archivo EAR de aplicación denominado CustomerServiceApp.ear tendría en este caso el nombre de aplicación "CustomerServiceApp".
La especificación Java EE 6 proporciona para nombres de búsqueda EJB JNDI del formato general, java:global[/nombre_apl]/nombre_módulo/nombre_bean. El componente nombre_aplicación del nombre e búsqueda se muestra como opcional porque no se aplica a los beans desplegados en módulos autónomos. Sólo los beans empaquetados en archivos .ear contienen el componente nombre_aplicación en el nombre de búsqueda de java:global. Las reglas que determinan el valor de nombre_aplicación son diferentes de las reglas descritas anteriormente para los nombres de aplicación. El valor nombre_aplicación en la plantilla de nombre de búsqueda java:global mostrada anteriormente está definido por lo siguiente, en orden de prioridad:
  • El valor del parámetro <application-name> en el descriptor de despliegue application.xml de la aplicación.
  • El nombre de archivo EAR, excluyendo el sufijo de archivo .ear. Por ejemplo, un archivo EAR de aplicación denominado CustomerServiceApp.ear tiene un nombre de aplicación "CustomerServiceApp". Si la aplicación es un módulo autónomo, el nombre de búsqueda java:global no contiene un componente de aplicación.
El valor de nombre_aplicación también es el valor de serie enlazado bajo el nombre, java:app/AppName, de acuerdo con la especificación Java EE 6.

Nombre del módulo que se utiliza en enlaces clásicos

El nombre de un módulo se define como el URI (identificador de recursos uniforme) del archivo del módulo, en relación a la raíz del archivo EAR en la que reside. Dicho de otro modo, el nombre de módulo es el nombre de archivo del módulo relativo a la raíz del archivo EAR, incluyendo los subdirectorios en los que está anidado el archivo del módulo. Este convenio de denominación es cierto incluso cuando se especifica explícitamente un nombre de módulo lógico utilizando el elemento de nombre de módulo en el descriptor de despliegue.

En el siguiente ejemplo, la aplicación "CustomerServiceApp" contiene tres módulos cuyos nombres son AccountProcessing.jar, Utility/FinanceUtils.jar y AppPresentation.war:
CustomerServiceApp.ear:AccountProcessing.jar 		   
com/mycompany/AccountProcessingServiceBean.class AccountProcessingService.class
Utility/FinanceUtils.jar META-INF/ejb-jar.xml
com/mycompany/InterestCalculatorServiceBean.class InterestCalculatorService.class
AppPresentation.war META-INF/web.xml  
La especificación Java EE 6 proporciona para nombres de búsqueda EJB JNDI del formato general, java:global[/nombre_apl]/nombre_módulo/nombre_bean. El componente nombre_aplicación del nombre e búsqueda se muestra como opcional porque no se aplica a los beans desplegados en módulos autónomos. Sólo los beans empaquetados en archivos .ear contienen el componente nombre_aplicación en el nombre de búsqueda de java:global. Otra variante de nombre de búsqueda JNDI que incluye el nombre del módulo es java:app/nombre_módulo/nombre_bean. El valor de nombre_módulo no es el URI de módulo. El valor nombre_módulo en las plantillas de nombre de búsqueda java:global y java:app lo define lo siguiente, en orden de prioridad:
  • El valor del parámetro <module-name> en el descriptor de despliegue ejb-jar.xml o web.xml del módulo.
  • El URI de módulo, excluyendo el sufijo .jar o .war. Por ejemplo, un módulo con un URI CustomerService.jar o CustomerService.war tiene un nombre de módulo "CustomerService".
El valor de nombre_módulo también es el valor de serie enlazado bajo el nombre, java:module/nombre_módulo, de acuerdo con la especificación Java EE 6. Esto también se aplica a los módulos de cliente. Para los módulos de cliente, el parámetro <module-name> se encuentra en el archivo del descriptor de despliegue application-client.xml.

Nombre de componente EJB que se utiliza en enlaces clásicos

El nombre de un componente EJB se define por el valor siguiente, en orden de prioridad:
  • El valor de un código ejb-name asociado al bean en el descriptor de despliegue ejb-jar.xml, si está presente.
  • El valor del parámetro "name", si está presente, en la anotación @Stateless o @Stateful asociada al bean.
  • El nombre de la clase de implementación de bean, sin ningún calificador a nivel de paquete.

Enlaces clásicos predeterminados para interfaces empresariales EJB, ubicaciones iniciales y vistas sin interfaz

No es necesario definir explícitamente los nombres de los enlaces JNDI para cada una de las interfaces o ubicaciones iniciales de EJB dentro de un módulo EJB 3.x o vista sin interfaz dentro de un módulo EJB 3.1. Si no asigna explícitamente enlaces, el contenedor EJB del producto asigna enlaces clásicos predeterminados utilizando el reglas que se describen aquí. Esto es diferente desde el soporte EJB en el productor antes de que se diera soporte a la especificación EJB 3.0.

El contenedor EJB crea dos enlaces clásicos predeterminados para cada vista con interfaz (de empresa, ubicación inicial remota o ubicación inicial local) o sin interfaz en cada enterprise bean. Aquí, estos dos enlaces clásicos se denominan el enlace corto y el enlace largo de la interfaz o la vista sin interfaz. El enlace corto utiliza solamente el nombre de clase Java calificado por el paquete de la interfaz o la vista sin interfaz, mientras que el enlace largo utiliza el ID de componente del enterprise bean como calificador adicional antes del nombre de clase de interfaz o vista sin interfaz calificado por el paquete, con un hash o signo de almohadilla (símbolo #) entre el ID de componente y el nombre de clase de interfaz o vista sin interfaz. Puede pensar en la diferencia entre las dos formas como análogas con un nombre de host TCP/IP corto (simplemente el nombre de la máquina) en contraposición a un nombre de host largo (nombre de la máquina con el nombre de dominio añadido como prefijo).

Por ejemplo los enlaces clásicos predeterminados, tanto largos como cortos, de una interfaz o vista sin interfaz podrían ser com.mycompany.AccountService y AccountApp/module1.jar/ServiceBean#com.mycompany.AccountService, respectivamente.

De forma predeterminada, el ID de componente de los enlaces EJB clásicos predeterminados se forma utilizando el nombre de la aplicación, el nombre del módulo y el nombre del componente del enterprise bean, pero se puede asignar en su lugar cualquier otra serie. Si define su propia serie como el ID de componente, puede establecer un convenio de denominación donde los enlaces de forma larga del enterprise bean compartan una parte común definida por el usuario, pero al mismo tiempo tengan una parte definida por el sistema en función del nombre de cada clase de interfaz o vista sin interfaz. También permite hacer que los nombres de enlace EJB predeterminados sean independientes de la forma en la que se empaquetan los enterprise beans dentro de la jerarquía del módulo de la aplicación. La alteración temporal del ID de componente predeterminado de un enterprise bean se describe en a sección "Enlaces definidos por el usuario para interfaces de empresa, ubicaciones iniciales y vistas sin interfaz" de este tema.

Como se ha mencionado anteriormente en la sección sobre el espacio de nombres local clásico de ámbito de JVM y el espacio de nombres JNDI clásico con ámbito global, todas las ubicaciones iniciales, las interfaces locales y las vistas sin interfaz deben estar enlazadas al espacio de nombres clásico ejblocal:, al que se puede acceder sólo desde dentro del mismo proceso de servidor (JVM), mientras que las interfaces remotas y las ubicaciones iniciales deben estar enlazadas en el espacio de nombres clásico de ámbito global, al que se puede acceder desde cualquier lugar de la célula de producto WebSphere. Como sería de esperar, el contenedor EJB sigue estas reglas para los enlaces por omisión.

Además, los enlaces predeterminados largos para las interfaces remotas siguen los procedimientos recomendados de Java EE en que se agrupan bajo un nombre de contexto ejb. Por omisión, las interfaces de empresa y las ubicaciones iniciales de EJB se enlazan a la raíz del contexto de denominación del servidor de aplicaciones. Sin embargo, dado que el contexto raíz de servidor de aplicaciones se utiliza para enlazar más que simplemente interfaces EJB, para evitar que este contexto se llene demasiado, se recomienda agrupar enlaces relacionados con EJB en un subcontexto "ejb" común en lugar de colocarlos directamente en el contexto raíz de servidor. Es el mismo motivo por el que se utilizan subdirectorios en un volumen de disco en lugar de colocar todos los archivos en el directorio raíz.

Los enlaces por omisión cortos para las interfaces remotas no se enlazan en el contexto ejb. Los enlaces por omisión cortos están ubicados en la raíz del contexto raíz del servidor. Aunque el procedimiento recomendado es agrupar todos los enlaces relacionados con EJB bajo un contexto ejb, existen otras consideraciones que incluyen las situaciones siguientes:
  • Los enlaces predeterminados cortos proporcionan una forma simple y directa de acceder a una interfaz EJB. El objetivo de colocarlos directamente en el contexto raíz del servidor y de hacer referencia a los mismos simplemente mediante el nombre de interfaz o el nombre de interfaz con el prefijo ejblocal: era mantener esta simplicidad.
  • Al mismo tiempo, la colocación de los enlaces predeterminados largos en el contexto ejb, o en el contexto ejblocal: en el caso de una interfaz local, mantenía estos enlaces fuera del contexto raíz del servidor y reducía el desorden de manera suficiente para permitir tener los enlaces cortos en el contexto raíz.
  • Proporciona un grado de compatibilidad cruzada con otros servidores de aplicaciones Java EE que utilizan convenios de denominación similares.

En resumen, todos los enlaces predeterminados locales, tanto cortos como largos, se colocan en el espacio de nombres clásico con ámbito del servidor/JVM ejblocal:, mientras que los enlaces predeterminados remotos se colocan en el contexto raíz del servidor del espacio de nombres clásico con ámbito global si son cortos o en el contexto <raíz_servidor>/ejb (después del contexto raíz del servidor) si son largos. Por lo tanto, los únicos enlaces predeterminados del contexto raíz con ámbito global del servidor son los enlaces cortos para las interfaces remotas, lo que constituye el mejor equilibrio entre proporcionar un modelo de uso simple y transferible y evitar que el contexto raíz con ámbito global del servidor se llene demasiado.

Patrón de enlace clásico predeterminado

Los patrones para cada tipo de enlace clásico se muestran en la tabla. En estos patrones, las series que aparecen en <cursiva entre corchetes representan un valor. Por ejemplo, <package.qualified.interface> podría ser com.mycompany.AccountService, y <component-id> podría ser AccountApp/module1.jar/ServiceBean.

Tabla 1. Patrones de enlace predeterminados. Patrones de enlace predeterminados
Patrones de enlace Descripción
ejblocal:<package.qualified.interface> Interfaces de empresa de EJB, ubicaciones iniciales y vistas sin interfaz con forma corta
<package.qualified.interface> Interfaces y ubicaciones iniciales remotas con forma corta
ejblocal:<component-id>#<package.qualified.interface> Interfaces de empresa de EJB, ubicaciones iniciales y vistas sin interfaz con forma larga
ejb/<component-id>#<package.qualified.interface> Interfaces y ubicaciones iniciales remotas con forma larga

El patrón predeterminado de ID-componente es <nombre-aplicación>/<nombre-jar-módulo>/<nombre-ejb;> a menos que se altere temporalmente en el archivo de enlaces de módulo EJB con el atributo component-id como se describe en la sección siguiente, "Conflictos en los nombres de enlace predeterminados cortos cuando se implementan múltiples enterprise beans en la misma interfaz". La variable <nombre-jar-módulo>, cuando no la altera temporalmente el archivo de enlaces del módulo EJB, es el nombre del archivo de módulo físico dentro del EAR, incluida la extensión, por ejemplo, .jar, .ear, .war, tal como se describe en la sección anterior "Nombre de módulo", incluso si se especifica un nombre de módulo lógico en el descriptor de despliegue.

Conflictos en los nombres de enlace clásico predeterminados cortos cuando se implementan múltiples enterprise beans en la misma interfaz

Cuando más de un enterprise bean que se ejecuta en el servidor de aplicaciones implementa una interfaz o vista sin interfaz determinada, el nombre de enlace clásico predeterminado corto se convierte en ambiguo ya que el nombre corto puede hacer referencia a cualquiera de los Enterprise JavaBeans que implementan esta interfaz o vista sin interfaz. Para evitar esta situación, debe definir explícitamente un enlace para cada Enterprise JavaBeans que implemente la interfaz determinada o la vista sin interfaz tal como se describe en la sección siguiente, o bien inhabilitar los enlaces predeterminados cortos clásicos para las aplicaciones que contienen estos Enterprise JavaBeans definiendo una propiedad personalizada com.ibm.websphere.ejbcontainer.disableshortdefaultbindings de la JVM del producto WebSphere. Para obtener más información acerca de la propiedad personalizada JVM, lea el apartado acerca de las propiedades personalizadas de la máquina virtual Java.

Para utilizar esta propiedad personalizada de JVM, establezca el nombre de propiedad en com.ibm.websphere.ejbcontainer.disableShortFormBinding y el valor de propiedad en * (asterisco) como valor comodín para inhabilitar los enlaces clásicos predeterminados de forma corta para todas las aplicaciones del servidor o en una secuencia separada por dos puntos de los nombres de aplicaciones Java EE para los que desea inhabilitar los enlaces clásicos predeterminados cortos, por ejemplo PayablesApp:InventoryApp:AccountServicesApp.

Efecto de la asignación explícita en los enlaces clásicos predeterminados

Si asigna explícitamente una definición de enlace para una interfaz, ubicación inicial o vista sin interfaz, no se realiza ningún enlace clásico predeterminado corto o largo para esta interfaz o vista sin interfaz.
Supported configurations Supported configurations: Esto solamente es aplicable para las interfaces o vistas sin interfaz específicas para las que se asigna un enlace explícito. Otras instancias de ese enterprise bean, sin enlaces asignados explícitamente, se enlazarán utilizando los nombres de enlaces clásicos predeterminados.sptcfg

Espacios de nombres java:[ámbito]

Los espacios de nombres java:global, java:app y java:module se presentan en la especificación Java EE 6. Ofrecen un mecanismo para enlazar y buscar recursos que son portables entre servidores de aplicaciones.

El servidor siempre crea un enlace predeterminado en formato largo para cada interfaz EJB, incluida la vista sin interfaz, y los coloca en los espacios de nombres java:global, java:app y java:module. También se crea un enlace de formato corto y se coloca en los espacios de nombres java:global, java:app y java:module, si el bean sólo expone una interfaz, incluyendo la vista sin interfaz. Los enlaces predeterminados se crean únicamente para los beans de sesión. No se crean para los beans de entidad o los beans controlados por mensajes.

Los enlaces de formato largo y corto contienen el nombre de la aplicación, el nombre del módulo y el nombre del componente de bean. Como nombre predeterminado de la aplicación se toma el nombre base del archivo .ear, sin la extensión. El nombre de la aplicación puede alterarse temporalmente utilizando el elemento application-name del archivo application.xml. Como nombre predeterminado del módulo se toma el nombre de la vía de acceso del módulo, incluyendo los nombres de todos los directorios y eliminando la extensión. El nombre del módulo se pueden alterar temporalmente utilizando el elemento module-name de los archivos ejb-jar.xml o web.xml. Como nombre predeterminado del componente de bean se toma el nombre no calificado de la clase de bean. El nombre del componente de bean puede alterarse temporalmente utilizando el atributo name de la anotación de definición del componente EJB o el elemento ejb-name del archivo ejb-jar.xml.

El patrón de enlace de formato largo es java:global/<nombreAplicación>/<nombreMódulo>/<nombre componente bean>!<nombre de interfaz completo>.

El patrón de enlace de formato corto es java:global/<nombreAplicación>/<nombreMódulo>/< nombre componente bean >.

Por ejemplo, el componente de bean MyBeanComponent sólo expone una interfaz, com.foo.MyBeanComponentLocalInterface, y está empaquetado en el módulo myModule.jar del archivo myApp.ear. Como consecuencia, se crean los siguientes enlaces en los espacios de nombres java:[ámbito]:
  • java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
  • java:global/myApp/myModule/MyBeanComponent
  • java:app/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
  • java:app/myModule/MyBeanComponent
  • java:module/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
  • java:module/MyBeanComponent
El bean MyBeanComponent puede obtenerse de los espacios de nombres java:[ámbito] utilizando una de las técnicas siguientes:
  • Utilice el atributo de búsqueda en la anotación @EJB; por ejemplo:
    @EJB(lookup="java:global/myApp/myModule/MyBeanComponent")
  • Utilice el elemento de nombre de búsqueda ejb-jar.xml; por ejemplo:
    <lookup-name>java:global/myApp/myModule/MyBeanComponent!com.ibm.MyBeanComponentLocalInterfaces</lookup-name>
  • Realizar una búsqueda en el objeto InitialContext; por ejemplo:
    initialContext.lookup("java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterfaces")

Además de los enlaces predeterminados creados por el servidor de aplicaciones, el usuario puede definir referencias en los espacios de nombres java:global, java:app y java:module. Las referencias definidas en los espacios de nombres java:global, java:app y java:module no entran en el espacio de nombres del componente. Las referencias definidas en los espacios de nombres java:global, java:app o java:module deben buscarse o inyectarse desde esos espacios de nombres. No pueden buscarse o inyectarse desde el espacio de nombres del componente.

Un componente de bean puede utilizar el espacio de nombres java:module para declarar una referencia que puede utilizar un componente empaquetado en el mismo módulo. Puede utilizar el espacio de nombres java:app para declarar una referencia que puede utilizar un componente empaquetado en un módulo distinto de la misma aplicación. Puede utilizar el espacio de nombres java:global para declarar una referencia que puede utilizar un componente empaquetado en una aplicación diferente.

Las referencias que tengan nombres idénticos en los espacios de nombres java:global, java:app o java:module pueden entrar en conflicto entre sí, de igual modo que pueden entrar en conflicto las referencias que tengan nombres idénticos en el espacio de nombres del componente. Una referencia delimitada al espacio de nombres java:app de una aplicación no entrará en conflicto con una referencia delimitada al espacio de nombres java:app que tenga el mismo nombre pero que sea de una aplicación distinta. Del mismo modo, una referencia delimitada al espacio de nombres java:module de un módulo no entrará en conflicto con una referencia delimitada al espacio de nombres java:module que tenga el mismo nombre pero sea de un módulo diferente.

En el espacio de nombres java:global se pueden declarar una referencia utilizando anotaciones; por ejemplo:
@EJB(name="java:global/env/myBean")
En el archivo ejb-jar.xml se puede declarar una referencia; por ejemplo:
<resource-ref>
    <res-ref-name>java:global/env/myDataSource</res-ref-name>
    ....
</resource-ref>         

Para obtener documentación adicional sobre los espacios de nombre java:[ámbito], consulte la sección 5.2.2 de la especificación Java EE 6 y la sección 4.4 de la especificación de Enterprise JavaBeans 3.1.

Enlaces definidos por el usuario para interfaces de empresa de EJB, ubicaciones iniciales y vistas sin interfaz

En los casos en los que desee asignar manualmente ubicaciones de enlace en lugar de utilizar los enlaces predeterminados del producto, puede utilizar el archivo de enlaces del módulo EJB para asignar sus propias ubicaciones de enlace para interfaces, ubicaciones iniciales y vistas sin interfaz específicas. También puede utilizar este archivo para alterar sólo temporalmente la parte del ID de componente de los enlaces predeterminados en uno o varios enterprise beans del módulo. La alteración temporal del ID de componente proporciona un término medio entre el uso de todos los enlaces predeterminados y la especificación completa del nombre de enlace para cada interfaz o vista sin interfaz.

Para especificar información de enlaces definidos por el usuario para los módulos EJB 3.x, coloque el archivo ibm-ejb-jar-bnd.xml en el directorio META-INF para el archivo JAR (Java archive) de EJB. El sufijo de este archivo es XML. Además, cuando se define un enlace para una interfaz local o una vista sin interfaz, debe añadir como prefijo al nombre la serie "ejblocal:" a fin de que se enlace con el espacio de nombres ejblocal: de ámbito de JVM clásico.

El archivo ibm-ejb-jar-bnd.xml se utiliza para los módulos EJB 3.0 y posteriores que se ejecutan en el producto, mientras que el archivo ibm-ejb-jar.bnd.xmi se utiliza para módulos anteriores a EJB 3.0 y para módulos web. El formato del archivo de enlace del archivo ibm-ejb-jar.bnd.xml es diferente del formato de archivo XML por las razones siguientes:
  • Los enlaces y las extensiones que se declaran en el formato de archivo XML dependen de la presencia del archivo de descriptor de despliegue ejb-jar.xml correspondiente que hace referencia explícitamente a números de ID exclusivos adjuntados a elementos de ese archivo. Este sistema ya no es viable para módulos EJB 3.0 y posteriores, donde ya no es necesario que el módulo contenga un descriptor de despliegue ejb-jar.xml.
  • El formato de archivo XMI se diseñó para que pudiera ser editado por la máquina solamente por parte de las funciones de gestión del sistema y las herramientas de desarrollo del producto; era una parte efectiva de la implementación interna del producto y la estructura del archivo no se documentaba nunca externamente. Posibilitaba que los desarrolladores editaran manualmente los archivos de enlaces o los crearan como parte de un proceso de compilación independiente de WebSphere de forma soportada.
  • En lugar de hacer referencia a números de ID codificados en el descriptor de despliegue ejb-jar.xml, el archivo de enlaces basado en XML hace referencia a un componente EJB por su nombre de EJB. Cada componente EJB de un módulo tiene un nombre de EJB exclusivo, ya sea de forma predeterminada o mediante la asignación explícita por parte del desarrollador. Por lo tanto, este comportamiento proporciona una forma inequívoca de hacer referencia a enlaces y extensiones.
  • Los nuevos archivos de enlaces se basan en XML y se proporciona un archivo XSD (XML Schema Definition) para documentar externamente la estructura. Estos archivos .xsd pueden ser consumidos por muchos editores de archivos XML comunes como ayuda en las funciones de verificación sintáctica y finalización de código. Como resultado, ahora los desarrolladores pueden producir y editar los archivos de enlaces y extensiones independientemente de la infraestructura del servidor de aplicaciones.
En la tabla siguiente se listan los elementos y los atributos de ibm-ejb-jar-bnd.xml que se utilizan para asignar enlaces a las interfaces y las ubicaciones iniciales EJB para los módulos EJB 3.x y a las vistas sin interfaz para los módulos EJB 3.1.
Tabla 2. Elementos y atributos de ibm-ejb-jar-bnd.xml. Elementos y atributos de ibm-ejb-jar-bnd.xml
Elemento o atributo Forma de utilización Ejemplo Comentarios
<session> Declara un grupo de asignaciones de enlaces para un bean de sesión. <session name="AccountServiceBean"/> Requiere el atributo name y como mínimo uno de los atributos siguientes: atributo simple-binding-name, atributo local-home-binding-name, atributo remote-home-binding-name o elemento <interface>.
nombre Atributo que identifica el ejb-name del enterprise bean al que se aplica un elemento <session>, <message-driven> o <entity> u otro elemento. <session name="AccountServiceBean"/> El valor del nombre es el nombre declarado en el elemento <ejb-name> de un archivo de descriptor de despliegue ejb-jar.xml, el atributo de nombre de una anotación @Stateful, @Stateless, @Singleton o @MessageDriven, o toma de forma predeterminada el nombre de clase no calificado de la clase de implementación EJB anotada con la anotación @Session o @MessageDriven (si no se especifica el valor <ejb-name> en el descriptor de despliegue XML y no se declara ningún parámetro de nombre en la anotación).
component-id Atributo que altera temporalmente el valor de ID de componente predeterminado para un enterprise bean. Los enlaces clásicos con forma larga predeterminados para este enterprise bean utilizan el ID de componente especificado en lugar de <nombre:apl>/<nombre_jar_módulo>/<nombre_bean>.
<session name="AccountServiceBean" 
component-id="Dept549/AccountProcessor"/>

En el ejemplo anterior se obtiene como resultado el bean cuyo ejb-name es AccountServiceBean, que tiene sus interfaces locales clásicas predeterminadas de formato largo enlazadas a ejblocal:Department549/AccountProcessor#<package.qualified.interface> Las interfaces remotas clásicas predeterminadas de formato largo están enlazadas a ejb/Department549/AccountProcessor#<package.qualified.interface>

Se puede utilizar solo o bien en combinación con el elemento <interface>, el atributo local-home-binding-name o el atributo remote-home-binding-name. Las interfaces a las que no se asignan enlaces explícitos pueden tener realizados enlaces clásicos predeterminados utilizando el valor de ID de componente especificado por el usuario. Las interfaces a las que se asignan enlaces explícitos se enlazarán utilizando estos valores.

Debido a que el objetivo del atributo simple-binding-name es su aplicación a todas las interfaces definidas en un enterprise bean determinado (sin dejar ninguna interfaz predeterminada), la aplicación de un component-id en combinación con simple-binding-name normalmente no es muy útil.

simple-binding-name Mecanismo simple para asignar enlaces de interfaz para Enterprise JavaBeans que:
  • Implementan una única interfaz de empresa EJB 3.x
  • Implementan una interfaz de componente de estilo anterior a EJB 3.0 (de tipo local, remoto, o ambos) con una ubicación inicial de EJB de acompañamiento.
El valor del atributo se utiliza como la ubicación de enlace de la interfaz de empresa del enterprise bean o la ubicación de enlace de las ubicaciones iniciales locales, remotas, o ambas, de Enterprise JavaBeans. El enlace se coloca en el espacio de nombres ejblocal: clásico si la interfaz o la ubicación inicial es local, y se coloca en el contexto raíz del servidor de aplicaciones del espacio de nombres JNDI clásico con ámbito global si la interfaz o la ubicación inicial son remotas.
<session name="AccountServiceBean"
simple-binding-name="ejb/AccountService"/>
El resultado de este ejemplo es que la interfaz de empresa o ubicación inicial local, si existe, del bean cuyo ejb-name es AccountServiceBean, se enlaza en ejblocal:ejb/AccountService en el espacio de nombres clásico EJB con ámbito de JVM local, y su interfaz de empresa o ubicación inicial remota (si existe) se enlaza en ejb/AccountService en el contexto raíz del servidor de aplicaciones del espacio de nombres clásico JNDI con ámbito global.
Importante: Importante:
se utiliza el valor exacto del atributo, incluido, en este ejemplo específico, el nombre de subcontexto "ejb", aunque la interfaz sea una interfaz local enlazada en el espacio de nombres ejblocal:. Cuando se especifican enlaces definidos por el usuario, se utiliza el nombre exacto especificado por el atributo.
No se debe utilizar en combinación con los atributos local-home-binding-name o remote-home-binding-name, o con el elemento <interface>. Además, no se debe utilizar en beans que implementen más de una interfaz de empresa (en su lugar, en este caso utilice el elemento <interface>.

Si este atributo se utiliza en un enterprise bean que implementa más de una interfaz de empresa, o una combinación de interfaz de empresa e interfaz de componente local/remota con ubicación inicial, se elimina la ambigüedad de los enlaces resultantes añadiendo un guión o un signo de número (el símbolo #) al valor del atributo, seguido por el nombre de clase calificado por el paquete de cada interfaz, ubicación inicial o ambas del enterprise bean. Sin embargo, esta condición se puede evitar utilizando el elemento <interface> para definir un enlace para cada una de las interfaces en lugar de utilizar simple-binding-name.

Importante: Importante:
la definición de un simple-binding-name en un bean que implementa más de una interfaz de empresa no es lo mismo que la alteración temporal del ID de componente predeterminado para un bean utilizando <component-id>. Los enlaces predeterminados de interfaces remotas definidos con component-id se siguen agrupando bajo el contexto de EJB (como lo hacen todos los enlaces predeterminados de interfaces remotas), mientras que los enlaces de interfaces remotas cuya ambigüedad ha sido resuelta por el contenedor EJB en respuesta a la utilización incorrecta de simple-binding-name en un bean con múltiples interfaces no se agrupan bajo el contexto de ejb.
Adicionalmente, la inclusión del nombre de clase calificado por el paquete se produce siempre para enlaces clásicos predeterminados con forma larga, mientras que con simple-binding-name se produce solamente en las condiciones de error, donde es necesario deshacer la ambigüedad. No se debe depender del nombre de enlace creado al deshacer la ambigüedad, porque el hecho de que este efecto se produzca o no puede cambiar si el bean se cambia para implementar más o menos interfaces.
local-home-binding-name Atributo para especificar la ubicación de enlace de la ubicación inicial local de un enterprise bean.
<session name="AccountServiceBean"
 local-home-binding-name="ejblocal:AccountService"/>
No se debe utilizar en combinación con el atributo simple-binding-name. Debido a que las ubicaciones iniciales locales deben estar siempre enlazadas al espacio de nombres clásico con ámbito de JVM, el valor debe empezar con el prefijo ejblocal:.
remote-home-binding-name Atributo para especificar la ubicación de enlace de la ubicación inicial remota de un enterprise bean.
<session name="AccountServiceBean"
 remote-home-binding-name=
 "ejb/services/AccountService"/>
No se debe utilizar en combinación con el atributo simple-binding-name. El valor no puede empezar con el prefijo clásico ejblocal:, ya que las ubicaciones iniciales remotas no pueden enlazarse al espacio de nombres clásico ejblocal:.
<interface> Subelemento del elemento <session> que asigna un enlace a una interfaz empresarial EJB o a una vista sin interfaz específica. A diferencia de los atributos simple-binding-name, local-home-binding-name y remote-home-binding-name, son necesarios tanto un parámetro de nombre de enlace como un parámetro de clase (de hecho, esta distinción es la razón por que la es necesario un elemento XML aparte en lugar de un atributo). El parámetro de clase especifica el nombre calificado por el paquete de la clase de interfaz de empresa o la vista sin interfaz que se enlazará.
<interface class="com.ejbs.InventoryService" 
binding-name="ejb/Inventory"/> 
(declarado como subelemento dentro de un elemento <session>)
No se debe utilizar en combinación con el atributo simple-binding-name. Debido a que las interfaces locales y las vistas sin interfaz se deben enlazar siempre al espacio de nombres clásico con ámbito de JVM, el valor de binding-name debe empezar con el prefijo ejblocal: cuando este elemento se aplica a una interfaz local o a una vista sin interfaz.
binding-name Atributo para especificar la ubicación de enlace de una interfaz de empresa enlazada con el elemento <interface>.
<interface class="com.ejbs.InventoryService" 
binding-name="ejb/Inventory"/>
(declarado como subelemento dentro de un elemento <session>)
Es necesario en combinación con el elemento <interface> (y se utiliza en ese elemento solamente). Debido a que las interfaces locales deben estar siempre enlazadas en el espacio de nombres clásico de ámbito JVM, el valor de binding-name debe empezar con el prefijo ejblocal: cuando se aplica a una interfaz local.

Ejemplo 1 de archivo de enlaces

El ejemplo siguiente es un archivo ibm-ejb-jar-bnd.xml básico que contiene sólo los elementos y atributos que asignan nombres de enlace a interfaz EJB y vistas sin interfaz. Altera temporalmente el ID de componente utilizado para los enlaces predeterminados en el enterprise bean denominado S01 y asigna enlaces explícitos a algunas de las interfaces en los enterprise beans, S02 y S03, en este módulo.
<?xml version="1.0" encoding="UTF-8?"> 
<ejb-jar-bnd xmlns=http://websphere.ibm.com/xml/ns/javaee xmlns:xsi="
 http://www.w3.org/2001/XMLSchema-instance "xsi:schemaLocation"=
 http://websphere.ibm.com/xml/ns/javaee 
 http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd "version 1.0">
 <session name="S01" component-id="Department549/AccountProcessors"/>
 <session name="S02" simple-binding-name="ejb/session/S02"/>
 <session name="S03">
  <interface class="com.ejbs.BankAccountService" binding-name="ejblocal:session/BAS"/>
 </session>
</ejb-jar-bnd>
El archivo de enlace tiene los resultados siguientes:
  • Al bean de sesión con ejb-name S01 se le asigna un ID de componente definido por el usuario, lo cual altera temporalmente el ID de componente predeterminado (nombre de aplicación/nombre de módulo ejb-jar/nombre de bean) para todas las interfaces de ese bean. Las interfaces locales y las vistas sin interfaz de este bean se enlazan en ejblocal:Department549/AccountProcessors#<nombre.interfaz.calificado.paquete> mientras que las interfaces remotas se enlazan en ejb/Department549/AccountProcessors#<nombre.interfaz.calificado.paquete>
  • Se presupone que el bean de sesión con ejb-name S02 tiene una única interfaz de empresa EJB 3.x o una vista sin interfaz EJB 3.1. De forma opcional, podría tener una interfaz de "componente" anterior a EJB 3.0 con ubicación inicial local, ubicación inicial remota o ubicaciones iniciales locales y remotas. La interfaz empresarial, o la ubicación o ubicaciones iniciales de la interfaz de componente se enlazan en ejblocal:ejb/session/S02 si es local, o en ejb/session/S02 si es remota.

    Si el bean S02 tiene más de una interfaz de empresa, o interfaces de empresa y una ubicación inicial, un simple-binding-name es ambiguo. En este caso, el contenedor deshace la ambigüedad de las asignaciones de los enlaces añadiendo #<nombre.interfaz.calificada.paquete> al nombre de enlace simple ejb/session/S02 para cada una de las interfaces del bean.

  • La interfaz de empresa EJB 3.x o la vista sin interfaz EJB 3.1 com.ejbs.BankAccountService en el bean de sesión con ejb-name S03 se enlaza en ejblocal:session/BAS.
A todas las demás interfaces de empresa, ubicaciones iniciales y vistas sin interfaz en este bean, si están presentes, se les asignan enlaces clásicos predeterminados. Se presupone que la interfaz com.ejbs.BankAccountService es local, ya que se ha designado para el espacio de nombres ejblocal: en este ejemplo; se produce un error si la interfaz no es local.

La siguiente sección amplía este ejemplo mediante la introducción de elementos para resolver los destinos de las distintas clases de entradas de referencias e inyecciones declaradas en el descriptor de despliegue XML o mediante anotaciones.

Enlaces definidos por el usuario para resolver destinos de referencias e inyecciones

La sección anterior ha mostrado ejemplos de cómo asignar nombres de enlaces definidos por el usuario para interfaces de empresa, ubicaciones iniciales y vistas sin interfaz. En esta sección se trata la forma de resolver destinos de enlaces para referencias, directivas de inyección y destinos de beans controlados por mensajes.

Tabla 3. Elementos y atributos para resolver destinos de enlace para referencias y destinos de inyección. Elementos y atributos para resolver destinos de enlace para referencias y destinos de inyección
Elemento o atributo Forma de utilización Ejemplo Comentarios
<jca-adapter> Define una especificación de activación del adaptador JCA 1.5 y una ubicación JNDI de destino de mensajes, para la entrega de mensajes a un bean controlado por mensajes.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
Requiere el atributo activation-spec-binding-name. Si el bean controlado por mensaje correspondiente no identifica su destino de mensaje mediante el elemento <message-destination-link>, también se necesitará el atributo destination-binding-name. Puede incluir opcionalmente el atributo activation-spec-auth-alias.
<ejb-ref> Resuelve el destino de una declaración ejb-ref, que se declara mediante la anotación @EJB o mediante el elemento ejb-ref del descriptor de despliegue ejb-jar.xml, proporcionando el enlace entre el nombre declarado en el espacio de nombres java:comp/env con ámbito de componente y el nombre de enterprise bean de destino en el espacio de nombres clásico ejblocal: con ámbito de JVM o el espacio de nombres clásico JNDI con ámbito global.
<ejb-ref name="com.ejbs.BankAccountServiceBean/s02Ref" 
binding-name="ejb/session/S02"/>
Requiere los atributos name y binding-name.
<message-driven> Declara un grupo de asignaciones de enlaces para un bean controlado por mensajes.
<message-driven name="EventRecorderBean">
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec" 
destination-binding-name="jms/ServiceQueue"/>
</message-driven>
Requiere el atributo name y el subelemento <jca-adapter>.
<message-destination> Asocia el nombre de un destino de mensajes, que es un nombre lógico definido en un descriptor de despliegue del módulo Java EE, con un nombre JNDI global específico, que es un nombre real en el espacio de nombres JNDI. Los elementos <message-destination-ref> del descriptor de despliegue del módulo Java EE o las directivas de inyección @Resource que inyectan destinos de mensajes pueden utilizar el elemento <message-destination-line> para hacer referencia a este destino de mensaje mediante el nombre lógico de destino, en lugar de necesitar entradas de enlaces <message-destination-ref> individuales en el archivo de enlaces para cada message-destination-ref.
<message-destination name="EventProcessingDestination"
binding-name="jms/ServiceQueue"/>
Requiere los atributos name y binding-name.
<message-destination-ref> Resuelve el destino de una declaración message-destination-ref declarada mediante la anotación @Resource o mediante el elemento message-destination-ref de ejb-jar.xml, proporcionando el enlace entre el nombre declarado en el espacio de nombres java:comp/env con ámbito de componente y el nombre del entorno de recurso de destino del espacio de nombres JNDI global.
<message-destination-ref
name="com.ejbs.BankAccountServiceBean/serviceQueue"
binding-name="jms/ServiceQueue"/>
Requiere los atributos name y binding-name.
<resource-ref> Resuelve el destino de una declaración resource-ref declarada mediante la anotación @Resource o mediante el elemento resource-ref de ejb-jar.xml, proporcionando el enlace entre el nombre declarado en el espacio de nombres java:comp/env con ámbito de componente y el nombre del recurso de destino en el espacio de nombres JNDI global.
<resource-ref
name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default"/>
Requiere los atributos name y binding-name. Puede incluir los atributos authentication-alias o custom-login-configuration.
<resource-env-ref> Resuelve el destino de una declaración resource-env-ref declarada mediante la anotación @Resource o mediante el elemento resource-env-ref de ejb-jar.xml, proporcionando el enlace entre el nombre declarado en el espacio de nombres java:comp/env con ámbito de componente y el nombre del entorno de recursos de destino en el espacio de nombres JNDI global.
<resource-env-ref 
name="com.ejbs.BankAccountServiceBean/dataFactory"
binding-name="jdbc/Default"/>
Requiere los atributos name y binding-name.
<env-entry> Altera temporalmente una entrada de entorno con el valor especificado representado en formato de serie u objeto, al que se puede acceder con una búsqueda de JNDI en el nombre de búsqueda especificado aplicado al contexto inicial predeterminado.
<env-entry name="java:module/env/taxYear" value="2010"/>
<env-entry name="java:module/env/taxYear" binding-name="cell/persistent/MyApp/MyModule/taxYear"/
Requiere el atributo name y el valor o el atributo binding-name, pero no ambos.
<data-source> Altera temporalmente una definición de origen de datos, que se declara mediante la anotación @DataSourceDefinition o mediante el elemento de origen de datos en la aplicación, o un descriptor de despliegue de módulo, con un recurso gestionado.
<data-source name="java:module/env/myDS" 
binding-name="jdbc/DB2DS"/>
Requiere los atributos name y binding-name.
nombre Atributo que identifica la ubicación de denominación, normalmente dentro del espacio de nombres java:comp/env específico del componente, que define la parte "de origen" de un enlace de referencia/destino, como por ejemplo en ejb-ref, resource-ref, resource-env-ref, message-destination o message-destination-ref.
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
 
binding-name Atributo que identifica la ubicación de denominación dentro de un espacio de nombres ejblocal: clásico, o JNDI con ámbito global clásico, o java:global que define la parte "de destino" de un enlace de referencia/destino, como por ejemplo en ejb-ref, resource-ref, resource-env-ref, message-destination o message-destination-ref.
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
 
value Atributo que especifica el valor que debe utilizarse para un enlace env-entry.
<env-entry name="java:module/env/taxYear" value="2010"/>
 
activation-spec-binding-name Atributo que identifica la ubicación JNDI de la especificación de activación asociada con el adaptador JCA 1.5 que se utilizará para entregar mensajes a un bean controlado por mensajes.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
Este nombre debe coincidir con el nombre de una especificación de activación de JCA 1.5 que se defina en WebSphere Application Server.
activation-spec-auth-alias Atributo opcional que identifica el nombre de un alias de autenticación J2C utilizado para la autenticación de conexiones del adaptador de recursos JCA. El alias de autenticación J2C especifica el ID de usuario y la contraseña que se utiliza para autenticar la creación de una nueva conexión con el adaptador de recursos de JCA.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
activation-spec-auth-alias="jms/Service47Alias"
destination-binding-name="jms/ServiceQueue"/>
Este nombre debe coincidir con el nombre de un alias de autorización J2C que se define en WebSphere Application Server
destination-binding-name Atributo que identifica el nombre JNDI que utiliza el bean controlado por mensajes para buscar su destino JMS en el espacio de nombres JNDI.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
Este nombre debe coincidir con el nombre de un tema o de una cola JMS que se define en WebSphere Application Server.
authentication -alias Subelemento opcional del elemento de enlace <resource-ref>. Si la referencia del recurso es para una fábrica de conexiones, se puede especificar una configuración de inicio de sesión JAAS opcional; en este caso, un nombre de alias de autenticación simple.
<resource-ref
name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default">
<authentication-alias name="defaultAuth"/>
<resource-ref>
Este nombre debe coincidir con el nombre de un alias de autenticación JAAS que se define en WebSphere Application Server.
custom-login-configuration Subelemento opcional del elemento de enlace <resource-ref>. Si la referencia del recurso es para una fábrica de conexiones, se puede especificar una configuración de inicio de sesión JAAS opcional; en este caso, un conjunto de propiedades (pares de nombre/valor).
<resource-ref
name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default">
<custom-login-configuration-name="customLogin">
<property name="loginParm1" value="ABC123"/>
<property name="loginParm2" value="DEF456"/>
</custom-login-configuration> 
</resource-ref>         
Este nombre debe coincidir con el nombre de una configuración de inicio de sesión JAAS que se define en WebSphere Application Server.

Ejemplo 2 de archivo de enlaces

El ejemplo siguiente es una expansión del archivo ibm-ejb-jar-bnd.xml básico presentado en el Ejemplo 1.
<?xml version="1.0" encoding="UTF-8"?> 
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" "xmlns:xsi"=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee" 
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd version" "1.0">
 <session name="S01" component-id="Department549/AccountProcessors"/>
 <session name="S02" simple-binding-name="ejb/session/S02"/>
 <session name="S03">
  <interface class="com.ejbs.BankAccountService"
   binding-name="ejblocal:session/BAS"/>
  <ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
   binding-name="ejb/session/S02"/>
  <resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
   binding-name="jdbc/Default"/>
 </session>
 <message-driven name="MO1">
  <jca-adapter activation-spec-binding-name="jms/InternalProviderSpec"
   destination-binding-name=jms/"ServiceQueue"/>
 </message-driven>
 <session name="S04" simple-binding-name="ejb/session/S04">
  <resource-ref name="ejbs.S04Bean/dataSource"
   binding-name="jdbc/Default">
   <authentication-alias name="defaultlogin"/>
  </resource-ref>          </session>
 <session name="S05">
  <interface class="com.ejbs.InventoryService"
   binding-name="ejb/session/S05Inventory"/>
  <resource-ref name="ejbs.S05Bean/dataSource"
   binding-name="jdbc/Default">
   <custom-login-configuration name="customLogin">
    <property name="loginParm1" value="ABC123"/>
    <property name="loginParm2" value="DEF456"/>
   </custom-login-configuration>
  </resource-ref>          </session>
</ejb-jar-bnd>
Este enlace tiene los resultados siguientes:
  1. Los enlaces de interfaz de empresa, ubicación inicial y vista sin interfaz para los beans de sesión denominados S01, S02 y S03 no cambian respecto al ejemplo anterior.
  2. El bean de sesión cuyo ejb-name es S03 ahora incluye dos enlaces de resolución de destino de referencias:
    • El enlace ejb-ref resuelve la referencia EJB definida en java:comp/env/com.ejbs.BankAccountServiceBean/goodBye en la ubicación JNDI ejb/session/S02 dentro del contexto JNDI raíz del servidor de aplicaciones. La referencia EJB también la puede definir una inyección @EJB en la clase com.ejbs.BankAccountServiceBean, en una variable de instancia denominada "goodBye".
      Nota: ejb/session/S02 es la ubicación JNDI de bean de sesión S02 también definida en este mismo archivo de enlaces, lo que significa que la referencia apunta al bean de sesión cuyo nombre es S02.
    • El enlace resource-ref resuelve la referencia del recurso definida en java:comp/env/com.ejbs.BankAccountServiceBean/dataSource en la ubicación JNDI jdbc/Default. La referencia del recurso también podría haber sido definida por una inyección @Resource de la clase com.ejbs.BankAccountServiceBean en una variable de instancia denominada "dataSource".
  3. Se definen enlaces para un bean controlado por mensajes cuyo ejb-name es M01. MDB recibe los mensajes de un destino JMS definido en WebSphere Application Server, cuyo nombre JNDI es jms/ServiceQueue, utilizando un adaptador JCA 1.5 cuya especificación de activación JCA 1.5 se ha definido en WebSphere Application Server con el nombre jms/InternalProviderSpec.
  4. Se presupone que el bean de sesión cuyo ejb-name es S04 tiene una única interfaz de empresa o vista sin interfaz, enlazada en ejb/session/S04 si es remota o en ejblocal:ejb/session/S04 si es local. Tiene una referencia resource-ref con nombre, java:comp/env/ejbs/S04Bean/dataSource. También puede ser la clase, ejbs.S04Bean, con una inyección @Resource en una variable con nombre, dataSource. Esta referencia resource-ref se resuelve en la ubicación JNDI jdbc/Default. El elemento resource-ref hace referencia a una conexión J2C y se conecta a este recurso utilizando un alias de autenticación simple denominado defaultlogin que se ha definido en WebSphere Application Server.
  5. Se define un enlace de interfaz de empresa para la interfaz cuyo nombre de clase es com.ejbs.InventoryService implementada por el bean de sesión cuyo ejb-name es S05; se presupone que la interfaz es remota ya que no tiene el prefijo "ejblocal:" y, por lo tanto, puede enlazarse en ejb/session/S05Inventory en el contexto JNDI raíz del servidor en el espacio de nombres con ámbito global clásico. A las demás interfaces de empresa implementadas por este bean se les asignan enlaces clásicos predeterminados. Este bean tiene un resource-ref con nombre java:comp/env/ejbs.S05Bean/dataSource (o una inyección @Resource de la clase ejbs.S05Bean en una variable denominada "dataSource") que se resuelve en la ubicación JNDI jdbc/Default. El elemento resource-ref hace referencia a una conexión J2C y se conecta a este recurso utilizando una configuración de inicio de sesión personalizada que incluye dos pares de nombre-valor.

Ejemplo 3 de archivo de enlaces

Este ejemplo muestra cómo definir y resolver enlaces de referencias EJB para realizar búsquedas JNDI entre instancias de servidor de aplicaciones dentro de la misma célula de WebSphere Application Server. Utiliza dos beans EJB: un bean al que se llama que define un enlace explícito utilizando el atributo simple-binding-name y un bean que realiza la llamada que realiza una inyección @EJB y utiliza el elemento ejb-ref dentro de su archivo de enlaces asociado para resolver la referencia de forma que esta apunte al bean al que se llama, que reside en un proceso de servidor de aplicaciones distinto.

ibm-ejb-jar-bnd.xml (denominado bean)

<?xml version="1.0" encoding="UTF-8"?> 
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee" 
 "http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
 <session name="FacadeBean" simple-binding-name="ejb/session/FacadeBean"/> 
</ejb-jar-bnd>
Este contenido de archivo de enlaces supone que el bean de sesión cuyo ejb-name es "FacadeBean" implementa una única interfaz de empresa y, por lo tanto, el atributo simple-binding-name se puede utilizar como alternativa al subelemento <interface>. En este caso, FacadeBean implementa una única interfaz de empresa remota, enlazada en ejb/session/FacadeBean en el contexto JNDI raíz de servidor del servidor de aplicaciones donde reside FacadeBean.

Fragmento de código (denominado bean)

@EJB(name="ejb/FacadeRemoteRef") 	
FacadeRemote remoteRef; 	
try {
     output = remoteRef.orderStatus(input);
} 
catch(Exception e){
     // Handle exception, etc.
} 
Este fragmento de código realiza una inyección de recursos EJB en la variable de instancia denominada "remoteRef", que es de tipo FacadeRemote. La inyección altera temporalmente el parámetro "name", estableciendo el nombre de referencia ejb-ref resultante en ejb/FacadeRemoteRef. El código invoca un método de negocio en la referencia inyectada.

ibm-ejb-jar-bnd.xml (denominado bean)

<?xml version="1.0" encoding="UTF-8"?> 
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" 
 "xmlns:xsi="
 "http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee" 
 "http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
 <session name="CallingBean">     
  <ejb-ref name="ejb/FacadeRemoteRef" 
   binding-name="cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean"/>   
 </session> 
</ejb-bnd-jar>  
Finalmente, este archivo de enlace resuelve la referencia de EJB con un ejb-ref name de ejb/FacadeRemoteRef para apuntar al nombre clásico JNDI con ámbito global de cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean. Este nombre clásico JNDI de ámbito global representa una interfaz enlazada en ejb/session/FacadeBean bajo el contexto raíz del servidor denominado "S35serverA1" en el nodo denominado "S35NLA1" dentro de la célula de WebSphere Application Server del bean que realiza la llamada. Para apuntar a una ubicación dentro de una célula diferente de WebSphere Application Server, se puede utilizar un nombre de estilo CORBAName en lugar de un nombre JNDI estándar.

Las instrucciones acerca de cómo modificar el archivo ibm-ejb-jar-bnd.xml se pueden encontrar en el tema Formas de actualizar archivos de aplicación.

Relación entre inyecciones y referencias

Existe una correspondencia de una a una entre las directivas de inyección y las declaraciones de referencia (cada inyección define implícitamente una referencia de algún tipo, y, a la inversa, cada referencia puede también definir también una inyección). Puede pensar en una anotación de inyección como el mecanismo para definir referencias mediante anotaciones en lugar de definirlas en el descriptor de despliegue XML.

De forma predeterminada, una inyección define una referencia con un nombre formado a partir del nombre de clase calificada por el paquete del componente que realiza la inyección, una barra inclinada (/) y, a continuación, el nombre de la variable o propiedad en la que se inyecta. Por ejemplo, una inyección realizada en la clase com.ejbs.AccountService, en una variable o propiedad denominada "depositService", da como resultado una referencia denominada java:comp/env/com.ejbs.AccountService/depositService. La especificación, sin embargo, del parámetro opcional "name" en la directiva de inyección altera temporalmente este nombre predeterminado y hace que la referencia adopte un nombre según el valor del parámetro "name".

Si se conoce esta regla, es fácil ver cómo se puede utilizar un archivo de enlaces no solamente para resolver destinos de referencias declaradas en un descriptor de despliegue XML, sino también para resolver destinos de referencias declaradas implícitamente mediante una directiva de inyección de anotación. Utilice simplemente el valor del parámetro "name" en la anotación de inyección, o el nombre de referencia predeterminado del nombre de clase y el nombre de variable/propiedad si no se especifica ningún parámetro "name", como si fuera el nombre de la referencia declarada en un descriptor de despliegue XML.

Resolución predeterminada de referencias e inyecciones EJB: Características EJBLink y AutoLink

Las características EJBLink y AutoLink son dos mecanismos diferentes que resuelven referencias a los componentes EJB que se empaquetan en la misma aplicación y en el mismo proceso del servidor de aplicaciones que el componente que realiza la referencia. Tanto EJBLink como AutoLink evitan la necesidad de resolver explícitamente la referencia EJB con información de enlace. La característica EJBLink se define en la especificación EJB, mientras que la característica AutoLink es una extensión de WebSphere Application Server.

Las características EJBLink y AutoLink utilizan diferentes criterios de búsqueda para localizar el componente de bean de destino. EJBLink busca el componente de bean de destino utilizando el nombre de bean especificado de forma explícita. AutoLink busca el componente de bean de destino con la interfaz que el bean implementa. Si no se proporcionan enlaces explícitos, pero se proporciona un nombre de bean, se utiliza la característica EJBLink. Si no se proporcionan enlaces explícitos y no se proporciona un nombre de bean, se utiliza la característica AutoLink. Las características EJBLink y AutoLink nunca se utilizan juntas como parte del mismo proceso de búsqueda.

Excepto en los criterios de búsqueda, las características EJBLink y AutoLink son similares. Ambas características buscan un módulo específico en primer lugar y, a continuación, si es necesario, vuelven a buscar los demás módulos de la misma aplicación y el mismo proceso de servidor de aplicaciones. Ambas características requieren que los criterios de búsqueda se resuelvan exactamente en un componente de bean, y consideran como una condición de error que los criterios de búsqueda se resuelvan en varios componentes de bean. Existe una condición de error porque el servidor de aplicaciones no sabe cuál de los distintos componentes de bean se debe utilizar. En este caso, se produce la excepción com.ibm.websphere.ejbcontainer.AmbiguousEJBReferenceException. Esta excepción se genera en tiempo de ejecución cuando el componente de referencia intenta buscar el componente de bean de destino.

La característica EJBLink da soporte a tres formatos distintos.
  • Especifique solamente el nombre del componente del bean. Por ejemplo, MyBean.
  • Especifique el nombre del archivo del módulo físico, incluida la extensión, que contiene el componente de bean de destino, seguido del carácter #, seguido del nombre del componente del bean. Por ejemplo, myModule.jar#MyBean
  • Especifique el nombre lógico del módulo que contiene el componente de bean de destino, el carácter de barra inclinada (/), seguido del nombre del componente de bean. Por ejemplo, MyModule/MyBean.

Puede especificar opcionalmente el nombre lógico del módulo utilizando el elemento de nombre de módulo en el descriptor de despliegue EJB para un módulo ejb-jar, o puede utilizar el elemento de nombre de módulo en el archivo del descriptor de despliegue web de un módulo WAR con contenido EJB. Para un módulo WAR que contiene el contenido de EJB, el elemento módulo-name especificado en el descriptor de despliegue EJB se ignora y el elemento module-name especificado en el descriptor de despliegue web se procesa. Si no se especifica ningún valor de module-name en el descriptor de despliegue, se asigna un nombre lógico predeterminado al módulo. El nombre del módulo lógico predeterminado es el nombre base del archivo del módulo, menos la extensión. Por ejemplo, el archivo del módulo, MyModule.jar, tiene el nombre del módulo lógico predeterminado MyModule.

Todavía se da soporte a la acción de especificar le nombre del archivo de módulo físico aunque el módulo tenga un nombre lógico. Se da soporte también a la acción de especificar el nombre lógico del módulo aunque no se haya configurado ningún nombre de módulo lógica en el descriptor de despliegue. En este caso, el nombre base del módulo se utiliza como nombre lógico del módulo.

El contenedor EJB incorporable admite todos los formatos EJBLink. Para dar soporte al formato de archivo físico del módulo, el contenedor EJB incorporable no le permite iniciar varios módulos con el mismo nombre base.

AutoLink es una característica de valor añadido de WebSphere Application Server que elimina la necesidad de resolver explícitamente destinos de referencias EJB en determinados escenarios de uso. En WebSphere Application Server V8, AutoLink se implementa dentro de los límites de cada proceso de WebSphere Application Server. El algoritmo de AutoLink funciona de la forma siguiente.

Cuando el contenedor EJB del producto encuentra una referencia EJB dentro de un módulo EJB determinado, primero comprueba si se ha resuelto explícitamente el destino de esa referencia mediante la inclusión de una entrada en el archivo de enlace del módulo. Si no encuentra ninguna resolución explícita del destino en el archivo de enlaces, el contenedor busca dentro del módulo que realiza la referencia un enterprise bean que implemente el tipo de interfaz o la vista sin interfaz que se ha definido dentro de la referencia.

Si encuentra exactamente un solo enterprise bean dentro del módulo que implementa la interfaz o la vista sin interfaz, utiliza ese enterprise bean como destino de la referencia EJB. Si el contenedor no puede localizar un enterprise bean de ese tipo dentro del módulo, expande el ámbito de búsqueda a la aplicación de la que forma parte el módulo y busca en otros módulos de esa aplicación asignados al mismo servidor de aplicaciones que el módulo que realiza la referencia. De nuevo, si el contenedor encuentra exactamente un solo enterprise bean que implementa la interfaz de destino o la vista sin interfaz, dentro del otro módulos de la aplicación asignado al mismo servidor como módulo que realiza la referencia, utiliza ese enterprise bean como destino de la referencia.

El ámbito de AutoLink se limita a la aplicación en la que aparece la referencia EJB y al servidor de aplicaciones en el que está asignado el módulo que realiza la referencia. Las referencias a enterprise beans en una aplicación diferente, a enterprise beans en un módulo asignado a un servidor de aplicaciones diferente o a enterprise beans que residen en un módulo asignado a un clúster de WebSphere Application Server se deben resolver explícitamente utilizando los enlaces de destino de referencia del archivo ibm-ejb-jar-bnd.xml del módulo EJB o del archivo ibm-web-bnd.xmi del módulo web.

Es importante tener en cuenta que solamente se da soporte a AutoLink para referencias EJB, no para otros tipos de referencias aunque recibe soporte desde el contenedor EJB, el contenedor web y el contenedor del cliente de aplicaciones. Además, debido a que el ámbito de la función AutoLink está limitado al servidor al que está asignado el módulo que realiza la referencia o, en el caso del contenedor de clientes Java EE, al servidor donde el contenedor de clientes está configurado como servidor de programa de arranque JNDI, es útil principalmente en entornos de desarrollo y otros escenarios de uso de servidor único. Incluso si se tienen presentes estas limitaciones, puede ser una valiosa ayuda durante la experiencia del desarrollo eliminando la necesidad de resolver explícitamente las referencias EJB.

Resolución de EJB y de las referencias de recursos e inyecciones: la característica de búsqueda

La característica de búsqueda se define en la especificación EJB 3.1 como un mecanismo que resuelve las referencias a los EJB o recursos, por un nombre JNDI explícito. Puede especificar el atributo lookup en la anotación javax.ejb.EJB o en la anotación javax.annotation.Resource. El atributo XML correspondiente en el archivo ejb-jar.xml es <lookup-name>, en uno de los elementos siguientes: <ejb-ref>, <ejb-local-ref>, <env-entry>, <resource-ref>, <resource-env-ref> o <message-destination-ref>. lookup o <lookup-name> es un nombre JNDI relativo al contexto de denominación java:comp/env.

En una referencia EJB, no se debe especificar lookup ni <lookup-name> con beanName o <ejb-link>. La consola administrativa muestra lookup-name y ejb-link como de sólo lectura. No obstante, si se especifica un nombre JNDI en el paso de instalación de aplicación "Correlacionar referencias de EJB con beans", se alterará temporalmente el valor de lookup-name o ejb-link.

Alteración temporal de entradas de entorno definidas en aplicaciones

Las aplicaciones pueden definir entradas de entorno con valores que son adecuados para pruebas unitarias, pero no para la prueba de integración o el uso de producción. Si desea alterar temporalmente un valor de entrada de entorno, puede añadir el elemento siguiente al archivo de enlace correspondiente:
<env-entry name="nombre" value="valor"/
donde nombre es el nombre env-entry tal como se ha definido en la aplicación y valor es el valor asignado al env-entry representado en formato de serie. La serie para valor se analiza de acuerdo con el tipo de la entrada de entorno como si el valor se hubiera especificado en el descriptor de despliegue utilizando env-entry-value. Por ejemplo,
<env-entry name="java:module/env/taxYear" value="2010"/>
asocia el env-entry denominado "java:module/env/taxYear" con un valor de "2010".
Como alternativa, puede configurar un env-entry como referencia a otro objeto accesible a través de JNDI. El objeto devuelto de la búsqueda JNDI se utiliza como el valor de env-entry. El elemento para esa opción tiene el formato siguiente:
<env-entry name="nombre" binding-name="nombreBúsqueda"/>
donde nombre es el nombre env-entry como se define en la aplicación y nombreBúsqueda es un nombre JNDI que se resuelve cuando se aplica a una búsqueda en el contexto inicial predeterminado. Por ejemplo,
<env-entry name="java:module/env/taxYear" binding-name="cell/persistent/MyApp/MyModule/taxYear"/>
asocia el env-entry denominado "java:module/env/taxYear" con un valor devuelto de una operación de búsqueda de contexto inicial predeterminada en "cell/persistent/MyApp/MyModule/taxYear". Es responsable de crear el enlace de objeto JNDI. La clase del objeto enlazado debe ser asignable al tipo de objeto del env-entry asociado.

Las entradas de entorno se pueden definir a nivel de aplicación y en módulos EJB, web y de cliente. Esos niveles corresponden a los archivos de enlace application-bnd.xml, ejb-jar-bnd.xml, web-app-bnd.xml y application-client-bnd.xml.

Alteración temporal de definiciones de origen de datos

Con Java EE 6, puede desarrollar aplicaciones que definen los orígenes de datos utilizando la anotación @DataSourceDefinition o la entrada de descriptor de despliegue <data-source>.

Las aplicaciones debe buscar referencias de recursos en lugar de buscar las definiciones de origen de datos directamente. Si está instalando una aplicación existente que contiene búsquedas directas en una definición de origen de datos y desea que éstas utilicen otra definición de origen de datos, puede alterar temporalmente la definición de origen de datos con un enlace que se resuelve en el recurso gestionado que crea. Cree el enlace añadiendo el elemento siguiente al archivo de enlace:
<data-source name="nombre" binding-name="nombreBúsqueda"/> 
donde nombre es el nombre env-entry como se define en la aplicación y nombreBúsqueda es un nombre JNDI que se resuelve cuando se aplica a una búsqueda en el contexto inicial predeterminado. Por ejemplo,
<data-source name="java:module/env/myDS" binding-name="jdbc/DB2DS"/>
hace que las búsquedas en "java:module/env/myDS" se resuelvan en el origen de datos enlazado con el nombre, "jdbc/DB2DS", relativo al contexto inicial predeterminado. El origen de datos enlazado bajo jdbc/DB2DS se puede crear, por ejemplo, a través de la consola administrativa.

Los orígenes de datos se pueden definidos a nivel de aplicación y en módulos EJB, web y de cliente. Esos niveles corresponden a los archivos de enlace application-bnd.xml, ejb-jar-bnd.xml, web-app-bnd.xml y application-client-bnd.xml.

Consideraciones de denominación en entornos en clústeres y entre servidores

Los convenios de denominación JNDI globales clásicos de las secciones anteriores se aplican en entornos que no son en clúster y cuando el destino de búsqueda está dentro del mismo clúster que el origen de la búsqueda. Cuando se realiza una búsqueda desde fuera de un clúster en un enlace que está dentro de un clúster determinado, la serie de búsqueda debe estar calificada para indicar el nombre del clúster en el que reside el destino, según el convenio siguiente:
cell/clusters/<nombre-clúster>/<ubicación-enlace-nombres>    
Por ejemplo, en el caso de una ubicación de enlace de interfaz EJB dentro del contexto raíz del servidor de aplicaciones:
ejb/Department549/AccountProcessors/CheckingAccountReconciler 
Si el EJB que implementa esta interfaz se asigna a un servidor de aplicaciones que es un miembro de un clúster denominado Cluster47, la serie de búsqueda externa a ese clúster tendrá la forma siguiente:
cell/clusters/Cluster47/ejb/Department549/AccountProcessors/CheckingAccountReconciler  
Cuando se realiza una búsqueda entre procesos de servidor de aplicaciones, la serie de búsqueda debe estar calificada para indicar el nombre del nodo y servidor donde reside el destino, según el convenio siguiente:
cell/nodes/<nombre-nodo>/servers/<nombre-servidor>/<ubicación
del enlace de nombres> 
De nuevo, en el caso de una ubicación de enlace de interfaz EJB dentro del contexto raíz del servidor de aplicaciones:
ejb/Department549/AccountProcessors/CheckingAccountReconciler 
Si el enterprise bean que implementa esta interfaz se asigna a un servidor de aplicaciones denominado Server47A1 ubicado en un nodo denominado S47NLA1, la serie de búsqueda entre servidores tendrá la forma siguiente:
cell/nodes/S47NLA1/servers/Server47A1/ejb/Department549/AccountProcessors/CheckingAccountReconciler 

Valores de extensión EJB definidos por el usuario

En los casos en los que desee especificar valores de extensión EJB de WebSphere Application Server, puede utilizar un archivo de extensión de módulo EJB para asignar estos valores a tipos EJB específicos en dicho módulo. Especifique la información de valores de extensión para los módulos EJB 3.x poniendo uno o los dos archivos en el directorio META-INF para el archivo JAR EJB, en función del tipo de extensión que se esté definiendo. Los nombres de los dos archivos son ibm-ejb-jar-ext.xml y ibm-ejb-jar-ext-pme.xml.

Nota: El sufijo de estos archivos es XML, no XMI como en versiones anteriores de WebSphere Application Server.
Los archivos ibm-ejb-jar-ext.xml i ibm-ejb-jar-ext-pme.xml se utilizan para los módulos EJB 3.x que se ejecutan en WebSphere Application Server, mientras que los archivos ibm-ejb-jar-ext.xmi e ibm-ejb-jar-ext-pme.xmi se utilizan para los módulos EJB anteriores a la versión 3.0. La versión 8.0 de WebSphere Application Server utiliza un formato de archivo de extensión nuevo basado en XML en lugar del formato de archivo .xmi anterior por los motivos siguientes:
  1. Los enlaces y las extensiones declarados en el formato de archivo xmi dependen de la presencia de un archivo de descriptor de despliegue ejb-jar.xml correspondiente, que hace referencia explícitamente a números de ID exclusivos adjuntados a elementos de ese archivo. Este sistema ya no es viable para módulos EJB 3.0 y posteriores, donde ya no es necesario que el módulo contenga un descriptor de despliegue ejb-jar.xml.
  2. El formato de archivo xmi se diseñó para que pudiera ser editado por la máquina sólo por parte de las funciones de gestión del sistema y las herramientas de desarrollo de WebSphere; era una parte efectiva de la implementación interna de WebSphere y la estructura del archivo no se documentaba nunca externamente. Posibilitaba que los desarrolladores crearan o editaran manualmente archivos de enlaces o de extensión o los crearan como parte de un proceso de compilación independiente de WebSphere de manera soportada.
  3. En lugar de hacer referencia a números de ID codificados en ejb-jar.xml, el formato de archivo de extensión basado en XML hace referencia a componentes EJB por su nombre de EJB. Se garantiza que cada componente EJB de un módulo tenga un nombre de EJB exclusivo, ya sea de forma predeterminada o mediante la asignación explícita por parte del desarrollador, de forma que se proporciona una forma inequívoca de hacer referencia a enlaces y extensiones.
  4. Los nuevos formatos de archivo de enlaces y extensión son archivos XSD (SML Schema Definition) basados en XML se proporcionan para documentar externamente la estructura. Estos archivos .xsd pueden ser consumidos por muchos editores de archivos XML comunes como ayuda en las funciones de verificación sintáctica y finalización de código. Como resultado, ahora los desarrolladores pueden producir y editar los archivos de enlaces y extensiones independientemente de la infraestructura de WebSphere Application Server, mediante el editor XML o sistema de scripts genérico que deseen.

Extensiones definidas en el archivo META-INF/ibm-ejb-jar-ext.xml

En la tabla siguiente, se muestran los elementos y atributos de extensión que deben colocarse en el archivo META-INF/ibm-ejb-jar-ext.xml. En la sección siguiente, se muestran los elementos y atributos que aparecen en un archivo diferente, META-INF/ibm-ejb-jar-ext-pme.xml.
Tabla 4. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml
Elemento o atributo Descripción Ejemplo Notas de uso
<session> Declara un grupo de valores de asignación para un bean de sesión.
<session name="AccountServiceBean"/>
Requiere el atributo name. Para que se aplique, incluya también un subelemento de definición de valor de extensión.
<message-driven> Declara un grupo de valores de asignación para un bean controlado por mensaje.
<message-driven name="EventProcessorBean"/>
Requiere el atributo name. Para que se aplique, incluya también un subelemento de definición de valor de extensión.
Tabla 5. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml
Elemento o atributo Descripción Ejemplo Notas de uso
<time-out> Subelemento del elemento <session> que declara opcionalmente el número de segundos entre la invocaciones de método después de las cuales un bean de sesión con estado puede dejar de estar disponible.
<session
 name="ShoppingCartBean">
 <time-out value="600"/>
</session>
Requiere el atributo value, un entero positivo.
Nota: Sólo se aplica a los beans de sesión con estado; no debe utilizarse en beans sin estado.

Valor predeterminado del atributo: 300 (5 minutos)

<bean-cache> Subelemento del elemento <session> utilizado para declarar valores de activación/desactivación de bean para beans de sesión con estado.
<session
 name="ShoppingCartBean">
 <bean-cache
  activation-policy="TRANSACTION"/>
</session>
Para que se aplique, incluya también el atributo activation-policy.
activation-policy Atributo del elemento <bean-cache> que declara las condiciones según las cuales la instancia del bean se puede activar y desactivar. Aplicable a todos los beans de sesión con estado. Los valores permitidos y sus significados son:
  • TRANSACTION: indica que el bean se activa al inicio de una transacción y se desactiva (y se elimina de la memoria caché de la instancia EJB activa) al final de la transacción.
  • ONCE: indica que el bean se activa la primera vez que se accede al mismo en el proceso del servidor y se desactiva ( y se elimina de la memoria caché de la instancia EJB activa) según el criterio del contenedor, por ejemplo, cuando la memoria caché se llena.
  • ACTIVITY_SESSION: indica que el bean se activa y desactiva como se indica a continuación:
    1. En un límite de ActivitySession, si existe un contexto de ActivitySession en la activación
    2. En un límite de transacciones, si un contexto de transacción está presente en la activación( pero no lo está un contexto de sesión de actividad) o
    3. en un límite de invocación.
<session
 name="ShoppingCartBean">
 <bean-cache
  activation-policy="ONCE"/>
</session>
Valor predeterminado de atributo: ONCE para beans de sesión con estado.
Tabla 6. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml
Elemento o atributo Descripción Ejemplo Notas de uso
<global-transaction> Subelemento de los elementos <session> y <message-driven> que se puede utilizar para declarar el tiempo de espera superado de la transacción (en segundos) que debe utilizarse en las transacciones iniciadas por este tipo de EJB específico (alterando temporalmente el valor del servidor del tiempo de espera superado de la transacción global) y también puede declarar si este tipo de EJB propaga el contexto de la transacción global recibido a través de transacciones atómicas de servicio web, en todo el entorno de servicio web heterogéneo.
<session
 name="AccountServiceBean"
 <global-transaction
  <global-transaction
 transaction-time-out="180" 
  send-wsat-context="FALSE"/>
</session>
Requiere al menos uno de los atributos transaction-time-out o send-wsat-context.

Valor predeterminado de atributo: valor de tiempo de espera de transacción Server para transaction-time-out; FALSE para send-wsat-context

<local-transaction> Subelemento de los elementos <session> y <message-driven> que se puede utilizar para declarar valores relacionados con las transacciones locales. Los atributos soportados son boundary, resolver y unresolved-action: estos atributos configuran, para el componente, el comportamiento del entorno de contención de transacciones locales (LTC) del contenedor que el contenedor establece cuando no está presente una transacción global. El significado de cada atributo es el siguiente:

Boundary

Este valor especifica el límite de contención en el que deben llevarse a cabo todas las transacciones locales del gestor de recursos (RMLT) incluidas. Valores posibles:
  • BEAN_METHOD: es el valor predeterminado. Si selecciona esta opción, las RMLT se deben resolver dentro del mismo método de bean en el que se iniciaron.
  • ACTIVITY_SESSION: las RMLT deben resolverse dentro del ámbito de las sesiones de actividades donde se hayan iniciado o, si no hay ningún contexto de sesión de actividad, dentro del mismo método de bean en el que se iniciaron.

Resolver

Este valor especifica el componente responsable de iniciar y finalizar las RMLT. Valores posibles:
  • APPLICATION: es el valor predeterminado. La aplicación es responsable de iniciar las RMLT y de completarlas dentro del límite de contenedor de transacciones locales (LTC). El contenedor elimina todas las RMLT que se hayan completado al final del límite de LTC de acuerdo con el valor del atributo Acción no resuelta.
  • CONTAINER_AT_BOUNDARY: el contenedor es responsable de iniciar las RMLT y de completarlas dentro del limite de LTC. El contenedor empieza un RMLT cuando se utiliza una conexión por primera vez dentro del ámbito de LTC y la completa automáticamente al final del ámbito de LTC. Si Límite se establece como Sesión de actividad, las RMLT se incluyen como recursos de Sesión de actividad y se dirigen a que las finalice la Sesión de actividad. Si Límite se establece en Método de bean, el contenedor compromete las RMLT al final del método.

Unresolved Action

Este valor especifica la dirección que tomarán las RMLT de solicitudes de contenedor si dichas transacciones están sin resolver al final del ámbito de límite de LTC y el Solucionador se establece en Aplicación. Valores posibles:
  • ROLLBACK: es el valor predeterminado. Al final del ámbito del límite de LTC, el contenedor indica a todas las RMLT sin resolución que se retrotraigan.
  • COMMIT: al final del ámbito del límite de LTC, el contenedor indica a todas las RMLT sin resolución que se comprometan. El contenedor indicará a las RMLT que se confirmen sólo si no hay ninguna excepción no manejada. Si el método de aplicación que se ejecuta bajo el contexto de transacción local finaliza con una excepción, el contenedor retrotraerá todas las RMLT sin resolver. Este es el mismo comportamiento que para las transacciones globales.
<session
 name>="AccountServiceBean">
 <local-transaction
  boundary="BEAN_METHOD"
  resolver="APPLICATION" 
  unresolved-action="ROLLBACK"/>
</session>
Requiere al menos uno de los atributos boundary, resolver o unresolved-action .
Valor predeterminado de atributo:
boundary="BEAN_METHOD"; 
resolver="APPLICATION"; 
unresolved-action=
"ROLLBACK"
Tabla 7. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml. Elementos y atributos del archivo META-INF/ibm-ejb-jar-ext.xml
Elemento o atributo Descripción Ejemplo Notas de uso
<method> Subelemento de los elementos <method-session-attribute> y <run-as-mode> que se utiliza para especificar el nombre del método, la firma del método o los tipos de método para los que se puede aplicar un valor determinado. Los atributos soportados son type, name y params. Cada atributo se describe de la manera siguiente:

tipo

  • UNSPECIFIED: el valor se aplica a todos los métodos que coinciden con los atributos name y params, independientemente del tipo de interfaz.
  • REMOTE: el valor se aplica a los métodos de interfaz de empresa remota y de interfaz de componentes remota que coincidan con los atributos name y params.
  • LOCAL: el valor se aplica a la interfaz de empresa local, los métodos de interfaz de componente local y las vistas sin interfaz que coinciden con el atributo name, params o ambos.
  • HOME: el valor se aplica a los métodos de interfaz de factoría remota que coincidan con los atributos name y params que coincidan con los atributos name y params.
  • LOCAL_HOME: el valor se aplica a los métodos de interfaz inicial local que coinciden con los atributos name y params.
  • SERVICE_ENDPOINT: el valor se aplica a los métodos de la interfaz de punto final de servicio JAX-RPC que coincidan con los atributos name y params.

nombre

El nombre del método al que se aplicará el valor, o un asterisco (*) si el valor debe aplicarse a todos los métodos independientemente del nombre.

params

Firma del parámetro del método al que se aplica el valor. Ésta se puede utilizar para cualificar de forma exclusiva un método determinado en los casos en los que varios métodos utilizan el mismo nombre. La firma de parámetro es una lista de tipos Java separados por comas. Los tipos primitivos se especifican utilizando sólo el nombre; los tipos no primitivos se especifican utilizando la clase totalmente calificada o el nombre de interfaz, incluido cualquier paquete Java, y las matrices de tipos Java se especifican mediante el tipo del elemento de matriz seguido por uno o varios pares de corchetes (por ejemplo int[][]).

<session
 /name="AccountServiceBean">
 <method-session-attribute
  type="REQUIRES_NEW">
 <method
  type="LOCAL"
  name="debitAccount" 
  params="java.lang.String[], int, 
     com.xyz.CustomerInfo"/>
 </method-session-attribute;>
</session>
 
<run-as-mode> El subelemento de los elementos <session> y <message-driven> se puede utilizar para declarar la identidad de seguridad que un método EJB determinado utilizará al invocar otro método. La identidad se puede establecer para utilizar la identidad del interlocutor (modo = CALLER_IDENTITY), la identidad del servidor EJB (modo = SYSTEM_IDENTITY) o la identidad de un rol de seguridad específico (modo = SPECIFIED_IDENTITY).
<session
 name="AccountServiceBean">
 <run-as-mode
   mode="SPECIFIED_IDENTITY">
 <specified-identity
   role="admin"/>
 <method type="UNSPECIFIED" 
   name="testRunAsRole"/>
 </run-as-mode>
</session>
Requiere el atributo de modalidad y el subelemento <method>. Si el modo es SPECIFIED_IDENTITY, el subelemento <specified-identity también será necesario.
<start-at-app-start> Subelemento de los elementos <session> y <message-driven> que se puede utilizar para informar al contenedor EJB que el tipo de EJB especificado se iniciará la primera vez que se inicie la aplicación, en lugar de cuando la aplicación utilice el tipo EJB por primera vez.
<session
 name="AccountServiceBean">
 <start-at-app-startvalue="TRUE"/>
</session>
Requiere el atributo value.

Valor predeterminado de atributo: FALSE (inicializar el tipo EJB cuando la aplicación utiliza EJB por primera vez) para beans distintos de los beans controlados por mensaje. Siempre TRUE para beans controlados por mensaje.

<resource-ref> Subelemento de los elementos <session> y <message-driven>, que se puede utilizar para declarar valores adicionales en una referencia de recurso Java EE, por ejemplo el nivel de aislamiento que se debe utilizar en transacciones controladas mediante la conexión referida por la referencia. Los atributos permitidos incluyen isolation-level. Los atributos se definen de la forma siguiente:
isolation-level
  • TRANSACTION_REPEATABLE_READ: este nivel de aislamiento prohíbe lecturas no permitidas y no repetibles, pero permite las lecturas fantasma.
  • TRANSACTION_READ_COMMITTED: este nivel de aislamiento prohíbe las lecturas no permitidas, pero permite las lecturas no repetibles y las fantasma.
  • TRANSACTION_READ_UNCOMMITTED: este nivel de aislamiento permite leer cambios no comprometidos (datos cambiados por una transacción diferente que sigue estando en proceso). También permite lecturas no permitidas, no repetibles y fantasma.
  • TRANSACTION_SERIALIZABLE: este nivel de aislamiento prohíbe los siguientes tipos de lecturas:
    1. Lecturas sucias, en las que una transacción lee una fila de base de datos que contiene cambios no confirmados de una segunda transacción,
    2. Lecturas no repetibles, en las que una transacción lee una fila, una segunda transacción cambia la misma fila y la primera transacción vuelve a leer la fila y obtiene un valor diferente, y
    3. Lecturas fantasma, en las que una transacción lee todas las filas que satisfacen una condición WHERE de SQL, una segunda transacción inserta una fila que también satisface la condición WHERE y la primera transacción aplica la misma condición WHERE y obtiene la fila insertada por la segunda transacción.
  • TRANSACTION_NONE: este nivel de aislamiento indica que las transacciones no se admiten en este tipo de recurso.
<session
 name="AccountServiceBean">
 <resource-ref
  name="jdbc/Default" 
  isolation-level="TRANSACTION_NONE">
</session>
Requiere el atributo name. Para que se aplique, incluya también el atributo isolation-level.

Extensiones definidas en el archivo META-INF/ibm-ejb-jar-ext-pme.xml

Las tablas siguientes listan los elementos y atributos de extensión que se deben poner en el archivo META-INF/ibm-ejb-jar-ext-pme.xml.
Tabla 8. Extensiones definidas en META-INF/ibm-ejb-jar-ext-pme.xml. Extensiones definidas en META-INF/ibm-ejb-jar-ext-pme.xml
Elemento o atributo Descripción Ejemplo Notas sobre la utilización
<internationalization> Elemento que se puede utilizar para declarar el entorno local el tipo de EJB puede utilizar (entorno local del llamante o entorno local del servidor).
<internationalization>  <application>
   <ejb name="S01"/>
   <ejb name="S02"/>
  </application>
  <run-as-caller>
   <method type="LOCAL" name="getFoo" params="int">
     <ejb name="C01"/>
   </method>
  </run-as-caller>
  <run-as-server>
   <method type="LOCAL" name="getBar" params="int">
    <ejb name="C02"/>
   </method>
  </run-as-server>
  <run-as-specified name="North American English">
   <locale lang="en" country="US" variant="foo"/>
   <locale lang="en" country="CA" variant="bar" /> 
   <time-zone name="GMT"/> 
   <method type="LOCAL" name="getFoo" params="int"> 
    <ejb name="C03"/>
   </method>
  </run-as-specified>
  <run-as-specified name="North American French"> 
   <locale lang="fr" country="US" variant="foo"/>
   <locale lang="fr" country="US" variant="bar" /> 
   <time-zone name="GMT"  /> 
   <method type="LOCAL" name="getBar" params="int"> 
   <ejb name="C04"/>
   </method>
  </run-as-specified>
</internationalization>
Para obtener información sobre esta extensión, consulte los atributos de internacionalización del contenedor: WebSphere Application Server.

Debido a la complejidad de esta función, es aconsejable utilizar una herramienta diseñada para WebSphere Application Server, por ejemplo Rational Application Developer, para producir las stanzas de archivo de extensión deseadas y, a continuación, modificar el archivo XML como se desee.

<activity-sessions> Elemento que declara, de manera opcional, el tipo de gestión de sesiones de la actividad que debe utilizarse en un bean de sesión designado (BEAN o CONTAINER) y para sesiones de actividad gestionadas por contenedor, el tipo de comportamiento de la sesión de la actividad que debe proporcionar el contenedor.
<activity-sessions> <container-activity-session 
  name="Foo" type="NOT_SUPPORTED">
  <methodtype="HOME" name="findByPrimaryKey" 
    params="int">
   <ejb name="C01"/>
  </method>
 </container-activity-session>
<./activity-sessions>
Para obtener información sobre esta extensión, consulte Establecimiento de atributos de despliegue ActivitySession de módulo EJB.

Debido a la complejidad de esta función, es aconsejable utilizar una herramienta diseñada para WebSphere Application Server, por ejemplo Rational Application Developer

<app-profiles> Elemento que declara opcionalmente los valores de perfil de aplicación para uno o varios archivos EJB.
<app-profiles> <defined-access-intent-policy name="foo">
  <collection-scope type"SESSION"/>
  <optimistic-read/>
  <read-ahead-hint hint="foo.bar.baz"/>
 </defined-access-intent-policy>
 <run-as-task 
  name="TestEJB1.ejbs.C01LocalHome.createjava.lang.Integer" 
  type="RUN_AS_SPECIFIED_TASK">
  <task name=“/>
  <method type="LOCAL" name="getFoo" params="int">
   <ejb name="C01"/>
  </method>
 </run-as-task>
 <ejb-component-extension ejb="C01"> 
  <task name="SomeTask"/>
 </ejb-component-extension>
</app-profiles>
Debido a la complejidad de esta función, es aconsejable utilizar una herramienta diseñada para WebSphere Application Server, por ejemplo Rational Application Developer, para producir las stanzas de archivo de extensión deseadas y, a continuación, modificar el archivo XML como se desee.

Enlaces heredados (XMI)

Los módulos y las aplicaciones existentes pueden continuar utilizando el soporte de enlaces heredados proporcionado en el producto y, por lo tanto, se pueden utilizar las herramientas y los asistentes existentes para especificar información de enlaces y extensiones para aplicaciones y módulos. La utilización del soporte heredado se limita a los archivos EAR y a los módulos que utilizan descriptores de despliegue XML de estilo J2EE 1.4.

Los módulos EJB que utilizan un esquema de descriptor de despliegue XML de la versión 3.x o que no tienen un archivo de descriptor de despliegue XML deben utilizar los enlaces predeterminados y AutoLink, o bien archivos de enlaces XML especificados por el usuario.

Es necesario que los beans de entidad CMP estén siempre empaquetados en un módulo con una versión de esquema de descriptor de despliegue XML 2.1, de forma que se puedan utilizar las herramientas existentes para proporcionar correlaciones, enlaces y soporte de ampliación.

Enlaces XML especificados por el usuario

Los enlaces predeterminados para cada interfaz y la resolución de referencias de AutoLink para cada referencia se pueden alterar temporalmente mediante la especificación de enlaces para el módulo EJB creando un archivo META-INF/ibm-ejb-jar-bnd.xml.

Los archivos de esquema que describen el formato están ubicados en el directorio <WAS_HOME>/properties/schemas. Esta forma de especificación de enlaces solamente se puede utilizar para módulos que no contienen un descriptor de despliegue XML o un descriptor de despliegue EJB 3.x.
Nota: No es necesario especificar todos los enlaces. Los nombres de enlaces o referencias que no estén definidos utilizarán los enlaces predeterminados y el soporte de AutoLink.
Se pueden especificar enlaces para los siguientes beans:
  • Beans de sesión que utilizan el elemento <session>.
  • Beans controlados por mensajes que utilizan elemento <message-driven>
Los únicos atributos y subelementos soportados para el elemento <session> son los siguientes:
  • El atributo id
  • El atributo name
  • El atributo simple-binding-name
  • El atributo component-id
  • El elemento ejb-ref
  • El elemento resource-ref y sus atributos
  • El elemento resource-env-ref y sus atributos
  • El elemento message-destination-ref y sus atributos
  • El elemento env-entry
  • El elemento data-source
Los únicos atributos y subelementos soportados para el elemento <message-driven> son:
  • El atributo id
  • El atributo name
  • El atributo jca-adapter
  • El elemento ejb-ref y sus atributos
  • El elemento resource-ref y sus atributos
  • El elemento resource-env-ref y sus atributos
  • El elemento message-destination-ref y sus atributos
  • El elemento env-entry
  • El elemento data-source

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_bindingsejbfp
File name: cejb_bindingsejbfp.html