Reliable Messaging is based on a Sequence of events. The various profiles of Reliable Messaging listed below will help determine what the sequence will look like. Sometimes just the client will send a sequence, and other times both client and server may send independent sequence numbers. It is up to the framework implementing Reliable Messaging to keep track of the sequences and acknowledgements where necessary. A general conversation is depicted in Figure 9.1, “Reliable Messaging Conversation Sequence”.

Figure 9.1. Reliable Messaging Conversation Sequence

Trading partners may use WS-Policy to estabilish the Assurance Profiles for the Reliable Messaging conversation. In regards to how the messages may look when transmitted, Paul Freemantle's article provides several useful examples.

<soap:body>
  <wsrm:createsequence>
    <wsrm:acksto>
      <wsa:address>http://Business456.com/serviceA/789</wsa:address>
    </wsrm:acksto>   
  </wsrm:createsequence>
</soap:body>

A Reliable Messaging conversation will always start with a CreateSequence and may be terminated with a TerminateSequence message. If a TerminateSequence is not sent, a framework may use a predefined timeout to automatically terminate the sequence. In between there can be zero-or-many acknowledgements that appear in the soap:header. These acknowledgements are in response to the message sequences that have been received.

<soap:header>
  <wsrm:sequenceacknowledgement>
    <wsrm:identifier>http://Business456.com/RM/ABC</wsrm:identifier>
    <wsrm:acknowledgementrange lower="1" upper="1" />
    <wsrm:acknowledgementrange lower="3" upper="3" />    
  </wsrm:sequenceacknowledgement>
</soap:header>

<soap:header>
  <wsrm:sequence>
    <wsrm:identifier>http://Business456.com/RM/ABC</wsrm:identifier>
    <wsrm:messagenumber>1</wsrm:messagenumber>
  </wsrm:sequence>
</soap:header> 

Reliable Messaging 1.1 has the ability to establish a reliable delivery system with a server that may not be addressable all the time. During a conversation, a server may set an alternative method to retrieve the rest of the messages. If the conversation is broken, or lost in the middle, the client may try to re-establish the conversation using the MakeConnection protocol. The client will "poll" periodically, to try and establish a connection at the Address specified by the makeconnection element. Once connection is estabilished it will send the request for the message that it needs to receive, and the server will respond back with the message and an indicator if there are any more messages waiting to be sent. [WS-MC2007]

This allows for a server to be off line and for the conversation to be re-established. Some dealerships are still using dial up connections and limited broadband connections that may not always be connected. WS-MakeConnection is the recommended way to continue this conversation and deliver the messages.

MakeConnection may also be used in those situations where a long running process may occur. For example, a client sends a ProcessPartsOrder BOD to a server. Depending on the size and complexity of the PartsOrder BOD it may take a while to process. The server will drop the connection, and the client can try to establish a connection through MakeConnection. If the a response is waiting for the client, it will be sent, otherwise, the server will drop the connection. Eventually the process finishes and the next time the client connects, the message is sent. There may be multiple responses waiting for the client, if so, the server will let the client know about the other messages waiting to be delivered. MakeConnection enables a reliable way of working asynchronously.

WS-ReliableMessage defines general error handling at the SOAP level via SOAP Faults. In the context of STAR Reliable Messaging, WS-ReliableMessaging provides support for Retry (Retransmission), Recovery, TimeOut and Duplicate Detection.

	STAR Level 2 Requirement
	STAR 2010: Error handling is REQUIRED to follow the recommendations of the WS-I Reliable and Secure Profile in regards to handling of errors.

Retry

WS-ReliableMessaging supports retransmission of unacknowledged messages. As described above, At-Least-Once and Once-Ane-Only-Once / Exactly-Once require the ability to resend messages. WS-ReliableMessaging allows for sending implementations to retransmit messages if an acknowledgement is not received within an agreed upon RetransmissionInterval. The retransmitted message is intended to be exactly the same as the original message and at the very least it must have the exact same Sequence Identifier and MesageNumber.

	STAR Level 2 Requirement
	STAR 2004: If a message was not able to be sent it MUST be retried at least three times.

Recovery Processes / Message Store

WS-ReliableMessaging does not directly require persistence of messages or specify recovery procedures. STAR requires messages to be persisted to non-volatile storage to be able to function through component, system or network failures and to be able to support duplicate elimination, lookup of messages by Sequence Identifier and Message ID and the ability to retransmit messages.

Time-Out

WS-ReliableMessaging supports the Time-Out feature through a senders ability to specify a Inactivity Time-out and/or BaseRetransmissionInterval policy. The receivers also can specify an AcknolwedgmentInterval through the use of Policy on return messages or through shared policies.

Duplicate Detection

WS-ReliableMessaging specifies that to support At-Most-Once and Exactly-Once Delivery Assurance Profiles, receivers MUST enable message receipt without duplication. Implementation details are not given, but at the very least, a receiver MUST prevent duplicates where Sequence Identifier and MessageNumber are repeated.