Los destinos JMS que proporcionan mensajes a un nodo JMSInput o reciben mensajes de un nodo JMSOutput se pueden coordinar por el punto de sincronismo como parte de una transacción global de flujo de mensajes.
En la figura siguiente, un nodo JMSInput consume mensajes de un tema y un nodo JMSOutput produce dichos mensajes en una cola JMS. Los nodos se conectan con un proveedor JMS y están en sesión con dicho proveedor. Cualquier nodo de entrada de flujo de mensajes puede indicar al Coordinador de punto de sincronismo externo cuándo se inicia y finaliza una transacción de flujo de mensajes y si los recursos que el flujo ha tocado se deben confirmar o restituir.
AQUÍ VA LA IMAGEN
El coordinador de puntos de sincronismo envía peticiones que cumplen con las normas de XA/Open a todos los gestores de recursos participantes para informarles que se preparen y, a continuación, los cambios se confirman o se restituyen. Los gestores de recursos, por ejemplo WebSphere MQ, DB2 y cualquier proveedor de JMS que cumpla los estándares de XA, pueden participar en una transacción global. El Coordinador de punto de sincronismo externo es WebSphere MQ en plataformas distribuidas y RRS (Resource Recovery Services - Servicios de recuperación de recursos) en z/OS.
El nodo JMSInput y el nodo JMSOutput sólo pueden participar en una transacción global si el proveedor JMS al que se conectan soporta la interfaz XA/Open mediante la clase XAResource de JMS. WebSphere MQ Java Client es un ejemplo de proveedor JMS.
Durante el arranque del gestor de colas de WebSphere MQ del intermediario, se realiza un paso de recuperación inicial para asegurarse de que se resuelven las transacciones pendientes antes de que los flujos de mensajes de intermediario empiecen a procesar entrada nueva. Las transacciones pendientes pueden producirse cuando el Gestor de recursos no responde una llamada del gestor de puntos de sincronismo para confirmar o restituir recursos. Durante el arranque del gestor de colas del intermediario, se incluye en este paso de recuperación un proveedor JMS que participa en las transacciones globales de intermediario.
El archivo de conmutación reenviará las llamadas de transacción XA/Open del coordinador de punto de sincronismo al proveedor JMS. Esto asegurará que los recursos JMS que participen en la transacción se puedan coordinar en sincronización con otros gestores de recursos implicados en la misma transacción.
XAResourceManager: Name=WBIWMQJMS SwitchFile=/<Vía de acceso de instalación>/lib/JMSSwitch.so XAOpenString=<Fábrica de contexto inicial>, <ubicación de enlaces JNDI>, <Principal LDAP>, <Credenciales LDAP>, <Nombre de fábrica de conexiones de recuperación> ThreadOfControl=THREADdonde:
<Vía de acceso de instalación> es la ubicación de la instalación de WebSphere Broker. Esta valor es obligatorio. Los parámetros proporcionados en XAOpenString están delimitados por coma y son posicionales. Cualquier parámetro opcional que falte se debe representar mediante una coma si se proporcionan otros parámetros más adelante en la serie de caracteres.
<Contexto inicial es el identificador de Fábrica de contexto inicial para el proveedor JMS. Este valor es obligatorio.
<Ubicación de es la vía de acceso al archivo .bindings (no incluye el propio nombre de archivo) o la ubicación de directorio LDAP de los objetos administrados JNDI que se pueden utilizar para crear una fábrica de contexto inicial para la conexión JMS. Consulte el nodo JMSInput o JMSOutput para obtener detalles adicionales sobre cómo crear los objetos administrados JNDI. Este valor es obligatorio.
<Principal LDAP> Parámetro opcional para especificar el principal (ID de usuario) que puede ser necesario cuando se utiliza una base de datos LDAP para que contenga los objetos administrados JNDI.
<Credenciales LDAP Parámetro opcional que se utiliza para especificar las Credenciales (contraseña) que se pueden necesitar si se utiliza una base de datos LDAP para que contenga los objetos administrados JNDI y que está protegido por contraseña.
<Fábrica de recuperación Parámetro opcional utilizado para especificar el nombre de un objeto de Fábrica de conexiones de colas en los objetos administrados JNDI para la recuperación, cuando se necesita el nombre que no sea el valor por omisión.
Debe especificar una sección en el archivo “.ini” del Gestor de colas de intermediarios para cada proveedor JMS que desee utilizar. Es decir, debe haber una sección para cada proveedor JMS nuevo especificado por cualquier nodo JMSInput o JMSOutput incluido en un flujo de mensajes que se ejecute en ese intermediario.
Los valores para la Fábrica de contexto inicial y la Ubicación de los enlaces JNDI de la sección deben coincidir con los especificados en los nodos JMSInput o JMSOutput de los flujos de mensajes.
De forma similar, los parámetros LDAP deben coincidir con los que se han especificado utilizando el mandato mqsicreatebroker o mqsichangebroker para dicho intermediario.
El Nombre de fábrica de recuperación debe coincidir con un nombre de Fábrica de conexiones de colas creado en los objetos administrados JNDI. Si se omite, se utilizará una fábrica por omisión denominada "recoveryQCF". En cualquier caso, este valor debe ser un objeto administrado JNDI creado anteriormente. Por ejemplo:
XAOpenString=com.sun.jndi.fscontext.RefFSContextFactory, /u/myJndiFileLocation, , , myRecoveryQCFNameDonde se omiten los parámetros LDAP, pero se especifica una Fábrica de conexiones de colas definida por el usuario para que se recupere.
Se necesita la misma información pero ésta se configura utilizando el complemento Servicios de WebSphere MQ para añadir los detalles al registro. En este caso, el archivo de conmutación se denomina JMSSwitch.dll. Consulte la Guía de administración del sistema WebSphere MQ para obtener detalles sobre cómo se actualiza el archivo qm.ini. En este caso, una entrada de “Sección” adicional denominada XACloseString debe coincidir con los valores proporcionados para XAOPenString.
En WebSphere Event Broker, el único proveedor JMS soportado actualmente es IBM WebSphere MQ Java Client. La única modalidad de transporte soportada actualmente para el cliente es la modalidad BIND. No se necesitan pasos de configuración adicionales.
El proveedor JMS por omisión para esta implementación es WebSphere MQ. Sin embargo, si se necesita coordinación de transacciones, se puede utilizar cualquier proveedor JMS, a condición de que se ajuste a la especificación JMS 1.1 y soporte la API XAResource de JMS durante la sesión JMS.
Sin embargo, si el diseñador de mensajes ha especificado un proveedor que no se ajusta a la especificación de XA, sólo se soporta la modalidad no transaccional y el diseñador también debe establecer la propiedad Avanzada Modalidad de transacción en no para todos los nodos JMSInput y JMSoutput.