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 llama a un servicio web existente

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.

El diagrama muestra un servicio web existente y el WSDL que lo describe. El WSDL se importa para crear un conjunto de mensajes. Un flujo de mensajes que utiliza el conjunto de mensajes se crea para llamar al servicio web y ambos se despliegan en un intermediario.

Clave de los símbolos:

El diagrama describe los símbolos que se utilizan en los otros diagramas, que no se describen aquí porque los diagramas tienen sus propias descripciones.

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 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.
  3. 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:
    El diagrama muestra un flujo de mensajes que proporciona una interfaz para el servicio Account utilizando nodos SOAPInput, SOAPRequest y SOAPReply.
  • Utilizando nodos SOAPInput, SOAPAsyncRequest, SOAPAsyncResponse y SOAPReply:
    El diagrama muestra dos flujos de mensajes que proporcionan una interfaz al servicio Account mediante el uso de nodos SOAPInput, SOAPAsyncRequest, SOAPAsyncResponse y SOAPReply.
  • Utilizando nodos HTTPInput, HTTPRequest y HTTPReply:
    El diagrama muestra un flujo de mensajes que proporciona una interfaz al servicio Account mediante el uso de 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:
    Este diagrama muestra un flujo de mensajes que llama a un servicio web utilizando nodos MQInput, SOAPRequest y MQOutput.
  • Utilizando nodos MQInput, SOAPAsyncRequest, SOAPAsyncResponse y MQOutput:
    Este diagrama muestra dos flujos de mensajes que llaman a un servicio web utilizando nodos MQInput, SOAPAsyncRequest, SOAPAsyncResponse y MQOutput.
  • Utilizando nodos MQInput, HTTPRequest y MQOutput:
    Este diagrama muestra una flujo de mensajes que llama a un servicio web 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.

Este diagrama muestra que puede colocar y, a continuación, recuperar la respuesta del servicio web en una ubicación temporal de un árbol de mensajes.

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.

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 | ac34530_