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:
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:java: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.TestRemoteInterface
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áticaTodos 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:
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("java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface) found;
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>