El intermediario implementa una interfaz de servicio web nueva

En este escenario de servicio web, el intermediario proporciona una interfaz de servicio web a una aplicación existente que no es de servicio web.

El diagrama muestra un conjunto de mensajes que se crean desde una definición de interfaz (por ejemplo, un archivo de cabecera) de una aplicación existente al que no se puede acceder 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. Para invocar la aplicación se crea un flujo de mensajes y el WSDL. 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.

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.

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.

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

Una aplicación CICS existente tiene una interfaz de libro de copias COBOL.

  1. Importe el libro de copias COBOL para crear un modelo de mensaje.
  2. Cree un flujo de mensajes con nodos: HTTPInput, HTTPReply y CICS.
  3. Utilice los nodos HTTPInput y HTTPReply para proporcionar la fachada del servicio web.
  4. Utilice el nodo CICS para invocar la implementación CICS original.

Ejemplo 2

El flujo de mensajes se invoca como un servicio web
Modifique el diseño de un flujo de mensajes existente para interactuar con clientes de servicio web a través de HTTP. El flujo de mensajes existente toma un mensaje de entrada definido correctamente y el cliente puede utilizar WSDL exportado de las herramientas de WebSphere Message Broker al invocar el flujo de mensajes.

La mayoría de flujos de mensajes que utilizan actualmente WebSphere MQ para entrada o salida se pueden adaptar para utilizar HTTP como protocolo de sustitución o adicional.

Representa un flujo de mensajes con nodos HTTPInput, Compute1, DataUpdate, Compute2 y HTTPReply.

Puede modelar el mensaje de entrada en el dominio MRM y generar WSDL a partir del modelo o puede procesar un mensaje de dominio XMLNS genérico. Si ha definido el mensaje en el dominio MRM, puede configurar el nodo HTTPInput para validar el mensaje de entrada. El nodo genera una excepción si el mensaje no se ajusta a las normas del modelo.

Puede configurar el nodo HTTPReply a fin de 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 procesa mensajes de WebSphere MQ en un flujo que procesa mensajes HTTP.

Ejemplo 3

El flujo de mensajes proporciona acceso a una aplicación WebSphere MQ
Diseñe dos flujos de mensajes que reciban peticiones de clientes de servicio web y envíen respuestas a dichos clientes y que interactúen con una aplicación WebSphere MQ existente que no se ha adaptado para comunicarse a través de HTTP.

El primer flujo de mensajes recibe peticiones de entrada de los clientes de servicio web en un nodo HTTPInput. Incluye un nodo Compute para transformar de algún modo la solicitud y un nodo MQOutput para enviar la solicitud modificada a la aplicación WebSphere MQ.

El segundo flujo de mensajes recibe la respuesta de dicha aplicación en un nodo MQInput. El mensaje se pasa a un nodo Compute que lo transforma y lo propaga a un nodo HTTPReply que lo envía como respuesta al cliente de servicio web original.

Aunque es posible que las transformaciones realizadas por cada nodo Compute sean triviales, el código ESQL del primer nodo Compute debe guardar información de estado HTTP que recuperará el segundo nodo Compute para asegurarse de que las respuestas de la aplicación WebSphere MQ se devuelven al cliente que ha enviado la solicitud original.

Representa dos flujos de mensajes; el primero tiene nodos HTTPInput, Compute1 y MQOutput. El segundo tiene MQInput, Compute2 y HTTPReply. El nodo MQOutput que termina el primer flujo pone un mensaje en una cola WebSphere MQ atendida por una aplicación existente, que pone las respuestas en la cola de entrada atendida por el nodo MQInput que inicia el segundo flujo.

El primer flujo de mensajes recibe el mensaje, realiza las transformaciones que sean necesarias y codifica el identificador de petición HTTP en el mensaje de salida. (El identificador de petición también se puede almacenar en una base de datos, si lo prefiere). El nodo HTTPInput proporciona el identificador de solicitud como campo en el árbol de entorno local llamado Destination.HTTP.RequestIdentifier y el nodo Compute1 puede leer y almacenar este valor.

El segundo flujo de mensajes recibe el mensaje de respuesta y lo vuelve a transformar al formato de mensaje de cliente. 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 petición para asegurarse de que el mensaje llega al cliente HTTP correcto.

La implementación de este escenario requiere que se maneje correctamente el MQMD. A los mensajes que entran en un flujo de mensajes a través de HTTP se les debe añadir un MQMD antes de que se envíen a un nodo MQOutput. Asimismo, se debe eliminar el MQMD de los mensajes que entran a través de WebSphere MQ antes de que se envíen a un nodo HTTPReply o HTTPRequest (a menos que se desee incluir un MQMD en la corriente de datos HTTP).

En el módulo ESQL para el nodo Compute1, incluya una sentencia de código similar a la del siguiente ejemplo:

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ódio similar a la de la siguiente sentencia:

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =     
			CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
Conceptos relacionados
Flujos de mensajes de dominios XML
El intermediario llama a un servicio web existente
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

ac34540_