El nodo de integración implementa una interfaz de servicio web nueva

En este escenario, el nodo de integración implementa una nueva interfaz de servicio web. EL WSDL para el servicio web es generado desde un conjunto de mensajes y se pone a disposición del cliente. 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 siguiente diagrama 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. Un archivo WSDL es generado desde el 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 despliegan en un nodo de integración, proporcionando una interfaz de servicio web a la aplicación original.
El diagrama se describe en el texto circundante.
Clave de los símbolos:
Este diagrama describe los símbolos que se utilizan en los otros diagramas, que no se describen aquí porque los diagramas tienen sus propias descripciones.

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.

Usos posibles

  • El nodo de integración proporciona una interfaz de servicios web a una aplicación existente, proporcionando opcionalmente otras prestaciones combinadas como por ejemplo comprobar las solicitudes realizadas.
  • Con el tiempo la implementación se puede cambiar sin que ello afecte a la interfaz presentada al cliente de servicios web.

Pasos de diseño

  1. Cree un conjunto de mensajes para los mensajes de empresa, posiblemente importando una definición de interfaz existente, por ejemplo un archivo de cabecera C o un libro de copias COBOL.
  2. Genere una definición WSDL desde el conjunto de mensajes.
  3. Utilice un kit de herramientas SOAP como Rational® Application Developer para crear un cliente de servicios web adecuado basado en el WSDL.
  4. Desarrolle un flujo de mensajes para implementar el servicio web.

En el tiempo de ejecución

El flujo de mensajes recibe una solicitud 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.

Ejemplo 1

En este ejemplo, un flujo de mensajes existente se modifica 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 los flujos de mensajes que utilizan actualmente WebSphere® MQ para la entrada o la salida se pueden adaptar para dar soporte a los servicios web como un protocolo adicional o de sustitución.

A continuación se muestran patrones de flujo de mensajes típicos. En cada caso, los nodos de entrada y respuesta sustituyen o complementan los nodos MQInput y MQOutput originales. Se sobrentiende que la parte principal del flujo realiza una parte del proceso útil.
  • Utilización de nodos SOAPInput y SOAPResponder :
    El diagrama muestra un flujo de mensajes que proporciona un servicio web utilizando nodos SOAPInput y SOAPReply.
  • Utilización de nodos HTTPInput y HTTPResponder :
    El diagrama muestra un flujo de mensajes que proporciona un servicio web utilizando los nodos HTTPInput y HTTPReply.

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 cómo elegir el dominio, consulte IBM Integration Bus y servicios web.

Detalles de HTTP
Si utiliza los nodos HTTP, puede configurar el nodo HTTPResponder para generar un conjunto de cabeceras HTTP predeterminadas para el mensaje de respuesta enviado al cliente. La generación de un conjunto de cabeceras HTTP por omisión reduce las modificaciones que debe realizar para convertir el flujo de mensajes de uno que procesa mensajes de WebSphere MQ a un flujo que procesa mensajes HTTP.

Ejemplo 2

En este ejemplo, se crea un flujo de mensajes para proporcionar acceso asíncrono a una aplicación WebSphere MQ .

A continuación se muestran patrones de flujo de mensajes típicos. En cada caso, el flujo recibe la solicitud de servicio web y crea la respuesta utilizando datos devueltos de la aplicación sobre WebSphere MQ.
  • La utilización de dos flujos de mensajes con nodos SOAPInput y SOAPResponder :
    El diagrama muestra dos flujos de mensajes que proporcionan acceso asíncrono a una aplicación WebSphere MQ utilizando nodos SOAPInput y SOAPReply.
  • La utilización de dos flujos de mensajes con nodos HTTPInput y HTTPResponder :
    El diagrama muestra dos flujos de mensajes que proporcionan acceso asíncrono a una aplicación WebSphere MQ utilizando los nodos HTTPInput y HTTPReply.

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 recibe la respuesta de la aplicació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 parte de la información de correlación que debe recuperar el nodo Compute2 , asegurándose de que las respuestas de la aplicación WebSphere MQ se devuelven al cliente que envió la solicitud original.

Detalles de HTTP
Utilización de nodos HTTPInput y MQOutput como mensaje de salida y nodos MQInput y HTTPResponder como mensaje de respuesta:
El diagrama muestra cómo puede utilizar los nodos HTTPInput y MQOutput como el mensaje de salida, y los nodos MQInput y HTTPReply como el 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 de entorno local y el nodo Compute1 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

El nodo Compute2 lee el identificador de respuesta SOAP del mensaje, y establece LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier utilizando este valor. El nodo SOAPResponder utiliza el identificador de respuesta para asegurarse de que el mensaje llegue al cliente HTTP correcto. En el módulo ESQL para el nodo Compute1, incluya una sentencia de código como la siguiente:
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

El nodo Compute2 lee el identificador de solicitud HTTP desde el mensaje, y establece LocalEnvironment.Destination.HTTP.RequestIdentifier utilizando este valor. El nodo HTTPResponder utiliza el identificador de solicitud para asegurarse de que el mensaje llegue al cliente HTTP correcto. En el módulo ESQL para el nodo Compute1, incluya una sentencia de código como la siguiente:
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);