WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

El intermediario implementa una interfaz de servicio web nueva

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.

El diagrama se describe en el texto que lo rodea.

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

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, por ejemplo 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 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.

Ejemplo 1

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.

A continuación se muestran patrones de flujos de mensajes típicos. En cada caso, los nodos de entrada y respuesta sustituyen o complementan los nodos MQInput y MQOutput. Se sobrentiende que parte principal del flujo realiza una parte del proceso útil.
  • Utilización de nodos SOAPInput y SOAPReply:
    El diagrama muestra un flujo de mensajes que proporciona un servicio web utilizando nodos SOAPInput y SOAPReply.
  • Utilización de nodos HTTPInput y HTTPReply:
    El diagrama muestra un flujo de mensajes que proporciona un servicio web utilizando 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 el dominio, consulte WebSphere Message Broker y servicios web.

Detalles de HTTP
Si utiliza los nodos HTTP, puede configurar el nodo HTTPReply para 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 procesar 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 flujos de mensajes típicos. En cada caso, el flujo recibe la solicitud de servicio web y crea la respuesta utilizando los datos devueltos desde la aplicación a través de WebSphere MQ.
  • Utilización de dos flujos de mensajes con nodos SOAPInput y SOAPReply:
    El diagrama muestra dos flujos de mensajes que proporcionan acceso asíncrono a una aplicación WebSphere MQ utilizando nodos SOAPInput y SOAPReply.
  • Utilización de dos flujos de mensajes con nodos HTTPInput y HTTPReply:
    El diagrama muestra dos flujos de mensajes que proporcionan acceso asíncrono a una aplicación WebSphere MQ utilizando 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 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.

Detalles de HTTP

Utilización de los nodos HTTPInput y MQOutput como mensajes de salida y los nodos MQInput y HTTPReply como mensaje de respuesta:

El diagrama muestra cómo se pueden utilizar los nodos HTTPInput y MQOutput como mensaje 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

El nodo Compute2 lee el identificador de respuesta SOAP del mensaje, y establece LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier utilizando este valor. El nodo SOAPReply utiliza el identificador de respuesta para asegurarse de que el mensaje llega 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 HTTPReply utiliza el identificador de solicitud para asegurarse de que el mensaje llega 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);
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:37


Tema de conceptoTema de concepto | Versión 8.0.0.5 | ac34540_