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

Clave de los símbolos:

Usos posibles
- Tiene un flujo de mensajes y desea que éste utilice
una función ya disponible como servicio web.
- Tiene un servicio web existente y desea proporcionarle una interfaz diferente. Ésta puede ser una interfaz de servicios web alternativa o una interfaz de
WebSphere MQ.
- Tiene un servicio web existente y desea cambiar de algún modo la implementación del mismo
sin cambiar la interfaz; es decir, el intermediario actúa como mediador
en el servicio web. Por ejemplo, se puede utilizar un flujo de mensajes
para habilitar la auditoría o propagar de forma transparente la respuesta de servicio web
a otra aplicación.
Pasos de diseño
- Importe WSDL para crear un conjunto de mensajes que contenga definiciones para los mensajes
SOAP descritos por el WSDL.
- Cree un flujo de mensajes para invocar el servicio web. Si el transporte de 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.
- Cree un flujo de mensajes con nodos: HTTPInput,
HTTPRequest y HTTPReply.
- El cliente de servicio web genera una petición de servicio web. El intermediario
la dirige al nodo HTTPInput.
- El flujo de mensajes procesa el mensaje de alguna manera.
- El nodo HTTPRequest envía una petición al servicio web original y recibe la respuesta.
- 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.
- 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.
- Diseñe un flujo de mensajes que
incluya un nodo HTTPInput conectado a un nodo Warehouse.
- El nodo Warehouse almacena el mensaje de entrada recibido del cliente de servicio web
en la base de datos.
- El nodo Warehouse pasa el mensaje a un nodo HTTPRequest, que interactúa con el
servicio web.
- Cuando se recibe la respuesta, el nodo HTTPRequest la propaga al nodo
HTTPReply.
- 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
al que se accede a través de un servicio web.

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 a los clientes más antiguos acceder al servidor
utilizando las interfaces nuevas sin actualizar sus propias interfaces.

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 por omisión 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.