Delivery Assurance is the ability of a message sender to be assured that a message will be delivered. This delivery guarantee protects the sender from network or system failures that may occur along the way. Based on factors ranging from the type of endpoint to the type of data, various levels of protection may be needed. Thus, it is important to be able to “customize” the reliability effort required into well-understood Delivery Assurance Profiles.

STAR recommends support of four levels of Delivery Assurance:

“Best-Effort” is the absence of any reliability features. A sender sends a message and assumes that the intended party received it.

“At-Least-Once” requires the sending party to uniquely identify a message and the receiving party to acknowledge the receipt of the message, giving the sender an auditable record stating that the message has been received. If the sender does not receive an acknowledgment of receipt in a reasonable amount of time (Time-Out), it MUST retry the message send. The sender and receiver should agree upon a reasonable Number-of-Retries and a reasonable RetryInterval to avoid unnecessary network traffic.

“At-Most-Once” requires a sending party to uniquely identify messages, to retry failed messages and requires the receiving party to identify and ignore any duplicate messages. In order to know which messages to ignore, it is strongly recommend that the receiving party persist received messages in a durable store. Note that the receiver is not required to acknowledge receipt of a message.

“Once-And-Only-Once / Exactly-Once requires the sender to uniquely identify each message and to retry any message that the receiver fails to acknowledge. The receiver must acknowledge receipt of messages and ignore duplicate messages. It is strongly recommended that the receiver persist messages in a durable store to enable duplicate elimination.

Message Routing

Message Routing refers to the ability of an Endpoint to figure out where to send a message. Routing can be specified per message and/or by leveraging some sort of Partner Management system.

It is necessary that business partners agree on which data elements in a message determine routing and the type of data, for example a URI. These agreements enable predictability between partners:

Retry and Acknowledgment are key mechanics for Reliable Messaging and require the parties to agree on the data elements that describe Routing.

STAR recommends that ebMS version 2.0 Routing features be used in conjunction with ebXML CPPA, or STAR recommends the use of WS-Addressing.

Acknowledgment of Receipt

A Message receiver must implement Acknowledgment of Receipt to enable:

Acknowledgment of Receipt means that an endpoint has received a message, and the endpoint believes the message can be processed. In other words, the message appears to be valid for an agreed upon format, appears to be received as sent, has not failed any initial security checks and the endpoint will attempt to take action that results in the processing of the business request represented by the message.

Acknowledgment of Receipt is not a business level acknowledgment such as AcknowledgmentOfPartsOrder.

STAR recommends that WS-ReliableMessaging Acknowledgment messages are used, or STAR recommends that ebMS version 2.0 Acknowledgment messages be used.

Partner Policy Agreements

To enable Reliable Messaging, business partners must agree on how to share the Policy details that govern the level of reliability. This Policy information might be set per message using data elements in the message, or may be shared out-of-band using persistent Policy Agreement records. To enable the automation of these agreements, STAR Recommends ebXML CPPA for ebMS. STAR has identified the WS-Policy framework of standards as the long-term solution for STAR Web Services Guideline. The WS-Policy recommendation will be expanded in future STAR Transport Guidelines documents.

Policy Agreements related to Reliable Messaging should include the ability to specify:

Message Integrity

STAR recommends three characteristics of Message Integrity:

Content Integrity is the ability of the receiver to ensure that a message has been received byte-for-byte exactly as sent. The typical solution for ensuring Content Integrity is for the sender to digitally sign the original message, providing a hash or content-digest of the message that the receiver can use to verify the message is a an exact representation of the intended message and has not been altered in transit.

Message Sequencing is the ability to label multiple messages as being part of a coherent ordered set of messages. In other words, message 3 follows message 2, which follows message 1.

TimeToLive is a timestamp associated with a message that defines its useful processing life. If the receiver receives a message who’s TimeToLive has expired, the message should be ignored.

STAR recommendations on Reliable Messaging are focused on point-to-point systems. From a technical perspective, STAR does not describe Multi-Hop features for Web Services or ebXML. STAR may address this in the future.

STAR workgroups have engaged in many discussions on how parties can identify themselves and what implications this has for intermediaries. There is a desire to support a model where a Dealer can identify itself to an Intermediary, and that Identification will be passed on to the end receiver, an OEM.

STAR currently allows for Authorization and Authentication based on Digital Certificates or Username / Password.

From a technical perspective STAR ebMS does not address any differences for an intermediary, the assumption is that Authorization and Authentication will be based on Digital Certificates and will be:

or

STAR Web Services do describe a model for the presence of Intermediaries where security information, including security tokens used for Authentication and Authorization can be targeted at an Intermediary. This capability is based on the ability of WS-Security 2004 constructs to leverage the SOAP Actor data fields. If security information is targeted at the “Next Actor”, an Intermediary may use this security information to Authenticate and or Authorize the message originator, and then the Intermediary is required to remove this specific security information from the message before forwarding.

In order to support interoperability and message handshaking, standardized error handing and monitoring should be used. STAR recommends the following error conditions be addressed:  

Resend

A Message sender must implement resend of messages to enable At-Least-Once, At-Most-Once or Once-And Only-Once / Exactly-Once profiles. Messages that are retransmitted should repeat the original message's MessageID (allowing the receiver to determine whether a duplicate has been received or not).

MaxNumberRetries

Parties must be able to agree to a maximum number of times a message can be retransmitted and should establish a Policy for what happens if the maximum number of retries is exceeded and a message still has not been delivered.

Timeout

Parties must be able to agree on a Time-Out value. This is how long a sender waits for Acknowledgment of Receipt before retransmitting a message.

STAR strongly recommends that sent and received messages are placed in a durable store, enabling correct processing, including the identification of duplicate messages, in the case of system failure.

Parties that choose to implement At-Most-Once or Once-And-Only-Once / Exactly-Once profiles must support the ability to identify and ignore messages with duplicate message IDs.