Web Services Reliable Messaging

IBM® Integration Bus supports WS-RM (Web Services Reliable Messaging), which allows two systems to reliably exchange messages with each other.

Web Services Reliable Messaging (WS-RM) is an OASIS standard that allows two systems to reliably exchange SOAP messages with each other. The purpose of WS-RM is to ensure delivery of messages in situations such as the destination endpoint being temporarily unavailable (for example, in the case of a server restart) or the message path crossing multiple transport connections, any of which might fail (for example, across a firewall). WS-RM offers greater reliability when using HTTP transport, but has a performance impact.

WS-RM is applicable only to HTTP transport. If you configure WS-RM on a message flow that uses JMS transport, the WS-RM settings are not used when the flow is deployed.

Systems that implement WS-RM retransmit messages that have not been successfully delivered and acknowledged, and prevent duplicate messages from being delivered to the application destination. WS-RM is a web services protocol and can be used with WS-Security and WS-Addressing.

The initial sender transmits a message from the application source to the reliable messaging source. The reliable messaging source transmits the message to the reliable messaging destination, which acknowledges receipt of the message. The reliable messaging destination then delivers the message to the application destination, and so it reaches the Application Destination.

Reliable messaging takes place between two endpoints known as the reliable messaging source and the reliable messaging destination. Before the messages are sent, the reliable source and reliable destination perform a message exchange to establish a Sequence. A Sequence is identified by a unique identifier and comprises a sequence of messages which are numbered starting from one. Sending a group of messages in a Sequence ensures the reliability of all the messages in that Sequence.

The reliable messaging source sends each message one or more times to the reliable messaging destination. The destination sends back acknowledgment for each message it receives to show that the message has been successfully received. If the reliable messaging source does not receive an acknowledgment that a message has been received by the destination, it sends the message again until an acknowledgment is received.

When all messages in a sequence have been successfully received by the destination and acknowledgment received by the source, the source sends a TerminateSequence message to instruct the destination that the message sequence is complete.

If the client is waiting for messages that have not been delivered, it can initiate a WS-MakeConnection request. WS-MakeConnection is a specification that describes how messages can be exchanged between a server and a client using a transport-specific back-channel. The client's MakeConnection request allows the server to respond with any queued messages that have not been received by the client.

IBM Integration Bus does not support using HTTP compression or SSL with WS-RM.

Message order

WS-RM specifies a number of delivery assurances to be supported by the provider. The InOrder assurance asserts that messages are delivered to the application destination by the RM Destination in the order in which they were sent, according to their sequence numbers. For example, if the RM Destination receives messages in the order m1, m3, m2, it first delivers m1, then retains m3 until it receives m2, and then delivers m2 and m3 to the application destination. Messages are not persisted in the event of an integration node restart.

The following diagram shows an example scenario where InOrder is not used, and messages need not be delivered in the order in which they were sent. The second message in the sequence is lost, but the third message is processed even though the second message has not been delivered.
With InOrder set to false, all messages are processed when they are delivered.
In the following scenario the option is selected, and messages must be delivered in the order in which they are sent. The second message in the sequence is lost, and so the third message is not processed until msg2 can be delivered.
With InOrder set to True, message 3 is not processed because message 2 has not yet been delivered.

The InOrder assurance affects only inbound message processing, for example, when the policy set that asks for InOrder delivery is associated with a SOAPInput node or an inbound message flow. When InOrder delivery is enabled for inbound SOAP message processing, the messages are processed by the flow according to their message number as assigned by the RM Source.

The InOrder assurance does not apply to outbound message processing. If InOrder delivery is selected for outbound SOAP message processing, for example, with a SOAPRequest node, messages are not necessarily delivered to the application destination in the same order in which they are sent from the message flow.

For information about scalability when using InOrder with WS-RM, see Tuning SOAP processing for scalability and performance.