Detalles de cómo el intermediario implementa una interfaz de servicio web existente

Obtenga información sobre 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 (Detalles de cómo el intermediario implementa un nuevo servicio web), 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, los envía a la implementación subyacente y, a continuación, empaqueta los valores de retorno como respuesta de WebSphere 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, el servicio Web está restringido en lo que debe proporcionarse porque la definición de WSDL para el cliente de servicios Web ya existe.

Un posible escenario podría ser el de un cliente de servicios Web ampliamente distribuido que 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 estructura 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 Web Services Interoperability Organization (WS-I) recomienda que la carga útil de servicio Web esté calificada para espacios de nombres, por lo que el usuario debe especificar 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 analiza la petición SOAP correspondiente y debe transformarla al formato de datos existente necesario o desde el mismo. Puede inspeccionar las definiciones de mensaje importadas y utilizar los editores de correlación 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 da como resultado que los archivos mxsd de SOAP adecuados se incluyan automáticamente en el conjunto de mensajes. Específicamente, la importación incluye el archivo mxsd de sobre SOAP y, si es necesario, el archivo 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 WebSphere MQ, según el transporte utilizado por el cliente. Las propiedades de nodo de entrada son:
    • Dominio de mensajes: MRM
    • Conjunto de mensajes: conjunto de mensajes que contiene la definición de sobre SOAP
    • Tipo de mensaje: Sobre
    • Formato de mensaje: XML1
  5. Cuando lo invoca el flujo, el analizador crea un árbol lógico que consta del sobre SOAP como lo define el archivo mxsd SOAP suministrado. 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 debe determinar qué carga útil ha recibido antes de poder aplicar la correlación. Puede codificar ESQL de la manera siguiente:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = 'foo') ...
     
    o utilice una referencia de campo, por ejemplo:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = "foo") ...
     
    Cuando se conoce el contenido, el flujo se puede ramificar de la manera adecuada (por ejemplo, mediante un nodo RouteToLabel), donde cada ramificación tiene nodos de Mapping, nodos de Compute, o ambos. Si es necesario, para los flujos simples, puede codificar toda la lógica en un solo nodo Compute.

    Ahora invoque el sistema existente (normalmente sobre WebSphere MQ), recupere la respuesta esperada y propague la respuesta de servicio web. Este escenario es similar al descrito en Detalles de cómo el intermediario implementa un nuevo servicio web, excepto en que el flujo de mensajes también debe correlacionarse entre el formato de datos que el cliente de servicio Web utiliza y el formato utilizado por el sistema existente habilitado para WebSphere MQ. El diseñador de flujo de mensajes 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
Flujos de mensajes de dominios XML
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
Detalles de cómo el intermediario implementa una interfaz de servicio web existente
El intermediario llama a un servicio web existente - detalles
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:09

ac34580_