AS4 for Dummies - Part III: Reliability

• Part I: Introduction
• Part II: Messaging Overview
• Part III: Reliability
• Part IV: Security
• Part V: Are you ready for AS4?

Reliable Messaging

Reliable messaging is established by exchanging positive (Receipts) and negative (Errors) acknowledgements on the processing of User Messages. For completeness, their descriptions are repeated here:

• The Receipt is a positive acknowledgement. It indicates that the receiving MSH was able to parse the incoming message without an exception. This ensures the Receive operations was successful. It’s an implementation choice whether to send the Receipt before or after the Deliver operation towards the message consumer.

• The Error is a negative acknowledgement. It indicates that the receiving MSH encountered an issue during the parsing of the incoming message. The ebMS 3.0 specifications define a list of standard error codes and their meaning.

AS4 establishes once-and-only-once delivery, if both the sending and the receiving MSH conform to the required AS4 reliability capabilities.

Reception Awareness

The sending MSH must support reception awareness. This feature requires the ability to detect the fact that no corresponding Receipt was received for a specific User Message, within a configurable time interval. In case this happens, the sending MSH must be able to report this issue to the business application (message producer).

As a sending MSH, it is recommended to also support message retry. This means resending the same message (with identical ebMS MessageId) when reception awareness triggers a missing Receipt. This message retry can be configured with a specific retry policy, which includes a retry count and a time interval between retries. In case a User Message is resent, the sending MSH must ensure that the hash values, included in the signature, are identical to the ones within the original User Message.

These requirements ensure that the sending party is aware whether the User Message was received correctly by the receiving party or not.

Duplicate Detection

The receiving MSH must support duplicate detection. If the sending MSH triggers a message retry, then it could be that the message is received multiple times. In order to assure only-once delivery, the receiving MSH must perform duplicate detection, based on the ebMS MessageId.

Duplicate detection preferably leads to the elimination of duplicate messages in the receiving MSH. If this duplicate elimination is not performed by the receiving MSH, it must at least notify the receiving business application (message consumer) of this event.

It’s an implementation choice how this duplicated detection is parameterized. It could be that there’s a configurable time window for duplicate detection or a maximum log size for the history of received MessageId’s.