En este tema se describen cuatro casos en los que los clientes de servicios Web interactúan con WebSphere Business Integration Message Broker. No representan una lista definitiva sino algunas de las opciones soportadas para las aplicaciones de servicios Web.
En este caso, generalmente se borra el recuadro de selección Sustituir mensaje de entrada por respuesta de servicio de web en las propiedades del nodo HTTPRequest y se coloca la respuesta desde el servidor de directorios de la empresa a una ubicación temporal del árbol de mensajes especificado en la propiedad Ubicación del mensaje de respuesta en el árbol del mismo nodo. En Compute2, se codifica ESQL para que desempaquete el resultado y aumente el mensaje final según corresponda.
Codifique ESQL en el nodo Compute1 para correlacionar la petición del cliente con una petición del servidor y en el nodo Compute2 para correlacionar la respuesta del servidor con la respuesta del cliente. Puede definir estos mensajes de petición y de respuesta en el dominio MRM para simplificar la transformación de un formato a otro.
Puede configurar el nodo HTTPRequest para que genere cabeceras HTTP basándose en las cabeceras que recibe el nodo HTTPInput, lo que permite que se pasen cookies y otras cabeceras específicas de la aplicación. El nodo HTTPReply puede proporcionar una tarea equivalente que extraiga cabeceras de la respuesta del servicio Web y las devuelva al cliente de origen. Si desea llevar esto a cabo, seleccione el recuadro de selección Generar cabeceras HTTP por omisión desde..... en los nodos HTTPRequest y HTTPReply.
En la mayor parte de los casos, la petición original no tiene ningún valor y solamente necesita la respuesta del servicio para generar el mensaje de respuesta del cliente. Si es así, seleccione la propiedad Sustituir mensaje de entrada por respuesta de servicio de web en el nodo HTTPRequest. Si desea conservar cualquier dato de la petición de entrada, puede almacenarlo en LocalEnvironment de Compute1 y recuperarlo en Compute2 para incluirlo en la respuesta.
La mayor parte de los flujos de mensajes que utilizan actualmente WebSphere MQ para entrada o salida se pueden adaptar para que utilicen HTTP como un protocolo de sustitución o un protocolo adicional.
Puede diseñar el mensaje de entrada en el dominio MRM y generar WSDL a partir del modelo o puede procesar un mensaje para el dominio en XML o XMLNS genérico. Si ha definido el mensaje en el dominio MRM, puede configurar el nodo HTTPInput para validar el mensaje de entrada. El nodo genera una excepción si el mensaje no se ajusta al modelo.
Puede configurar el nodo HTTPReply para generar un conjunto de cabeceras HTTP por omisión para el mensaje de respuesta que se envía al cliente. Esto disminuye las modificaciones que debe realizar para que el flujo de mensajes deje de ser un flujo que procesa mensajes WebSphere MQ y se convierta en un flujo de mensajes que procesa mensajes HTTP.
El primer flujo de mensajes recibe las peticiones de entrada de los clientes de servicios Web de un nodo HTTPInput. Incluye un nodo Compute para transformar la petición de algún modo y un nodo MQOutput para enviar la petición modificada a la aplicación WebSphere MQ.
El segundo flujo de mensajes recibe la respuesta de dicha aplicación en un nodo MQInput. El mensaje se pasa a un nodo Compute que transforma el mensaje y lo propaga a un nodo HTTPReply que lo envía como una respuesta al cliente del servicio Web original.
Aunque las transformaciones que completa cada nodo Compute pueden ser triviales, el código ESQL del primero debe guardar la información de estado HTTP que recupera el segundo para garantizar que las respuestas de la aplicación WebSphere MQ se devuelvan al cliente que ha enviado la petición original.
El primer flujo de mensajes recibe el mensaje, efectúa las transformaciones necesarias y codifica el identificador de la petición HTTP en el mensaje de salida. (El identificador de la petición también se puede almacenar en una base de datos, si lo prefiere). El nodo HTTPInput proporciona el identificador de la petición como un campo del árbol LocalEnvironment denominado Destination.HTTP.RequestIdentifier y el nodo Compute1 puede leer y almacenar este valor.
El segundo flujo de mensajes recibe el mensaje de respuesta y lo vuelve a transformar al formato del mensaje del cliente. Compute2 lee el identificador de la petición HTTP en el mensaje y establece LocalEnvironment.Destination.HTTP.RequestIdentifier utilizando este valor. El nodo HTTPReply utiliza el identificador de petición para garantizar que el mensaje llegue al cliente HTTP correcto.
La implementación de este caso requiere que se maneje correctamente el MQMD. Se debe añadir MQMD a los mensajes contenidos en un mensaje a través de HTTP antes de enviarlos a un nodo MQOutput. Asimismo, se debe suprimir MQMD de cualquier mensaje enviado a través de WebSphere MQ antes continuar con la salida de un nodo HTTPReply o HTTPRequest (a menos que incluya MQMD en la corriente HTTP, si lo desea).
En el módulo ESQL para Compute1, incluya una sentencia similar a esta:
SET OutputRoot.XML.A.MessageID = CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
En el módulo ESQL para Compute2, codifique una sentencia de este modo:
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XML.A.MessageID AS BLOB);
Conceptos relacionados
WebSphere MQ Web Services Transport
Generación del lenguaje de descripción de servicios web (WSDL)
Tareas relacionadas
Creación de un flujo de mensajes
Configuración de nodos para casos de servicios Web determinados
Difusión de aplicaciones de flujos de mensajes
Comprobación de los resultados de la difusión
Referencia relacionada
Nodo HTTPInput
Nodo HTTPReply
Nodo HTTPRequest
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
ac20440_ |