Standards for Technology in Automotive Retail

 Home -  News Feed 

9.2. Reliable Messaging Construct

Reliable Messaging is based on a conversation between a client and server. There are many different ways this convesation can take place and all Reliable Messaging frameworks that are being used for STAR implementations should support all of these profiles.

[Note]Reliable Messaging 1.0 Difference

In Reliable Messaging 1.0 these profiles were built into the protocol. In Reliable Messaging 1.1, these are not sent across the wire, but are configured using policy profiles. It is the responsibility of the framework to guarantee the correct reliablity is being used.


Delivery Assurance


The messages in the sequence will be delivered to the application without duplication. If a message was to be accidentally delivered more than one time, this ensures that all additional instances of the message are thrown away. It is possible that messages may not be delivered


The messages in the sequence are assured to be delivered to the application at least once. If a message is delivered more than once, it is not thrown away and is accepted. This could result in a duplicate message. If a message cannot be delivered an error message would be raised.


The messages in the sequence are assured to be delivered exactly once. This assertion is equivalent to AtMostOnce and AtLeastOnce. In this case the message is guaranteed to be delivered or an error is raised and any messages that arrive more than one time are thrown away.


The messages in the sequence are assured to be delivered to the application in the order they were sent. This is important when multiple messages make up a sequence and the order in which they arrive and or are processed is critical. When this assertion is set, this will ensure that the receiving application will be delivered the messages in the correct order. All messages that are sent within a sequence have a message number, to keep track of the ordering.

9.2.1. Message Sequencing

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

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.

Example 9.1. Reliable Messaging Create Sequence


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.

Example 9.2. Reliable Messaging Header Acknowledgements

    <wsrm:acknowledgementrange lower="1" upper="1" />
    <wsrm:acknowledgementrange lower="3" upper="3" />    

Each of the above acknowledgement refers to a Sequence Message number that was sent during a conversation.

Example 9.3. Reliable Messaging Header Message Sequence Number


The message numbers are usually incremented by one for each of the messages sent. Once the client wants to terminate the conversation with the server, and has sent all of it's sequences, it will send a TerminateSequence message. Once a conversation has been terminated, no more acknowdlegments can occur for that converstation.

9.2.2. WS-MakeConnection and Non-Addressable End Points

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.

9.2.3. WS-ReliableMessaging Standardized Error Handling and Monitoring

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.

[Important]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.


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.

[Important]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.


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.