Ampliación del ejemplo Solicitud y respuesta coordinadas de JMS

Cuando los valores de ReplyToQ y Correlation ID del mensaje de solicitud original se guardan en un mensaje de JMS para su recuperación posterior, se guarda la totalidad de JMSHeader, y no sólo los detalles de ReplyToQ y Correlation ID. Se guarda la totalidad de JMSHeader porque existe un requisito para almacenar y recuperar dos valores (ReplyToQ y Correlation ID), y el nodo JMSReceive puede almacenar o recuperar solamente un valor. Por consiguiente, debe guardar la estructura que contiene los valores necesarios, en lugar de guardar valores individuales. Cuando modifique el ejemplo para guardar distintos valores, debe considerar el comportamiento del nodo JMSReceive.

Puede utilizar sus propias implementaciones de los subflujos que se utilizan en los flujos de Solicitud y Respuesta para sustituir los proporcionados en el ejemplo. Por ejemplo, puede utilizar una base de datos para almacenar el detalle de ReplyToQ del mensaje de solicitud inicial. De forma alternativa, puede utilizar los subflujos que se utilizan para almacenar y recuperar los valores de ReplyToQ y Correlation ID en un mensaje de JMS en otros flujos de mensajes.

Reutilización del subflujo StoreOriginalJMSHeader_Sub

Puede utilizar el subflujo StoreOriginalJMSHeader_Sub en sus flujos de mensajes; este subflujo actúa del mismo modo que guardar JMSHeader en un mensaje de JMS. Para guardar el JMSHeader del mensaje, debe incluir el subflujo en el punto apropiado del flujo de mensajes en el que debe utilizarse. Puede incluir el subflujo sin ninguna modificación, pero debe tener en cuenta lo siguiente:

Aunque es posible que los parámetros clave que puede modificar se identifiquen en el texto anterior, debe revisar todos los valores de los parámetros de los nodos contenidos en el subflujo para asegurarse de que sean compatibles con los requisitos.

Utilización de una implementación alternativa del subflujo StoreOriginalJMSHeader_Sub

Puede modificar el subflujo para utilizar un recurso de almacenamiento alternativo para los datos; por ejemplo, si opta por utilizar una base de datos, en lugar de escribir un mensaje de JMS, el subflujo debe insertar los datos en una base de datos.

Si se modifica el recurso de almacenamiento, se modifican las características de rendimiento del subflujo. Es importante asegurarse de que las características de la implementación que selecciona sean coherentes con los requisitos de rendimiento del flujo de mensajes. Si se utiliza una base de datos para la información, es más probable que el rendimiento quede limitado E/S porque cada inserción de la base de datos requiere una escritura en el registro del gestor de bases de datos.

El uso de un recurso de almacenamiento alternativo también puede cambiar las propiedades transaccionales del subflujo. Cuando los datos se almacenan utilizando un mensaje de JMS, éste utiliza el mismo gestor de recursos que los mensajes de JMS que se leen en otro lugar del flujo de mensajes. Si los mensajes de JMS se procesan solamente en el flujo de mensajes, sólo participa un gestor de recursos. El uso de una base de datos, o de otro gestor de recursos recuperable, requiere un protocolo de recuperación de confirmación de dos fases entre el gestor de colas de WebSphere Message Broker y el gestor de bases de datos de la base de datos en la que se han almacenado los datos a fin de garantizar la integridad de los datos.

Cuando efectúe cambios, debe revisar todos los valores de los parámetros de los nodos contenidos en el subflujo para asegurarse de que son compatibles con sus requisitos.

Reutilización del subflujo RestoreOriginalJMSHeader_Sub

Puede utilizar el subflujo RestoreOriginalJMSHeader_Sub en otros flujos de mensajes para recuperar el JMSHeader del mensaje de solicitud inicial de un mensaje de JMS. Para recuperar el JMSHeader debe incluir el subflujo en el punto adecuado del flujo de mensajes en el que se ha de utilizar. Puede incluir el subflujo sin ninguna modificación, pero debe tener en cuenta lo siguiente:

Aunque es posible que los parámetros clave que desee modificar se identifiquen en el texto anterior, debe revisar todos los valores de los parámetros de los nodos contenidos en el subflujo para asegurarse de que sean compatibles con los requisitos.

Utilización de una implementación alternativa del subflujo RestoreOriginalJMSHeader_Sub

Puede modificar el subflujo para utilizar un recurso de almacenamiento alternativo para los datos; por ejemplo, si opta por utilizar una base de datos, en lugar de utilizar el nodo JMSReceive para leer un mensaje de JMS, el subflujo puede leer datos de una base de datos.

Si se modifica el recurso de almacenamiento, se modifican las características de rendimiento del subflujo. Es importante asegurarse de que las características de la implementación que elija sean coherentes con los requisitos de rendimiento del flujo de mensajes. Dependiendo de la implementación, la utilización de una base de datos para contener la información puede aumentar la actividad general. Si los datos se recuperan utilizando una operación de lectura y no se actualizan o suprimen, la actividad general estará al mínimo para una implementación de base de datos. Sin embargo, si los datos no se suprimen de la base de datos, su tamaño continuará aumentando y progresivamente su uso será más lento a menos que se lleve a cabo alguna operación de mantenimiento. Si el proceso de recuperación implica la actualización de una fila para indicar que los datos se han recuperado o que se ha suprimido una fila, esta acción implica una grabación en las anotaciones del gestor de bases de datos y el resultado será una actividad general de proceso significativamente mayor que cuando se ejecuta una operación de sólo lectura.

La utilización de un recurso alternativo de almacenamiento también puede cambiar las propiedades transaccionales del subflujo. Cuando los datos se almacenan utilizando un mensaje de JMS, éste utiliza el mismo gestor de recursos que los mensajes de JMS que se leen en otro lugar del flujo de mensajes. Si los mensajes de JMS sólo se procesan en el flujo de mensajes, sólo participa un gestor de recursos. El uso de una base de datos o de otro gestor de recursos recuperable requiere el uso de un protocolo de confirmación de dos fases entre el gestor de colas de WebSphere Message Broker y el gestor de bases de datos de la base de datos en la que se almacenan los datos a fin de garantizar la integridad de los datos.

Debe revisar todos los valores de los parámetros de los nodos contenidos en el subflujo para asegurarse de que son compatibles con sus requisitos.

Volver a la página inicial del ejemplo