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:
- Asegurar la entrega de un mensaje SOAP cuando un servidor se reinicia inesperadamente.
- 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.

El escenario del ejemplo
Estos son los pasos que describen cómo funciona el ejemplo cuando WS-RM está habilitado:
- 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.
- El consumidor solicita la creación de una nueva Secuencia.
- El proveedor crea una nueva Secuencia y devuelve su Identificador exclusivo.
- 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.
- El consumidor también incluye una cabecera AckRequested para asegurar que obtiene un
acuse de recibo de secuencia (SequenceAcknowledgement) oportuno para la secuencia.
- 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.
- 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.
- El proveedor recibe la segunda transmisión del mensaje con MessageNumber 1 y acusa
recibo del número de mensaje 1.
- 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.
- 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