El intermediario implementa una interfaz de servicio web existente - detalle

A continuación se proporciona una visión general de un escenario típico de extremo a extremo donde tiene un cliente de servicio web y desea que el intermediario realice alguna función no de servicio web existente disponible para el mismo.

Un sistema existente basado en C o Cobol ofrece lógica de negocio que puede ser útil exponer como servicio web.

Como en el ejemplo anterior (El intermediario implementa un servicio web nuevo - detalles), existe algún mecanismo para que el intermediario invoque operaciones en el sistema existente (es decir, el sistema expone una interfaz al intermediario). Normalmente el sistema existente está habilitado para WebSphere MQ, lo que significa que recibe mensajes MQ que contienen datos de aplicación, despacha dichos datos a la implementación subyacente y, a continuación, empaqueta los valores de retorno como respuesta MQ. Las estructuras de datos proporcionadas a estas operaciones existentes y devueltas por dichas operaciones se definen en un archivo de cabecera C o un libro de copias Cobol.

Sin embargo, en este ejemplo, también hay una restricción en el aspecto que debe tener el servicio web, es decir, ya tenemos la definición WSDL para el cliente de servicios web.

Un posible escenario consistirá en que un cliente de servicios web ampliamente distribuido ya proporcione a los usuarios acceso a una posibilidad de negocio determinada y el rol del intermediario será ofrecer la misma interfaz a una nueva implementación basándose en el sistema existente. Quizá el proveedor de servicios web original ofrezca una calidad de servicio diferente o se deba interrumpir por alguna razón.

Como antes, el intermediario puede invocar la función de sistema existente a través de WebSphere MQ.

Para implementar el escenario:

  1. Importe las estructuras de datos de API existentes - por ejemplo utilizando el importador C. Si se debe utilizar WSDL de estilo de documento, deberá hacer que el asistente de importador cree los elementos globales necesarios en el modelo de intermediario. La WS-I (consulte http://www.ws-i.org/) recomienda que la carga útil de servicio web esté calificado para espacios de nombres, de forma que el usuario especifique el espacio de nombres de destino en la importación.

    En esta etapa tiene un modelo de mensaje para los datos que se deben utilizar al invocar las operaciones existentes.

  2. Importe el archivo WSDL existente para crear el modelo de mensaje apropiado para los documentos de instancia esperados (consulte Importación de estructuras de datos). El flujo analizará la petición SOAP correspondiente y necesitará transformarla al formato de datos existente necesario o de dicho formato. Puede inspeccionar las definiciones de mensaje importadas y utilizar los editores de correlación y/o ESQL para ayudar a crear el flujo. No se crean archivos de categoría ni se genera WSDL a partir del modelo de intermediario.
  3. El paso de importación de WSDL hará que los mxsds de SOAP apropiados se incluyan automáticamente en el conjunto de mensajes. Específicamente esto incluye el mxsd de sobre SOAP y, si es necesario, el mxsd de codificación SOAP.
  4. Implemente un flujo de mensajes para recibir la petición de servicio web, es decir, actuar como el proveedor de servicios web. Los nodos de punto final son HTTP o MQ en función del transporte utilizado por el cliente. Las propiedades de nodo de entrada son:
    • dominio: "MRM"
    • conjunto: conjunto de mensajes que contiene la definición de sobre SOAP
    • tipo: "Envelope"
    • formato: "XML1"
  5. Cuando lo invoca el flujo, el analizador crea un árbol lógico que consta del sobre SOAP como lo define el mxsd SOAP pre-empaquetado. El análisis continúa automáticamente en los puntos de conexión en el sobre SOAP (cuerpo y cabecera SOAP), intentando realizar la comparación con otras definiciones de mensaje del conjunto de mensajes. Si es necesario, aplique la validación en el nodo de entrada.

    En esta etapa, tiene un árbol lógico pero no sabe qué carga útil SOAP se ha recibido. Puede consultar el campo SOAPAction/action de HTTP para determinar el posible contenido aunque esto sólo funciona para HTTP. (WS-I no recomienda utilizar SOAPAction.)

  6. Puede proporcionar una sola correlación de los mensajes de carga útil permitidos a los mensajes necesarios desde del sistema existente. Por ejemplo, una sola definición de correlación puede correlacionar los mensajes message1a y message1b con el mismo destino message2.
    De forma alternativa, se pueden proporcionar correlaciones independientes para cada tipo de mensaje – o para grupos de tipos de mensaje relacionados. Esta propuesta puede producir definiciones de correlación más manejables y reutilizables. La desventaja es que el usuario tiene que determinar qué carga útil ha recibido para poder aplicar la correlación. Esto se puede realizar en ESQL como se indica a continuación:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = ‘foo’) ...
     
    o utilizando una referencia de campo, por ejemplo:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = “foo”) ...
     
    Una vez que se conoce el contenido, el flujo se puede ramificar de forma apropiada (por ejemplo RouteToLabel) de manera que cada ramificación tenga nodos Mapping y/o Compute específicos de contenido. Si es necesario, para los flujos simples se puede conservar toda la lógica en un nodo Compute individual.

    Ahora invoque el sistema existente (normalmente sobre WebSphere MQ), recupere la respuesta esperada y propague la respuesta de servicio web. Esto es como el escenario anterior (El intermediario implementa un servicio web nuevo - detalles), excepto en que el flujo de datos también debe establecer una correlación entre el formato de datos utilizado por el cliente de servicio web y el formato utilizado por el sistema existente habilitado para WebSphere MQ. El diseñador de flujo de datos debe tener en cuenta la posibilidad de que la aplicación de empresa no envíe la respuesta esperada en un periodo de tiempo razonable.

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 nueva
El intermediario implementa una interfaz de servicio web existente
El intermediario implementa una interfaz no de servicio web en servicio web nuevo
Tareas relacionadas
El intermediario implementa una interfaz de servicio web existente - detalle
El intermediario llama a un servicio web existente - detalles
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac34580_