En este escenario, el intermediario implementa una interfaz 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 recibe una solicitud y, a continuación, compila un mensaje de respuesta utilizando los datos obtenidos de una aplicación no de servicio web existente.

Clave de los símbolos:

Usos posibles
- El intermediario proporciona una implementación de servicios web con una calidad
de servicio diferente respecto a las implementaciones existentes.
- El intermediario proporciona una estrategia de migración para la implementación
existente.
Pasos de diseño
- Importe WSDL para crear un conjunto de mensajes que contenga definiciones para los mensajes
SOAP descritos por el WSDL.
- Adapte el conjunto de mensajes para la interfaz existente necesaria, posiblemente
importando una definición de interfaz existente, por ejemplo un archivo de cabecera C
o un libro de copias COBOL.
- Desarrolle un flujo de mensajes para implementar el servicio web.
En el tiempo de ejecución
El flujo de mensajes recibe una solicitud 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
En este ejemplo, un cliente de servicio
web HTTP existente proporciona información sobre un tema en particular (por ejemplo precios
de acciones o tasas de cambio). Desea sustituir este servicio por una solución de búsqueda de base de datos interna, pero no desea realizar cambios en los clientes porque éstos están muy desplegados.
En los siguientes ejemplos se muestran patrones de flujos de mensajes típicos. En cada caso, el nodo de solicitud de intermediario recupera la información de la base de datos:
- Utilización de los nodos SOAPInput y SOAPReply:
- Utilización de los nodos HTTPInput y HTTPReply:
En los flujos anteriores, el nodo de entrada recibe la solicitud de servicio web. A continuación, Compute1 recupera la información necesaria de la base de datos y con estos datos genera la respuesta de servicio web necesaria. La respuesta la devuelve al el nodo de respuesta. En los ejemplos, puede utilizar nodos Mapping en lugar de nodos Compute.
Ejemplo 2
En este ejemplo, una aplicación existente se presenta como servicio web, pero hay un límite en la interfaz con el servicio web, puesto que existe un cliente ampliamente distribuido que ya utiliza un servicio parecido definido por la definición WSDL existente. El intermediario ofrece la misma interfaz al cliente, y esto podría deberse a que el servicio original ofrece una calidad de servicio distinta o se va a dejar de mantener.
En los siguientes ejemplos se muestran patrones de flujos de mensajes típicos. En cada caso los flujos de mensajes reciben la solicitud de servicio web y compilan la respuesta utilizando los datos devueltos desde la aplicación a través de WebSphere MQ.
- Utilización de los nodos SOAPInput, SOAPReply y MQGet:
- Utilización de los nodos HTTPInput, HTTPReply y MQGet:
- Utilización de dos flujos de mensajes con los nodos SOAPInput, SOAPReply:
- Utilización de dos flujos de mensajes con los nodos HTTPInput y HTTPReply:
Las pasos para desarrollar el flujo de mensajes son:
- Cree un modelo de mensajes para la interfaz de aplicación existente, por ejemplo, importando una cabecera de archivo C para la aplicación.
- Importe una definición WSDL existente para el cliente.
- Cree un flujo utilizando el conjunto de mensajes para implementar la interfaz de servicios web y mediar con la aplicación existente.
Los flujos de mensajes 1 y 2 muestran una llamada síncrona a la aplicación utilizando nodos
MQOutput y
MQGet. Puede establecer un tiempo de espera en el nodo
MQGet,
por si la aplicación remota sufriera una anomalía. La conversión de solicitud-respuesta se maneja en una sola transacción lo que permite una restitución y recuperación simples. Sin embargo, cada solicitud de entrada tiene que procesarse y responderse antes de pasar a la solicitud siguiente. Este comportamiento puede afectar al rendimiento si la aplicación no puede responder rápidamente.
Los flujos de mensajes se muestran en los ejemplos 3 y 4, muestran un equivalente asíncrono. En cada caso, el primer flujo se detiene después de enviar el mensaje a la aplicación, pasa a estar disponible para manejar más solicitudes. Sin embargo, este escenario requiere un contexto de correlación para guardarlo en el flujo de solicitudes y restaurarlo en el flujo de respuestas. El contexto de correlación se puede almacenar en una cola y, a continuación, utilizar un nodo
MQGet
en el flujo de respuestas para recuperarlo. Este diseño de flujo permite despachar en seguida las solicitudes a la aplicación y devolver las respuestas en el orden en el que se se reciben. En los ejemplos, puede utilizar nodos
Mapping en lugar de nodos
Compute.
Se prefiere el uso del 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.
Para obtener más información sobre el escenario de petición-respuesta asíncrona, consulte Un escenario de solicitud-respuesta que utiliza un nodo MQGet.
El escenario de petición-respuesta asíncrona se detalla también en el siguiente ejemplo que se puede adaptar para el uso del servicio web:
Se describe otro escenario de servicios web en el ejemplo:
Puede
ver información sobre los ejemplos sólo cuando utilice el Information Center que está integrado en WebSphere Message Broker Toolkit o el Information Center
en línea. Puede
ejecutar ejemplos sólo cuando utilice el Information Center que está
integrado en WebSphere Message Broker Toolkit.