WS-Reliable Messaging

The message flows are imported without WS-Reliable Messaging being enabled. Anyone can call the Web service to consume the messages, similar to the TCP/IP Monitor with SOAP over HTTP. To enable WS-Reliable Messaging, see Extending the Address Book sample.

Enabling WS-RM is an administrative task that is performed at the WebSphere Message Broker level. You cannot configure WS-RM when developing message flows; you must configure the policy in the broker and associate it with the message flows in a broker archive (BAR) file.

Why use WS-Reliable Messaging

In the Address Book extension sample, both the consumer and the provider have the same reliable messaging requirements:

  1. Ensure the delivery of a SOAP message when a server is unexpectedly restarted.
  2. Ensure the delivery of a SOAP message when the connection between the client and server fails, for example, due to a timeout. The client should be able to detect the condition and retry the message transmission.

The WS-RM protocol fulfills these requirements by defining how to send messages again that it determines have not been delivered successfully, and by preventing duplicate messages from being delivered to the destination application.

How WS-Reliable Messaging works

The key to WS-RM is the concept of a sequence. A sequence in WS-RM is a contract between a Web services client and a Web services provider, through which they agree to reliably transmit messages between them. The sequence is used to maintain the state of messages that have been sent and received. The sequence itself is specific to a provider's endpoint. When a client sends a message to a Web service provider's endpoint for the first time, a sequence to that provider's endpoint is created, and all subsequent messages from that client to that provider's endpoint are delivered on that sequence. The sequence allows client-side and provider-side WS-RM to decide whether application messages need to be delivered again, and to detect whether arriving messages are duplicates.

To define sequences and maintain current state, both client and provider WS-RM uses a collection of defined protocol messages that are sent back and forth. The following diagram shows a typical message flow for a request-reply Web service invocation using WS-RM.

A typical WS-RM message exchange sequence, which is described in the steps below.

The sample scenario

Here are the steps which describe how sample works when WS-RM enabled:

  1. The protocol preconditions are established. These include policy exchange, endpoint resolution, and establishing trust.
  2. The consumer requests creation of a new Sequence.
  3. The provider creates a new Sequence and returns its unique Identifier.
  4. The consumer begins transmitting messages in the Sequence beginning with MessageNumber 1. Each request sent by the SOAPRequest node will create a new sequence, so all messages will have MessageNumber 1.
  5. The consumer also includes an AckRequested header to ensure that it gets a timely SequenceAcknowledgement for the Sequence.
  6. The provider acknowledges receipt of message numbers 1 as a result of receiving the consumer's AckRequested header. If any message in between is lost for any reason, then no acknowledgment will be sent to consumer
  7. The consumer retransmits the unacknowledged message with same MessageNumber. This is a new message from the perspective of the underlying transport, but it has the same Sequence Identifier and MessageNumber so the provider can recognize it as a duplicate of the earlier message in case the original and retransmitted messages are both Received. The consumer includes an AckRequested header in the retransmitted message so the provider will expedite an acknowledgment.
  8. The provider receives the second transmission of the message with MessageNumber 1 and acknowledges receipt of message numbers 1.
  9. The consumer receives this acknowledgment and sends a TerminateSequence message to the provider indicating that the Sequence is completed. The TerminateSequence message indicates that message number 1 was the last message in the Sequence.
  10. The provider receives the TerminateSequence message indicating that the consumer will not send any more messages. The provider sends a TerminateSequenceResponse message to the consumer and reclaims any resources associated with the Sequence.

The details for whether messages should be delivered in order or not, are contained within the WS-RM policy set. Use the previous diagram for reference.

Back to Extending the Address Book sample

Back to sample home