En este escenario, el intermediario invoca una implementación de servicio web existente. El WSDL para el servicio web ya existe y se
importa para crear un conjunto de mensajes.
Un flujo de mensajes basado en este conjunto de mensajes envía una solicitud de
servicio web y recibe la respuesta, por ejemplo, utilizando un nodo
SOAPRequest.
Clave de los símbolos:
Usos posibles
- Desea llamar a un servicio web para que efectúe algún proceso como parte del
flujo de mensajes.
- 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 se utiliza el dominio SOAP, flujo de mensajes utiliza un nodo SOAPRequest, un nodo SOAPAsyncRequest o un nodo SOAPAsyncResponse. Los nodos se configuran
utilizando el WSDL importado en el paso 1. Si es necesario, puede crear un flujo de
esqueleto partiendo de cero soltando el WSDL en un lienzo en blanco del editor de flujos
de mensajes. Si utiliza el dominio SOAP, debe crear el flujo de mensajes utilizando los nodos de transporte y un dominio
XML o MIME. Por ejemplo, si el enlace WSDL especifica el transporte HTTP y el mensaje de solicitud es
SOAP, puede utilizar un nodo HTTPRequest con el dominio XMLNSC.
A continuación podrá configurar manualmente el nodo con la información de punto final para el servicio web.
- Cree un archivo de archivado de intermediario para el despliegue. El archivo de archivado de intermediario contiene el flujo de mensajes y el conjunto de mensajes que contiene un WSDL importado. El dominio SOAP siempre requiere que se despliegue WSDL,
porque los mensajes se verifican respecto a un entorno de tiempo de ejecución; también se
incluye información WSDL en el árbol lógico. El conjunto de mensajes incluye definiciones de esquemas XML que se pueden utilizar para la validación de mensajes en los dominios SOAP, XMLNSC o MRM.
En tiempo de ejecución
El flujo de mensajes crea una solicitud de servicio
web apropiadamente formateada, invoca el servicio web y analiza la respuesta de servicio
web. Si utiliza el dominio SOAP, el flujo de mensajes utiliza el modelo de árbol lógico
SOAP. Si no utiliza el dominio SOAP, el flujo de mensajes utilizará el árbol lógico para
el dominio seleccionado; por ejemplo, se utiliza el dominio MIME si los mensajes de
servicios web utilizan SOAP con adjuntos.
Ejemplo 1
- Intermediario de servicio web
- En este ejemplo, una aplicación cliente utiliza un servicio web llamado Account, que facilita otra organización. El cliente está ampliamente distribuido en la empresa. El cliente utiliza una operación llamada getBalance, pero el servicio Account se modifica para cambiar la definición de la operación
getBalance. Puede construir flujos de mensajes para proporcionar una interfaz para el servicio Account, en lugar de modificar el cliente. Los flujos de mensajes pueden llamar al servicio Account de modo que hagan el trabajo y el nuevo servicio web delega al servicio web original.
Ahora, el cliente puede seguir utilizando el servicio Account, mediante los nuevos flujos
de mensajes.
En los ejemplos de los patrones de flujos de mensajes típicos que aquí aparecen, el nodo de solicitud intermedio llama al servicio Account:
- Utilizando nodos SOAPInput,
SOAPRequest y SOAPReply:
- Utilizando nodos SOAPInput,
SOAPAsyncRequest, SOAPAsyncResponse y SOAPReply:
- Utilizando nodos HTTPInput,
HTTPRequest y HTTPReply:
En
los flujos de mensajes del ejemplo, Compute1 modifica el mensaje getBalance original tal
como precisa el servicio Account modificado, mientras que Compute2 restaura el mensaje de
respuesta al formato original. Si ha importado o generado WSDL, tendrá un modelo de
mensaje para la operación getBalance. Si ha definido un modelo de mensaje para la operación getBalance, puede utilizar los
nodos Mapping en lugar de los nodos
Compute.
Detalles de HTTP
Si
utiliza los nodos de transporte HTTP, como se muestra en el ejemplo, puede configurar el
nodo HTTPRequest para generar cabeceras HTTP a
partir de cabeceras recibidas por el nodo HTTPInput. Esta configuración permite que los cookies y otras cabeceras específicas de la aplicación
pasen a través del flujo de mensajes. El nodo
HTTPReply se puede utilizar para extraer
cabeceras de la respuesta del servicio web, para devolver al cliente que las origina. Para
crear esta configuración, seleccione Generar cabeceras HTTP predeterminadas
desde en los nodos HTTPRequest y
HTTPReply. Normalmente, no es necesario que el
mensaje de solicitud original genere la respuesta al cliente y puede seleccionar
Sustituir mensaje de entrada por respuesta de servicio web en el
nodo HTTPRequest. Si desea conservar datos de
la solicitud de entrada, puede almacenarlos en el entorno local de Compute1 y
recuperarlos en Compute2 para incluirlos en la respuesta.
Ejemplo 2
- Utilización de un servicio web
- En este ejemplo, un flujo de mensajes de WebSphere MQ
implementa un proceso para el departamento de Recursos humanos de su empresa. Como parte
de este proceso, el flujo de mensajes llama a un servicio web para que recupere números
de ID de empleado. Los números de ID de empleado se mantienen en el directorio de
empleados de la empresa, a la que se accede a través de un servicio web.
En los
ejemplos de los patrones de flujos de mensajes típicos que aquí aparecen, el nodo de
solicitud intermedio recupera el ID de empleado:
- Utilizando nodos MQInput, SOAPRequest y MQOutput:
- Utilizando nodos MQInput,
SOAPAsyncRequest,
SOAPAsyncResponse y MQOutput:
- Utilizando nodos MQInput,
HTTPRequest y MQOutput:
En los flujos de
mensajes del ejemplo, Compute1 prepara el mensaje de solicitud de servicio web y Compute2
procesa la respuesta.
Por ejemplo, incorporando el ID de empleado en otro mensaje.
Si ha
definido un modelo de mensaje, puede utilizar los nodos
Mapping en lugar de los nodos
Compute en estos ejemplos.
Detalles de HTTP
Si utiliza nodos de transporte HTTP, como se
muestra en el ejemplo, en general debe deseleccionar Sustituir mensaje de
entrada por respuesta de servicio web en las propiedades del nodo
HTTPRequest.
La respuesta del servidor de directorios corporativo se coloca en una ubicación temporal
del árbol de mensaje. La ubicación temporal se especifica en la propiedad
Ubicación del mensaje de respuesta en el árbol en el mismo nodo. En Compute2, puede codificar
ESQL para recuperar el resultado y actualizar el mensaje final.
Es preferible utilizar el dominio SOAP para estos casos.
Para obtener más información sobre cómo elegir un dominio para servicios web, consulte WebSphere Message Broker y servicios web.