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 no de servicio web existente.

El diagrama muestra una aplicación existente, cuyo archivo de definición se importa a un conjunto de mensajes. Se genera un archivo WSDL a partir del conjunto de mensajes. El conjunto de mensajes se despliega en un flujo en un intermediario. El flujo interactúa en la ejecución con la aplicación existente original y el cliente de servicio web.

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 esto se denomina fachada de servicio web. El diseño de la interfaz de servicio web incluirá normalmente la reagrupación, restricción o mejora de la interfaz existente y no está limitada por ninguna definición WSDL existente.

Usos posibles

El intermediario proporciona una interfaz de servicios web a una aplicación existente, proporcionando opcionalmente otras posibilidades combinadas, por ejemplo comprobar las peticiones realizadas.

Con el tiempo la implementación se puede cambiar sin que ello afecte a la interfaz presentada al cliente de servicios web.

Pasos de diseño

  1. Cree un conjunto de mensajes para los mensajes de negocio, 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 los nodos: HTTPInput, HTTPReply y CICS.
  3. Utilice los nodos HTTPInput y HTTPReply para proporcionar la fachada de servicio web.
  4. Utilice el nodo CICS para invocar la implementación de 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.


Esto representa un flujo de mensajes con los nodos HTTPInput, Compute1, DataUpdate, Compute2, 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 XML o 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 por omisión para el mensaje de respuesta enviado al cliente. Esto reduce las modificaciones que debe realizar para convertir un flujo de mensajes 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 petición y un nodo MQOutput para enviar la petición 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 primero debe guardar la información de estado HTTP que el segundo recupera para asegurar que las respuestas de la aplicación WebSphere MQ se devuelven al cliente que ha enviado la petición original.


Esto representa dos flujos de mensajes; el primero tiene los nodos HTTPInput, Compute1, MQOutput. El segundo tiene MQInput, Compute2, 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 petición como un campo del árbol LocalEnvironment denominado Destination.HTTP.RequestIdentifier y 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. Compute2 lee el identificador de petición HTTP en 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 Compute1, incluya una sentencia como la siguiente:

SET OutputRoot.XML.A.MessageID =    
			CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);

En el módulo ESQL para Compute2, codifique una sentencia como la siguiente:

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =     
			CAST(InputRoot.XML.A.MessageID AS BLOB);
Conceptos relacionados
Servicios web, WSDL y flujos de mensajes
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, 2006 Última actualización: 22/08/2006
ac34540_