En este escenario de servicio web, el intermediario proporciona una interfaz de servicio web a una aplicación existente que no es de servicio web.
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.
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 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 predeterminadas para el mensaje de respuesta enviado al cliente. Al generar un conjunto de cabeceras HTTP predeterminadas se reducen las modificaciones que debe realizar para convertir el flujo de mensajes de uno 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 solicitud y un nodo MQOutput para enviar la solicitud 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 primer nodo Compute debe guardar información de estado HTTP que recuperará el segundo nodo Compute para asegurarse de que las respuestas de la aplicación WebSphere MQ se devuelven al cliente que ha enviado la solicitud 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 solicitud como campo en el árbol de entorno local llamado 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 de mensaje de cliente. El nodo Compute2 lee el identificador de solicitud HTTP desde 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 el nodo Compute1, incluya una sentencia de código similar a la del siguiente ejemplo:
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ódio similar a la de la siguiente sentencia:
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XMLNS.A.MessageID AS BLOB);