En este escenario, el intermediario implementa una nueva interfaz de servicio web. Se genera el WSDL para el servicio web desde un conjunto de mensajes y se pone a disposición de los clientes. Un flujo de mensajes basado en este WSDL y un conjunto de mensajes recibe una solicitud y, a continuación, compila un mensaje de respuesta utilizando los datos obtenidos de un aplicación no de servicio web existente.
El diagrama siguiente muestra un conjunto de mensajes que se crean a partir de una definición de interfaz (por ejemplo, un archivo de cabecera) de una aplicación existente que no está accesible actualmente como servicio web. Se genera un archivo WSDL a partir del conjunto de mensajes y se exporta para que lo utilice un cliente de servicio web. Un flujo de mensajes que utiliza el conjunto de mensajes y el WSDL se crea para invocar la aplicación. El flujo de mensajes y el conjunto de mensajes se despliega a un intermediario, y proporciona una interfaz de servicio web a la aplicación original.
Clave de los símbolos:
A veces este escenario se denomina fachada de servicio web. El diseño de la interfaz de servicio web incluye normalmente la reagrupación, restricción o mejora de la interfaz existente y no está limitada por ninguna definición WSDL existente.
El flujo de mensajes recibe una petición de servicio web, la convierte a un formato esperado por la aplicación existente e invoca la aplicación existente. La respuesta de la aplicación existe se convierte en una respuesta de servicio web válida.
En este ejemplo, se modifica un flujo de mensajes existente para proporcionar un servicio web. Si el flujo de mensajes existente modela sus datos en un conjunto de mensajes, se puede generar una definición WSDL desde ese conjunto de mensajes y se pone a disposición de los clientes.
La mayoría de flujos de mensajes que utilizan actualmente WebSphere MQ para la entrada o la salida se pueden adaptar para dar soporte a servicios web como protocolo de sustitución o adicional.
Si utiliza el dominio SOAP, la forma del árbol lógico será distinta del dominio original y será necesario tenerlo en cuenta en el flujo de mensajes. Si utiliza los nodos HTTP con el dominio original, la forma del árbol lógico no cambia. Para obtener información sobre el dominio, consulte WebSphere Message Broker y servicios web.
En este ejemplo, se crea un flujo de mensajes para proporcionar acceso asíncrono a una aplicación WebSphere MQ.
En cada caso, el primer flujo de mensajes recibe solicitudes de entrada desde un cliente de servicio web. El nodo Compute1 transforma la solicitud y un nodo MQOutput envía la solicitud modificada a la aplicación existente.
En el segundo flujo de mensajes, un nodo MQInput recibir la respuesta de la aplicación. A continuación, el nodo Compute2 transforma el mensaje y lo propaga a un nodo de respuesta que responde al cliente de servicio web original.
El nodo Compute1 también debe guardar alguna información de correlación para que la recupere el nodo Compute2, asegurándose de que las respuestas de la aplicación WebSphere MQ se devuelven al cliente que ha enviado la solicitud original.
Utilización de los nodos HTTPInput y MQOutput como mensajes de salida y los nodos MQInput y HTTPReply como mensaje de respuesta:
Una forma de conservar la información de correlación es para el nodo Compute1 para codificar el identificador de correlación en el mensaje de salida. (De forma alternativa, el identificador puede almacenarse en una base de datos). Los nodos SOAPInput y HTTPInput colocan el identificador como un campo en el árbol del entorno local y el nodo Compute1 árbol puede leer y almacenar este valor. La ubicación del identificador difiere entre los nodos SOAPInput y HTTPInput, tal como se describe en las secciones siguientes.
Nodos SOAP
SET OutputRoot.XMLNS.A.MessageID =
CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER);
En el módulo ESQL para el nodo Compute2, incluya una sentencia de código como la siguiente: SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
Nodos HTTP
SET OutputRoot.XMLNS.A.MessageID =
CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
En el módulo ESQL para el nodo Compute2, incluya una sentencia de código como la siguiente: SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);