Las aplicaciones pueden utilizar los servicios de un intermediario enviándole mensajes o recibiendo mensajes de él, a través de uno de los protocolos de transporte soportados.
La forma de hacerlo depende del protocolo, la interfaz de programación que utilicen y el modelo de comunicación que adopten.
WebSphere Message Broker da soporte a dos modelos de comunicación con aplicaciones de usuario final:
Una misma aplicación puede combinar los dos estilos, si es adecuado. En un escenario con esta combinación, el flujo de mensajes que procesa los mensajes para esta aplicación contiene un nodo de salida y un nodo de publicación, como mínimo, además de uno o más nodos de entrada.
Las interfaces de programación que puede codificar en sus aplicaciones se describen en Interfaces de programación de aplicaciones.
Las aplicaciones punto a punto utilizan un modelo petición/respuesta o cliente/servidor, o despliegan un mensaje a muchas aplicaciones destino utilizando las listas de distribución. Otras aplicaciones envían tráfico unidireccional enviar y olvidar o datagrama. Intercambian información con asociados conocidos. Cada aplicación conoce la identidad de una o más aplicaciones con las que se comunica. Puede crear y configurar flujos de mensajes para procesar tanto los mensajes enviar y olvidar como los mensajes petición/respuesta.
El texto y los diagramas siguientes ilustran los modelos enviar y olvidar y petición/respuesta. Los diagramas suponen que las aplicaciones utilizan el protocolo WebSphere MQ Enterprise Transport. El modelo es idéntico para otros protocolos, aunque el recurso a través del cual se envía o se recibe un mensaje no será una cola de WebSphere MQ.
En el modelo enviar y olvidar, una aplicación envía un mensaje pero no espera una respuesta. Opcionalmente, otra aplicación puede recibir un mensaje como resultado del mensaje enviado por la primera aplicación. Es posible que el flujo de mensajes no envíe ningún mensaje (por ejemplo, si el mensaje enviado sólo solicitaba una actualización de base de datos). En el diagrama, el emisor coloca un mensaje en la cola de entrada de un flujo de mensajes en el intermediario (1). La salida del flujo de mensajes se pone en la cola del receptor (2), de donde éste puede obtenerlo (3).
Con la mensajería de petición/respuesta, después de que el receptor reciba un mensaje de petición, éste envía una respuesta al emisor. El mensaje de petición se maneja tal y como se describe para los mensajes enviar y olvidar. Hay dos posibilidades para la respuesta:
En el diagrama que hay a continuación, el emisor coloca un mensaje en la cola de entrada de un flujo de mensajes en el intermediario (1). La salida del flujo de mensajes se pone en la cola del receptor (2), de donde éste lo obtiene (3). El receptor envía la respuesta directamente a la ColaRespuestas del emisor (4), de donde éste puede obtenerlo (5).
La salida de este flujo de mensajes de respuesta debe ir a la ColaRespuestas del emisor. Si el nombre es fijo, no hay ningún problema; si no lo es, se necesita alguna forma de asociar esta cola con el mensaje de respuesta.
Por ejemplo, puede incluir un nodo Database o DataInsert en el primer flujo de mensajes que almacene la información del destino de la respuesta, que el segundo flujo de mensajes puede recuperar.
De forma alternativa, los detalles relevantes en el descriptor de mensaje pueden copiarse en una carpeta en la cabecera MQRFH2 y transportarse con el mensaje.
En el diagrama que hay a continuación, el emisor coloca un mensaje en la cola de entrada del primer flujo de mensajes en el intermediario (1). La salida del flujo de mensajes se pone en la cola del receptor (2), de donde éste lo obtiene (3). El receptor envía la respuesta a la cola de entrada del segundo flujo de mensajes en el intermediario (4). Después de procesar la respuesta, el intermediario la envía a la ColaRespuestas del emisor (5), de donde éste puede obtenerla (6). (En este caso, el nodo de salida del segundo flujo de mensajes debe conocer la ColaRespuestas del emisor.)
Las aplicaciones existentes que ha escrito utilizando el modelo punto a punto pueden ejecutarse sin modificarse en un entorno de WebSphere Message Broker si utilizan uno de los protocolos soportados para comunicarse con el intermediario.
Puede mejorar y ampliar la función de aplicaciones existente utilizando los recursos del intermediario para incluir asociados adicionales. Por ejemplo, una aplicación que maneja datos parecidos pero en un formato distinto puede participar porque un flujo de mensajes en el intermediario puede transformar el mensaje original al formato que se espera, sin tener que cambiar la aplicación emisora o receptora.
Si identifica un mensaje que necesita un proceso adicional, puede crear otra copia del mensaje en el flujo de mensajes y enviarla a la nueva aplicación desarrollada para proporcionar ese proceso. Las aplicaciones originales ignoran esta nueva acción en el mensaje y siguen funcionando igual que anteriormente.
El modelo de publicación/suscripción de comunicación con aplicaciones implica aplicaciones conocidas como publicadores y aplicaciones conocidas como suscriptores. Los publicadores ponen los mensajes a disposición publicando sobre temas específicos. Los suscriptores reciben los mensajes suscribiéndose a los temas. Una aplicación individual puede ser tanto un publicador como un suscriptor.
Cualquier número de suscriptores pueden recibir los mensajes publicados por un publicador. Los suscriptores también pueden recibir mensajes, sobre el mismo tema o sobre temas distintos, de cualquier número de publicadores.
En el diagrama que hay a continuación, el publicador puede enviar mensajes de publicación o de supresión de publicación al intermediario. El intermediario reenvía el mensaje de publicación a los suscriptores que tienen la suscripción correspondiente. El suscriptor puede enviar mensajes de registro de suscriptor, de anulación de registro de suscriptor o de petición de actualización, al intermediario. Los mensajes de respuesta opcional del intermediario se envían al publicador y al suscriptor.
Si tiene aplicaciones ya existentes de usuario final que están escritas para el modelo de publicación/suscripción, por ejemplo, utilizan MQI o AMI, probablemente puede integrar estas aplicaciones sin modificar en un dominio de intermediarios de WebSphere Message Broker.
También puede modificar estas aplicaciones, o escribir de nuevas, para sacar el máximo partido del proceso sofisticado de publicación/suscripción que se proporciona, especialmente para los suscriptores.
El modelo de publicación/suscripción y el proceso que proporciona WebSphere Message Broker se describen ampliamente en otros temas, disponibles a través de los enlaces relacionados que se muestran a continuación.