Utilización de enterprise JavaBeans con interfaces remotas en Liberty

Puede acceder de forma remota a métodos Enterprise Java™ Bean (EJB) con interfaces remotas cuando el EJB lo aloja otra máquina virtual Java (JVM) u otra aplicación en la misma JVM. WebSphere® Application Server implementa interfaces EJB remotas utilizando tecnologías RMI-IIOP. Puede habilitar el soporte de EJB remoto con la característica ejbRemote-3.2.

Acerca de esta tarea

Para configurar un servidor Liberty para que ejecute una aplicación con el soporte EJB remoto habilitado, debe establecer la característica ejbRemote-3.2.

Cuando utilice interfaces EJB remotas, revise las consideraciones siguientes:

Denominación

Utilizando el espacio de nombres java:

La especificación EJB requiere que las interfaces remotas estén enlazadas con el espacio de nombres java:; por ejemplo:
java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface
java:app/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface
java:module/ExampleBean!com.ibm.example.ExampleRemoteInterface

Los componentes EJB no están vinculados con el espacio de nombres JNDI (Java Naming and Directory Interface) predeterminado como en WebSphere Application Server tradicional, por lo que las búsquedas de @EJB y los enlaces en los archivos ibm-*-bnd.xml no deben utilizar este espacio de nombres. Estas búsquedas deben utilizar los nombres java: para los componentes EJB que están alojados en el mismo servidor y los URL corbaname: para los componentes EJB que están alojados en otro servidor.

Utilizando los URL corbaname:
Las interfaces también se enlazan con el servicio de nombres CosNaming de ORB en contextos similares a los de las interfaces utilizadas en el espacio de nombres java:global. Se puede acceder a estas interfaces a través de JNDI mediante los URL corbaname:; por ejemplo:
corbaname::test.ibm.com:2809#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome
corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome

En el servidor, el formato rir: de los URL utiliza el servicio de nombre local. En el cliente, utiliza el servicio de nombres remoto predeterminado o configurado.

Escape de los URL corbaname:

Según la especificación de servicio de denominación de OMG (Object Management Group), algunos caracteres de los URL corbaname: deben escribirse con caracteres de escape. Liberty intenta determinar si un URL corbaname: que se ha derivado del espacio de nombres java:global necesita especificarse con caracteres de escape y, en ese caso, se hace automáticamente. No es posible realizar siempre esta acción. Por ejemplo, si un nombre contiene un solo punto (.), y no tiene caracteres no válidos, no se pueden especificar caracteres de escape automáticamente. Para forzar que un nombre se interprete de una forma en particular, es necesario escribir con caracteres de escape el URL manualmente tal como se describe en Especificación del servicio de denominación de OMG.

Tenga en cuenta el siguiente nombre java:global para un enterprise bean:
java:global/TestApp/TestModule/TestBean!test.TestRemoteInterface
El formato simple del URL corbaname: no se puede omitir automáticamente porque representa una ubicación diferente pero válida. Por lo tanto, el URL siguiente no funciona como se esperaba:
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test.TestRemoteInterface
En su lugar, este URL se deberá omitir manualmente tal como se indica a continuación:
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface

La sintaxis para escribir con carácter de escape los URL corbaname: se define absolutamente en Especificación del servicio de denominación de OMG.

