WS-Reliable Messaging

Los flujos de mensajes se importan sin que WS-Reliable Messaging esté habilitado. Cualquiera puede llamar al servicio web para consumir los mensajes, de forma similar a un supervisor TCP/IP con SOAP sobre HTTP. Para habilitar WS-Reliable Messaging, consulte Ampliar el ejemplo de Libreta de direcciones.

Habilitar WS-RM es una tarea administrativa que se realiza a nivel de WebSphere Message Broker. No puede configurar WS-RM al desarrollar flujos de mensajes; debe configurar la política en el intermediario y asociarla con los flujos de mensajes en un archivo archivador de intermediario (BAR).

¿Por qué utilizar WS-Reliable Messaging?

En el ejemplo de ampliación de Libreta de direcciones, el consumidor y el proveedor tienen los mismos requisitos de mensajería segura:

  1. Asegurar la entrega de un mensaje SOAP cuando un servidor se reinicia inesperadamente.
  2. Asegurar la entrega de un mensaje SOAP cuando la conexión entre el cliente y el servidor falla, por ejemplo debido a un tiempo de espera excedido. El cliente debería poder detectar la condición y reintentar la transmisión del mensaje.

El protocolo WS-RM satisface estos requisitos al definir cómo enviar de nuevo los mensajes que determina que no se han entregado satisfactoriamente, e impidiendo la entrega de mensajes duplicados a la aplicación de destino.

Cómo funciona WS-Reliable Messaging

La clave de WS-RM es el concepto de secuencia. Una secuencia en WS-RM es un contrato entre un cliente de servicios web y un proveedor de servicios web, por el cual se comprometen a transmitir mensajes entre ellos de forma segura y fiable. La secuencia se utiliza para mantener el estado de los mensajes que se han enviado y recibido. La secuencia en sí misma es específica del punto final de un proveedor. Cuando un cliente envía por primera vez un mensaje al punto final de un proveedor de servicios web, se crea una secuencia para el punto final de ese proveedor, y todos los mensajes subsiguientes de ese cliente al punto final de ese proveedor se entregan en esa secuencia. La secuencia permite al WS-RM de la parte del cliente y de la parte del proveedor decidir si los mensajes de la aplicación deben entregarse de nuevo, y detectar si los mensajes que llegan son duplicados.

Para definir secuencias y mantener el estado actual, el WS-RM del cliente y del proveedor utiliza una colección de mensajes de protocolo definidos que se envían de una parte a otra. El diagrama siguiente muestra un flujo de mensajes típico para una invocación de servicio web de solicitud-respuesta utilizando WS-RM.

Una secuencia de intercambio de mensajes WS-RM típica, que se describe en los pasos siguientes.

El escenario del ejemplo

Estos son los pasos que describen cómo funciona el ejemplo cuando WS-RM está habilitado:

  1. Se establecen las condiciones previas del protocolo. Estas incluyen el intercambio de políticas, la resolución de puntos finales y el establecimiento de la confianza.
  2. El consumidor solicita la creación de una nueva Secuencia.
  3. El proveedor crea una nueva Secuencia y devuelve su Identificador exclusivo.
  4. El consumidor inicia la transmisión de mensajes en la Secuencia empezando por el Número de mensaje (MessageNumber) 1. Cada solicitud enviada por el nodo SOAPRequest creará una nueva secuencia, por lo que todos los mensajes tendrán MessageNumber 1.
  5. El consumidor también incluye una cabecera AckRequested para asegurar que obtiene un acuse de recibo de secuencia (SequenceAcknowledgement) oportuno para la secuencia.
  6. El proveedor acusa recibo del número de mensaje 1 como resultado de recibir la cabecera AckRequested del consumidor. Si algún mensaje se pierde por cualquier motivo, no se enviará ningún acuse de recibo al consumidor.
  7. El consumidor vuelve a transmitir el mensaje sin acuse de recibo con el mismo MessageNumber. Este es un mensaje nuevo desde la perspectiva del transporte subyacente, pero tiene el mismo Identificador de secuencia y Número de mensaje para que el proveedor pueda reconocerlo como un duplicado del mensaje anterior en el caso de que se reciban tanto el mensaje original como el retransmitido. El consumidor incluye una cabecera AckRequested en el mensaje retransmitido para que el proveedor agilice un acuse de recibo.
  8. El proveedor recibe la segunda transmisión del mensaje con MessageNumber 1 y acusa recibo del número de mensaje 1.
  9. El consumidor recibe este acuse de recibo y envía un mensaje TerminateSequence al proveedor indicando que la secuencia ha finalizado. El mensaje TerminateSequence indica que el número de mensaje 1 era el último mensaje de la secuencia.
  10. El proveedor recibe el mensaje TerminateSequence, que indica que el consumidor no va a enviar más mensajes. El proveedor envía un mensaje TerminateSequenceResponse al consumidor y reclama los recursos asociados a la secuencia.

Los detalles de si los mensajes se deben entregar en orden o no se encuentran en el conjunto de políticas WS-RM. Utilice el diagrama anterior como referencia.

Volver a Ampliar el ejemplo de Libreta de direcciones

Volver a la página inicial del ejemplo