El intermediario llama a un servicio web existente

En este escenario, el intermediario invoca una implementación de servicio web existente. .

El diagrama muestra un servicio web existente y el WSDL que lo describe. El WSDL se importa para crear un conjunto de mensajes. Se crea un flujo de mensajes utilizando el conjunto de mensajes para invocar el servicio web y los ambos de despliegan en el intermediario.

Clave de los símbolos:

Este diagrama describe los símbolos utilizados en los demás diagramas y no se describe aquí porque cada uno de esos diagramas tiene su propia descripción.

Usos posibles

Pasos de diseño

  1. Importe WSDL para crear un conjunto de mensajes que contenga definiciones para los mensajes SOAP descritos por el WSDL.
  2. Cree un flujo de mensajes para invocar el servicio web. Si el transporte del servicio web es HTTP, se utilizará un nodo HTTPrequest. Si el transporte de servicio web es JMS, se utilizarán los nodos JMS o WebSphere MQ apropiados.

Ejecución

El flujo de mensajes crea una petición de servicio web apropiadamente formateada, invoca el servicio web y analiza la respuesta de servicio web.

Ejemplo 1

En este ejemplo, el intermediario actúa como mediador en el servicio web.

  1. Cree un flujo de mensajes con nodos: HTTPInput, HTTPRequest y HTTPReply.
  2. El cliente de servicio web genera una petición de servicio web. El intermediario la dirige al nodo HTTPInput.
  3. El flujo de mensajes procesa el mensaje de alguna manera.
  4. El nodo HTTPRequest envía una petición al servicio web original y recibe la respuesta.
  5. El flujo genera una respuesta de servicio web y la pone en el nodo HTTPReply. La respuesta puede estar basada, en su totalidad o en parte, en la respuesta recibida por el nodo HTTPRequest.
  6. El intermediario envía la respuesta al cliente de servicio web.

Si otra aplicación habilitada para WebSphere MQ necesita la información en un formato diferente, el flujo de mensajes puede disponer que el mensaje se propague a un nodo MQOutput para la transmisión a esta aplicación antes de continuar hasta el final del flujo y al nodo HTTPReply que envía la respuesta de servicio web esperada. Se necesitarán nodos Compute apropiados para transformar el mensaje (si es necesario) y para manipular las cabeceras de mensaje (por ej. añadir una cabecera MQMD).

Ejemplo 2

En este ejemplo el intermediario proporciona auditoría para un servicio web.

  1. Diseñe un flujo de mensajes que incluya un nodo HTTPInput conectado a un nodo Warehouse.
  2. El nodo Warehouse almacena el mensaje de entrada recibido del cliente de servicio web en la base de datos.
  3. El nodo Warehouse pasa el mensaje a un nodo HTTPRequest, que interactúa con el servicio web.
  4. Cuando se recibe la respuesta, el nodo HTTPRequest la propaga al nodo HTTPReply.
  5. El nodo HTTPReply genera la respuesta para el cliente de servicio web.

Ejemplo 3

El flujo de WebSphere MQ interactúa con un servicio web
Diseñe un flujo de mensajes de WebSphere MQ que acceda a un servicio web a través de una conexión HTTP. Por ejemplo, cree un flujo de mensajes que soporte un proceso para el departamento de Recursos humanos de su empresa. El proceso debe recuperar los números de ID de empleado y ampliar el mensaje con esta información. Los ID de empleado se mantienen en el directorio de empleados de la empresa a la que se accede mediante un servicio web.
Esto representa un flujo de mensajes con los nodos MQInput, Compute1, HTTPRequest, Compute2, MQOutput. El nodo HTTPRequest interactúa con el servidor de directorios de empresa a través de una conexión HTTP.

En este escenario, normalmente eliminará la marca del recuadro de selección Sustituir mensaje de entrada por respuesta de servicio web en las propiedades de nodo HTTPRequest y pondrá la respuesta del servidor de directorios de empresa en una ubicación temporal del árbol de mensaje especificado en la propiedad Ubicación del mensaje de respuesta en el árbol del mismo nodo. En Compute2, codifique ESQL para desempaquetar el resultado y aumente el mensaje final como sea apropiado.

Ejemplo 4

El flujo de mensajes actúa como intermediario de servicio web
Diseñe un flujo de mensajes que interactúe con un servicio web que haya actualizado la interfaz en nombre de los clientes de servicio web que no están informados de la nueva interfaz. Este nuevo flujo de mensajes permite que clientes más antiguos accedan al servidor utilizando la nueva interfaz sin actualizar sus propias interfaces.
Esto representa un flujo de mensajes con los nodos HTTPInput, Compute1, HTTPRequest, Compute2, HTTPReply. El nodo HTTPRequest interactúa con el servidor de directorios de empresa a través de una conexión HTTP.

Codifique ESQL en Compute1 para correlacionar la petición de cliente con una petición de servidor y en Compute2 para correlacionar la respuesta de servidor con la respuesta de cliente. Puede definir estos mensajes de petición y respuesta en el dominio MRM para simplificar la transformación de un formato a otro.

Puede configurar el nodo HTTPRequest para generar cabeceras HTTP a partir de las cabeceras recibidas por el nodo HTTPInput, lo que permite pasar a través de los cookies y otras cabeceras específicas de aplicación. El nodo HTTPReply puede proporcionar una tarea equivalente para extraer cabeceras de la respuesta del servicio web para devolverlas al cliente que las origina. Si desea realizar esto, marque el recuadro de selección Generar cabeceras HTTP predeterminadas desde... apropiado en los nodos HTTPRequest y HTTPReply.

En la mayoría de los escenarios, la petición original no tiene ningún valor y sólo necesita la respuesta del servicio para poder generar el mensaje de respuesta de cliente. Si éste es su caso, seleccione la propiedad Sustituir mensaje de entrada por respuesta de servicio web en el nodo HTTPRequest. Si desea conservar datos de la petición de entrada, puede almacenarlos en el entorno local de Compute1 y recuperarlos en Compute2 para incluirlos en la respuesta.

Conceptos relacionados
Flujos de mensajes de dominios XML
El intermediario implementa una interfaz de servicio web nueva
El intermediario implementa una interfaz de servicio web existente
El intermediario implementa una interfaz no de servicio web en servicio web nuevo
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última actualización : 2009-02-16 13:54:08

ac34530_