Utilización de nombres JNDI de forma programática
Todos los URL y nombres JNDI de estos ejemplos se pueden buscar de forma programática a partir del valor InitialContext. Cuando se busca un nombre java:, el objeto resultante se puede convertir directamente en el tipo esperado; por ejemplo:
Object found = new InitialContext().lookup("java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface");
ExampleRemoteInterface bean = (ExampleRemoteInterface) found;
Sin embargo, cuando se recuperan objetos utilizando los URL corbaname:, se debe utilizar el estilo de conversión RMI, denominado narrowing, por ejemplo:
Object found = new InitialContext().lookup("corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface");
ExampleRemoteInterface bean = (ExampleRemoteInterface)PortableRemoteObject.narrow(found, ExampleRemoteInterface.class);
Interoperatividad
Cualquier producto que admita el protocolo IIOP puede invocar a enterprise beans que utilicen el modelo de programación remoto EJB 2.x con EJBHome y EJBObject cuando se empaqueta en un módulo JAR de EJB con un descriptor de despliegue de la versión 2.0. El archivo WLP_INSTALL_DIR/clients/ejbRemotePortable.jar se debe incluir en la vía de acceso de clases del cliente remoto. Este archivo contiene clases de valor de sistema que son necesarias para la comunicación con un servidor Liberty. Este archivo no es necesario cuando se accede remotamente a componentes EJB desde WebSphere Application Server Liberty o WebSphere Application Server tradicional. Los procesos de WebSphere Application Server pueden acceder remotamente a los componentes EJB que utilizan el modelo de programación remota de EJB 3 en Liberty. Liberty no proporciona un cliente ligero para iniciar componentes EJB desde un proceso Java autónomo. Liberty no proporciona prestaciones de gestión de carga de trabajo o de migración tras error para componentes EJB remotos, incluyendo cuando se inician componentes EJB que están alojados desde WebSphere Application Server tradicional.
Clases de apéndice
Un cliente debe incluir clases de apéndice cuando inicia un EJB remoto que se aloja en WebSphere Application Server. En algunos casos, si el cliente es WebSphere Application Server, el producto genera automáticamente las clases de apéndice correctas:
  • Si una aplicación cliente inicia un EJB remoto que está incluido dentro de la misma aplicación, Liberty genera automáticamente clases de apéndice.
  • Si el EJB de destino se está ejecutando en una aplicación aparte y utiliza el modelo de programación remoto de EJB 2.x con EJBHome y EJBObject, el cliente debe incluir las clases de apéndice en su vía de acceso de clases. Si el EJB se aloja en WebSphere Application Server tradicional, puede copiar el JAR del cliente EJB en la aplicación en el EAR una vez procesado por el mandato ejbdeploy. Si el EJB se aloja en Liberty, debe utilizar el programa rmic que está incluido con el Java SDK para generar las clases de apéndice para el EJB de destino y, después, debe incluir las clases de apéndice con el cliente.
  • Si el EJB de destino se está ejecutando en una aplicación separada y utiliza el modelo de programación remota de EJB 3, el proceso cliente de Liberty o WebSphere Application Server tradicional genera automáticamente clases de apéndice. Solo los procesos WebSphere Application Server o WebSphere Application Client pueden acceder de forma remota a los componentes EJB que utilizan el modelo de programación remota de EJB 3 en Liberty.
Propagación de transacciones
Liberty no soporta la propagación de transacciones de salida y entrada. Asimismo, la especificación EJB requiere que, aunque un producto dé soporte a la propagación de transacciones de salida, se envíe un contexto de transacción nulo. Este contexto lo deberán rechazar los componentes EJB que utilizan los atributos de transacción Required (predeterminado), Mandatory o Supports. Un cliente con una transacción global activa no puede iniciar un EJB con atributos de transacción predeterminados, si el cliente o el servidor está en Liberty. El cliente puede iniciar el EJB si éste se ha modificado para utilizar los atributos de transacción RequiresNew o NotSupported. Sin embargo, el trabajo transaccional que realiza el EJB no se confirma como parte de las transacciones del cliente.
Métodos asíncronos
Una interfaz remota EJB puede tener un método asíncrono con un valor de retorno de tipo Future. El servidor devolverá un objeto Future al cliente, que se utiliza para recuperar el valor. Los métodos asíncronos remotos no se recomiendan porque la acumulación de resultados no reclamados puede agotar la memoria. Para mitigar este problema, los resultados del servidor caducan si el cliente no recupera el resultado en menos de 24 horas o si el número máximo de resultados no reclamados es mayor de 1000. Estos valores se pueden ajustar en el archivo server.xml; por ejemplo:
<ejbContainer>        
     <async maxUnclaimedRemoteResults="10"unclaimedRemoteResultTimeout="10m"/>    
</ejbContainer>

Procedimiento

  1. Para habilitar esta característica, actualice el archivo server.xml para añadir la característica ejbRemote-3.2; por ejemplo:
    <featureManager>
         <feature>ejbRemote-3.2</feature>
    </featureManager>
  2. Configure los archivos de enlace de aplicación, archivos ibm-*-bnd.xml, para referencias remotas de EJB que se han definido en el descriptor de despliegue <ejb-ref> o con anotaciones de código fuente, @EJB. No es necesario un enlace para las referencias EJB que proporcionan un nombre de búsqueda, ya sea en la anotación o en el descriptor de despliegue. En el archivo de enlace, la referencia EJB se puede enlazar utilizando uno de los nombres java: para un EJB o con un nombre corbaname:; por ejemplo:
    Para una referencia EJB:
    @EJB(name="TestBean")
       TestRemoteInterface testBean;
    El enlace se define:
     <ejb-ref name="TestBean" binding-name="corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface"/>
  3. Configure su cliente de aplicaciones para que incluya clases de apéndice.
  4. (Opcional) Configure la interoperatividad para las aplicaciones que admiten el protocolo IIOP para utilizar interfaces remotas EJB añadiendo el archivo WLP_INSTALL_DIR/clients/ejbRemotePortable.jar en la vía de acceso de clases del cliente remoto.

Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_ejb_remote.html