Las aplicaciones pueden utilizar los servicios de un intermediario al enviar y recibir mensajes de éste a través de uno de los protocolos de transporte para los que se ofrece soporte.
El procedimiento que utilizan para hacerlo depende del protocolo en sí, de la interfaz de programación que utilizan y del modelo de comunicación que adoptan.
WebSphere Business Integration Message Broker ofrece soporte para dos modelos de comunicación de aplicaciones de usuario final:
Una única aplicación puede combinar ambos estilos, si procede. En un escenario mixto, el flujo de mensajes que procesa los mensajes para esta aplicación contiene, como mínimo, un nodo de salida y un nodo de publicación, además de uno o más nodos de entrada.
Las interfaces de programación que puede codificar en las aplicaciones se describen en el apartado Interfaces de programas de aplicación.
Las aplicaciones punto a punto utilizan un modelo petición/respuesta o cliente/servidor, o bien, difunden un mensaje a varias aplicaciones destino utilizando listas de distribución. Otras aplicaciones envían tráfico de enviar y olvidar o de datagramas unidireccional. 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 mensajes de enviar y olvidar y de petición/respuesta y difundirlos a los intermediarios.
En el texto y los diagramas que se incluyen más abajo se muestran los modelos de enviar y olvidar y petición/respuesta. En los diagramas se da por supuesto 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 recibe un mensaje no sea una cola WebSphere MQ.
En el modelo de enviar y olvidar, una aplicación envía un mensaje, pero no espera ninguna respuesta. Es posible que otra aplicación reciba un mensaje como resultado del mensaje que ha enviado la primera aplicación. Es posible que el flujo de mensajes no envíe ningún mensaje (por ejemplo, si el mensaje emisor sólo solicitaba una actualización de base de datos). En el diagrama, el emisor transfiere un mensaje a la cola de entrada de un flujo de mensajes del intermediario (1). La salida del flujo de mensajes se transfiere a la cola del receptor (2), donde lo puede obtener el receptor (3).
Con la mensajería de petición/respuesta, cuando el receptor recibe un mensaje de solicitud, envía una respuesta al emisor. El mensaje de solicitud se maneja tal como se ha descrito para los mensajes de enviar y olvidar. Existen dos posibilidades para la respuesta:
En el diagrama, el emisor transfiere un mensaje a la cola de entrada de un flujo de mensajes del intermediario (1). La salida del flujo de mensajes se transfiere a la cola del receptor (2), donde la obtiene el receptor (3). El receptor envía la respuesta directamente a la ColaRespuestas del emisor (4), donde la puede obtener el emisor (5).
La salida de este flujo de mensajes de respuesta debe ir a la ColaRespuestas del emisor. Si el nombre es fijo, no existe ningún problema; si no es así, se necesita algún medio que permita asociar esta cola al mensaje de respuesta.
Puede hacerlo, por ejemplo, al incluir un nodo Database o DataInsert en el primer flujo de mensajes que almacene la información de destino de respuesta para que la recupere un segundo flujo de mensajes.
De forma alternativa, se pueden copiar los detalles pertinentes del descriptor de mensaje en una carpeta de la cabecera MQRFH2 e incluirlos con el mensaje.
En el diagrama mostrado más abajo, el emisor transfiere un mensaje a la cola de entrada del primer flujo de mensajes del intermediario (1). La salida del flujo de mensajes se transfiere a la cola del receptor (2), donde la obtiene el receptor (3). El receptor envía la respuesta a la cola de entrada del segundo flujo de mensajes del intermediario (4). Después de procesar la respuesta, el intermediario la envía a la ColaRespuestas del emisor (5), donde la puede obtener el emisor (6). (En este caso, el nodo de salida del segundo flujo de mensajes necesita conocer la ColaRespuestas del emisor).
Aplicaciones existentes que se han escrito utilizando el modelo punto a punto se pueden ejecutar sin cambios en un entorno WebSphere Business Integration Message Broker si utilizan uno de los protocolos soportados para comunicar con el intermediario.
Puede mejorar y ampliar las funciones de aplicaciones existentes utilizando los recursos del intermediario para incluir asociados adicionales. Por ejemplo, puede participar una aplicación que maneje datos similares, pero en un formato diferente, puesto que un flujo de mensajes del intermediario puede transformar el mensaje original al formato esperado, sin que sea necesario cambiar la aplicación emisora o receptora.
Si identifica un mensaje que necesita proceso de aplicación adicional, puede crear otra copia del mensaje en el flujo de mensajes y enviarla a una nueva aplicación desarrollada para que facilite dicho proceso. Las aplicaciones originales no se percatan de la nueva acción en el mensaje y continúan trabajando sin cambios.
El modelo de comunicación de aplicaciones de publicación/suscripción comprende aplicaciones conocidas como publicadores y como suscriptores. Los publicadores permiten que los mensajes estén disponibles, puesto que publican sobre temas específicos. Los suscriptores reciben mensajes, al suscribirse a temas. Una aplicación individual puede ser publicadora y suscriptora.
Varios suscriptores pueden recibir los mensajes que publica un publicador. Los suscriptores también pueden recibir mensajes sobre el mismo o sobre temas diferentes, de varios publicadores.
En el diagrama mostrado más abajo, 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 una suscripción coincidente. El suscriptor puede enviar mensajes sobre registrar suscriptor, revocar la suscripción del suscriptor o solicitar actualización al intermediario. Los mensajes de respuesta opcionales del intermediario se envían al publicador y al suscriptor.
Si tiene aplicaciones de usuario final existentes que se han escrito para el modelo de publicación/suscripción, por ejemplo, utilizando el atributo MQI o AMI, es probable que las pueda integrar en un dominio de intermediarios de WebSphere Business Integration Message Broker sin realizar ningún cambio.
También puede modificarlas o escribir aplicaciones nuevas que le permitan aprovechar el proceso de publicación/suscripción sofisticado que se ofrece, en especial para los suscriptores.
El modelo de publicación/suscripción, y el proceso que proporciona WebSphere Business Integration Message Broker, se describen ampliamente en otros temas, a los que puede acceder a través de los enlaces relacionados que se listan más abajo.
Conceptos relacionados
Publicación/suscripción
Interfaces de programas de aplicación
Tareas relacionadas
Desarrollo de aplicaciones de flujos de mensajes
Desarrollo de aplicaciones de publicación/suscripción
Referencia relacionada
Soporte de aplicaciones de usuario final
Nodos incorporados
Publicación/suscripción
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
ac00450_ |