Los destinos JMS que proporcionan mensajes a un nodo JMSInput o reciben mensajes de un nodo JMSOutput se pueden coordinar por el punto de sincronización como parte de una transacción global de flujo de mensajes.
Transacciones que incluyen el coordinador de punto de sincronización
En este diagrama, 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 sincronización 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.
El coordinador de punto de sincronización envía peticiones que cumplen con las normas de XA/Open a todos los gestores de recursos participantes para informarles que se preparen. A continuación, se confirman o se restituyen los cambios. Los gestores de recursos, por ejemplo WebSphere MQ, DB2 y cualquier proveedor JMS que cumpla los estándares de XA pueden participar en una transacción global. El coordinador de punto de sincronización 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.
Transacciones dudosas
Se pueden producir transacciones dudosas cuando un Gestor de recursos no responde a una llamada de un gestor de punto de sincronización, cuando la llamada es para confirmar o restituir recursos. 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 dudosas antes de que los flujos de mensajes de intermediario empiecen a procesar entrada nueva. En este paso de recuperación, se incluye un proveedor JMS que participe en las transacciones globales de intermediario.
Configuración para permitir el soporte de transacción global
Cuando el gestor de colas de WebSphere MQ del intermediario arranca, carga el archivo de conmutación. El archivo de conmutación reenvía las llamadas de transacción XA/Open del coordinador de punto de sincronización al proveedor JMS. Esto asegura que los recursos JMS que participan en la transacción se puedan coordinar en sincronización con otros gestores de recursos que están 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 Message Broker. Este valor es obligatorio.
Debe especificar una sección en el archivo .ini de gestor de colas del intermediario para cada proveedor JMS que desee utilizar, es decir, debe haber una sección para cada nuevo proveedor JMS, donde el proveedor JMS lo puede especificar cualquier nodo JMSInput o JMSOutput incluido en un flujo de mensajes que se ejecute en un 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.
Los parámetros LDAP deben coincidir con los que se han especificado utilizando el mandato mqsicreatebroker o mqsichangebroker.
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 utiliza una fábrica por omisión denominada recoverXAQCF. En cualquier caso, este valor debe hacer referencia a un objeto administrado JNDI que ya se haya creado.
A continuación se muestra una sección de 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.
Como en el caso de Linux y Unix, se necesita la misma información en Windows pero se configura utilizando el componente WebSphere MQ Explorer o WebSphere MQ Services, dependiendo de qué version de WebSphere MQ esté utilizando. En Windows, 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 actualizar el archivo qm.ini. La entrada adicional, denominada XACloseString, debe coincidir con los valores proporcionados para XAOpenString.
En WebSphere Message 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.
Si se necesita coordinación de transacciones, se puede utilizar cualquier proveedor JMS que se ajuste a la Especificación Java Message Service, versión 1.1 y que soporte la API XAResource de JMS durante la sesión JMS.
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. En este caso, debe establecer la propiedad Modalidad de transacción en no para todos los nodos JMSInput y JMSOutput.