Transacciones JMS

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.

Se necesitan pasos de configuración adicionales para habilitar el soporte de transacción global para el nodo JMSInput y el nodo JMSOutput. Consulte la sección sobre configuración para transacciones coordinadas bajo el nodo JMSInput y el nodo JMSOutput.
  1. El atributo de flujo de mensajes Transacción coordinada se debe establecer en .
  2. Para cada nodo JMSInput o JMSOutput que necesite participar en la transacción global, establezca la propiedad avanzada Modalidad de transacción en el valor ninguno (valor por omisión).
  3. Se deberá crear una Fábrica de conexiones de colas en los objetos administrados JNDI. Consulte el nodo JMSInput o JMSOutput para obtener detalles adicionales sobre cómo crear los objetos administrados JNDI. Este nombre de fábrica debe ser un nombre por omisión "recoveryQCF" o un nombre definido por el usuario.
  4. En plataformas distribuidas, es necesario realizar una tarea de administración de WebSphere MQ antes del despliegue. Esta tarea es necesaria para registrar un componente de intermediario WBI en el gestor de colas. El componente, que se conocerá como archivo de conmutación, es una biblioteca compartida (una DLL en Windows). Cuando el gestor de colas de WebSphere MQ del intermediario arranque, cargará el archivo de conmutación.

    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.

    La tarea de configuración varía según la plataforma:
    • Linux y UNIX
      En plataformas Linux y UNIX, la tarea es poner una entrada de sección en un archivo den “inicialización” (qm.ini) para el gestor de colas de intermediarios para cada proveedor JMS que pueda ser utilizado por un nodo JMSInput. Una entrada de sección de ejemplo cuando se utiliza IBM WebSphere MQ Java como proveedor JMS será:
      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=THREAD 
      donde:

      <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,
           ,
           ,
           myRecoveryQCFName    
      Donde se omiten los parámetros LDAP, pero se especifica una Fábrica de conexiones de colas definida por el usuario para que se recupere.
    • En plataformas Windows

      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 z/OS

      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.

Elección de proveedor JMS

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.

Referencia relacionada
Tipos de mensaje JMS
Estructura de mensaje JMS
Objetos administrados JNDI
Nodo JMSInput
Nodo JMSOutput
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2005 Última actualización: 11/11/2005
ac24879_