El intermediario implementa un servicio web nuevo - detalles

A continuación se proporciona una visión general de 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 negocio que puede ser útil exponer como servicio web.

Existe un 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.

El servicio web es ofrecer 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 y/u operaciones compuestas.

Para definir la interfaz:
  1. Examine la función de negocio ofrecida por el sistema existente
  2. Seleccione el subconjunto de esta función de negocio que se debe exponer
  3. Decida cómo se debe representar éste en la interfaz (como muchas operaciones discretas o como menos operaciones con varios usos)
Una decisión básica consiste en determinar si la interfaz de servicio web será de estilo RPC o de estilo de documento. (Consulte Servicios web, WSDL y flujos de mensajes y Relación de WSDL con el modelo de mensaje).
  • Generalmente una interfaz de estilo RPC está diseñada para correlacionarse en un conjunto de operaciones subyacente proporcionado por alguna 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 puede ser un documento que representa una petición de préstamo.
La WS-I (consulte http://www.ws-i.org/) recomienda utilizar sólo 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á hacer que el asistente de importador cree los elementos globales necesarios en el modelo de intermediario. La WS-I 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. 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). (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 hará que los mxsds de SOAP apropiados (archivos de definición de mensajes) se incluyan automáticamente en el conjunto de mensajes. Específicamente esto incluye el mxsd de sobre SOAP y (si el estilo WSDL está codificado con RPC) el mxsd de codificación SOAP.
  4. Si está creando un nuevo cliente de servicios web, utilice el WSDL generado con la tecnología de cliente de servicios web elegida. Para ello, utilice una herramienta distinta de WebSphere Message Broker, por ejemplo 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 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"
  6. 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.)

  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 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”) ...
     
    Después de esto, ahora que se conoce el contenido, el flujo se puede ramificar de forma apropiada (por ejemplo utilizando un nodo 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. 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.

Para ver un escenario similar, consulte el ejemplo: Ejemplo Sistema principal de servicio web.

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
ac34570_