Detalles de cómo el intermediario implementa un nuevo servicio web

Obtenga información sobre un escenario típico de extremo a extremo donde el intermediario implementa un servicio Web.

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

El intermediario puede iniciar la operación 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 WebSphere 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 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.

El servicio web ofrece una interfaz basada en las operaciones ya expuestas por el sistema existente. Es posible que esta interfaz contenga todas las operaciones existentes, un subconjunto de ellas u operaciones compuestas, o ambas.

Para definir la interfaz:
  1. Examine la función de empresa ofrecida por el sistema existente.
  2. Seleccione el subconjunto de esta función de empresa que se debe exponer.
  3. Decida cómo se debe representar el subconjunto en la interfaz, es decir, como muchas operaciones discretas o como menos operaciones con varios usos.
Debe decidir si desea que la interfaz de servicio web sea de estilo RPC o de estilo de documento. Para obtener más información sobre servicios web, WSDL y flujos de mensajes, consulte Relación de WSDL con el modelo de mensaje.
  • Habitualmente una interfaz de estilo RPC está diseñada para correlacionarse en un conjunto de operaciones subyacente proporcionado por una API y las operaciones individuales (llamadas de método) tienen cargas útiles relativamente pequeñas.
  • Es posible que una interfaz de estilo de documento tenga menos operaciones, cada una de las cuales tiene una carga útil mayor; por ejemplo, un documento podría representar una petición de préstamo.
La Web Services Interoperability Organization (WS-I) recomienda que sólo se utilice WSDL de estilo de documento, pero muchos servicios Web más antiguos utilizan el estilo RPC.

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á utilizar el asistente de importador para crear los elementos globales necesarios en el modelo de intermediario. La WS-I recomienda que la carga útil de servicio web debe estar calificada para espacios de nombres, por lo tanto, el usuario debe especificar el espacio de nombres de destino en la importación.

    Ahora tiene un modelo de mensaje para los datos que se deben utilizar para empezar las operaciones existentes.

  2. Genere la definición de WSDL. A menos que ya haya creado las categorías de mensaje necesarias, cree una categoría de mensaje para cada operación de servicios web que se deba exponer y asocie los mensajes de intermediario existentes con los roles SOAP apropiados (entrada, salida o anomalía). Para obtener más información, consulte Cómo trabajar con un archivo de categoría de mensajes.
    • Si elige WSDL de estilo de documento, el propio conjunto de mensajes no se modifica.
    • Si elige WSDL de estilo RPC, los mensajes que corresponden a la petición y respuesta para cada operación WSDL se crean y se añaden automáticamente al conjunto de mensajes.
  3. El paso de generación de WSDL dará como resultado que los archivos mxsd de SOAP apropiados (archivos de definición de mensajes), que incluyen el archivo mxsd de sobre SOAP y (si el estilo WSDL está codificado con RPC) el archivo mxsd de codificación SOAP se incluyan automáticamente en el conjunto de mensajes.
  4. Si desea crear un nuevo cliente de servicios web, utilice el WSDL generado con la tecnología de cliente de servicios web elegida. Utilice una herramienta en lugar de WebSphere Message Broker; por ejemplo, puede utilizar Rational Application Developer o .NET.
  5. 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
  6. Cuando el analizador es iniciado por el flujo, el analizador crea un árbol lógico que consta del sobre SOAP como lo define el archivo 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 mensajes del conjunto de mensajes. Si es necesario, puede aplicar la validación en el nodo de entrada.

    Puede tener un árbol lógico pero no sabe qué carga útil SOAP se ha recibido. Compruebe el campo de acción SOAPAction de HTTP para determinar el posible contenido, aunque esto sólo funciona para HTTP. (WS-I no recomienda utilizar SOAPAction.)

  7. Puede proporcionar correlación de los mensajes de carga útil permitidos a los mensajes necesarios desde del sistema existente. Por ejemplo, puede tener una sola definición de correlación con los mensajes message1a y message1b, ambos correlacionados 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 para poder aplicar la correlación. Puede determinar qué carga útil se ha recibido utilizando ESQL de la forma indicada a continuación:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = 'foo') ...
     
    o puede utilizar una referencia de campo, por ejemplo:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = "foo") ...
     
    Cuando haya determinado la carga útil, puede correlacionar de forma apropiada el flujo a ramificar (por ejemplo, utilizando un nodo RouteToLabel), en donde cada ramificación tiene un nodo Mapping específico de contenido, el nodo Compute, o ambos. Si es necesario, para los flujos simples, puede codificar toda la lógica en un solo nodo Compute.

    Ahora inicie el sistema existente (normalmente sobre WebSphere MQ), recupere la respuesta esperada y propague la respuesta de servicio web. 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.

Para ver un escenario similar, consulte el siguiente ejemplo: Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.
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
Relación de WSDL con el modelo de mensaje
Tareas relacionadas
Detalles de cómo el intermediario implementa una interfaz de servicio web existente
El intermediario llama a un servicio web existente - detalles
Cómo trabajar con un archivo de categoría de mensajes
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

ac34570_