La agregación es la creación y despliegue de peticiones relacionadas derivadas de un solo mensaje de entrada y la recopilación de las respuestas correspondientes para producir un solo mensaje de respuesta agregado.
La petición inicial recibida por el flujo de mensajes, que representa un conjunto de elementos de petición relacionados, se divide en el número adecuado de peticiones individuales para satisfacer las subtareas de la petición inicial. Este proceso se denomina abanico de salida y lo proporciona un flujo de mensajes que incluye nodos de agregación.
Las respuestas de las subtareas se combinan y fusionan en una sola respuesta que se devuelve al peticionario original (o a otra aplicación destino) para indicar la finalización del proceso. Este proceso se denomina abanico de entrada y también lo proporciona un flujo de mensajes que incluye nodos de agregación.
Puede iniciar la agregación enviando un mensaje a un flujo de mensajes desde una aplicación cliente que esté conectada al intermediario a través de cualquier protocolo soportado; la respuesta agregada también se puede enviar a una aplicación cliente a través de todos estos protocolos. Los mensajes emitidos por el flujo de mensajes de abanico de salida y las respuestas recibidas por el flujo de mensajes de abanico de entrada deben ser mensajes de petición/respuesta. Por consiguiente, está limitado a aplicaciones cliente que se conectan utilizando WebSphere MQ Enterprise Transport (enviando y recibiendo mensajes a y desde los nodos MQInput y MQOutput) o a clientes que utilizan otro protocolo soportado por nodos de entrada y salida definidos por el usuario que se ajustan al modelo de comunicaciones de petición/respuesta.
WebSphere Message Broker proporciona tres nodos de flujos de mensajes que soportan la agregación:
Cuando incluye estos nodos en sus flujos de mensajes, las diversas peticiones del abanico de salida se emiten en paralelo desde dentro de un flujo de mensajes. A diferencia del funcionamiento estándar del flujo de mensajes, en el que cada nodo efectúa su proceso en secuencia.
También puede utilizar estos nodos para emitir peticiones a aplicaciones fuera del entorno de intermediario; los mensajes se pueden enviar de forma asíncrona a servicios o aplicaciones externas, y las respuestas se pueden recuperar de esas aplicaciones y combinarse para proporcionar una sola respuesta al mensaje de petición original.
Estos nodos también proporcionan una oportunidad para mejorar el tiempo de respuesta, puesto que las peticiones lentas se pueden realizar en paralelo y no tienen que realizarse secuencialmente. Si las subtareas pueden procesarse independientemente y no tienen que manejarse como parte de una sola unidad de trabajo, pueden procesarse por flujos de mensajes aparte.
Puede diseñar y configurar un flujo de mensajes que proporcione una función similar sin utilizar los nodos agregados, emitiendo las peticiones de subtareas a otra aplicación (por ejemplo, utilizando el nodo HTTPRequest) y registrando los resultados en el entorno local. Después de completar cada subtarea, puede fusionar los resultados del entorno local en un nodo Compute y crear el mensaje de respuesta combinado para propagar a la aplicación destino. Si lo hace, todas las subtareas se realizan secuencialmente y no se obtienen los beneficios en cuanto a rendimiento que sí se obtiene de la operación en paralelo que puede realizar utilizando los nodos de agregación.
En el Ejemplo Agregación y el Ejemplo Reserva de vuelos, se proporcionan flujos de agregación de ejemplo que utilizan los nodos de agregación. El ejemplo de Agregación muestra una agregación simple de cuatro vías y el ejemplo de Reservas de vuelos simula peticiones relacionadas con un servicio de reservas de vuelos e ilustra las técnicas asociadas con los flujos de agregación.
En releases anteriores de WebSphere Message Broker, la agregación utilizaba una tabla en la base de datos del intermediario para que las peticiones de agregación permanezcan. A partir de WebSphere
Business Integration Message Broker Versión 5.0, puede utilizar WebSphere MQ en su lugar. El funcionamiento externo de los nodos de agregación no varía, pero puede configurar un grupo de ejecución para que utilice las colas WebSphere MQ para almacenar agregaciones en lugar de una tabla de base de datos. La utilización de WebSphere MQ de este modo mejora el rendimiento y quiere decir que la agregación se puede ejecutar en modalidad no persistente cuando la persistencia de peticiones de agregación no es necesaria. Si desea obtener información detallada sobre cómo migrar y configurar un grupo de ejecución para utilizar WebSphere MQ, consulte el apartado Utilizar WebSphere MQ para almacenar el estado en nodos de agregación.
Al pasar de utilizar una tabla de base de datos a WebSphere MQ para almacenar el estado de agregación, las agregaciones existentes no se migran, por lo que es importante asegurarse de que no haya agregaciones pendientes, ya que estas no se migrarían.
Las nuevos nodos de agregación utilizan la caducidad de mensajes de WebSphere MQ para gestionar los tiempos de espera de los mensajes. Para que la caducidad de los mensajes funcione, es necesario examinar las colas de mensajes. Los nodos de agregación examinan las colas automáticamente para asegurarse de que los mensajes caducados se procesan. En z/OS, puede configurar WebSphere MQ para que ejecute un proceso carroñero que examine esto en lugar de examinar los nodos de agregación. Para habilitar el proceso carroñero, establezca la propiedad EXPRYINT del gestor de colas del intermediario en 5 segundos.
Si EXPRYINT no está establecida o lo está en un valor mayor que 10 segundos, las agregaciones vuelven a examinar las colas de agregación automáticamente.