En este escenario de servicio web, el intermediario proporciona una interfaz de servicio web a una aplicación no de servicio web existente.
Clave de los símbolos:
A veces esto se denomina fachada de servicio web. El diseño de la interfaz de servicio web incluirá normalmente la reagrupación, restricción o mejora de la interfaz existente y no está limitada por ninguna definición WSDL existente.
El intermediario proporciona una interfaz de servicios web a una aplicación existente, proporcionando opcionalmente otras posibilidades combinadas, por ejemplo comprobar las peticiones realizadas.
Con el tiempo la implementación se puede cambiar sin que ello afecte a la interfaz presentada al cliente de servicios web.
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.
Una aplicación CICS existente tiene una interfaz de libro de copias COBOL.
La mayoría de flujos de mensajes que utilizan actualmente WebSphere MQ para entrada o salida se pueden adaptar para utilizar HTTP como protocolo de sustitución o adicional.
Puede modelar el mensaje de entrada en el dominio MRM y generar WSDL a partir del modelo o puede procesar un mensaje de dominio 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 a las normas del modelo.
Puede configurar el nodo HTTPReply a fin de generar un conjunto de cabeceras HTTP por omisión para el mensaje de respuesta enviado al cliente. Esto reduce las modificaciones que debe realizar para convertir un flujo de mensajes que procesa mensajes de WebSphere MQ en un flujo que procesa mensajes HTTP.
El primer flujo de mensajes recibe peticiones de entrada de los clientes de servicio web en un nodo HTTPInput. Incluye un nodo Compute para transformar de algún modo la petición 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 lo transforma y lo propaga a un nodo HTTPReply que lo envía como respuesta al cliente de servicio web original.
Aunque es posible que las transformaciones realizadas por cada nodo Compute sean triviales, el código ESQL del primero debe guardar la información de estado HTTP que el segundo recupera para asegurar que las respuestas de la aplicación WebSphere MQ se devuelven al cliente que ha enviado la petición original.
El primer flujo de mensajes recibe el mensaje, realiza las transformaciones que sean necesarias y codifica el identificador de petición HTTP en el mensaje de salida. (El identificador de petición también se puede almacenar en una base de datos, si lo prefiere). El nodo HTTPInput proporciona el identificador de petición como un campo del árbol LocalEnvironment denominado Destination.HTTP.RequestIdentifier y Compute1 puede leer y almacenar este valor.
El segundo flujo de mensajes recibe el mensaje de respuesta y lo vuelve a transformar al formato de mensaje de cliente. Compute2 lee el identificador de 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 asegurarse de que el mensaje llega al cliente HTTP correcto.
La implementación de este escenario requiere que se maneje correctamente el MQMD. A los mensajes que entran en un flujo de mensajes a través de HTTP se les debe añadir un MQMD antes de que se envíen a un nodo MQOutput. Asimismo, se debe eliminar el MQMD de los mensajes que entran a través de WebSphere MQ antes de que se envíen a un nodo HTTPReply o HTTPRequest (a menos que se desee incluir un MQMD en la corriente de datos HTTP).
En el módulo ESQL para Compute1, incluya una sentencia como la siguiente:
SET OutputRoot.XML.A.MessageID = CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
En el módulo ESQL para Compute2, codifique una sentencia como la siguiente:
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XML.A.MessageID AS BLOB);