AS4 receipts, retries and recoverable/unrecoverable errors

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Some questions came up when I discussed AS4 reception awareness with a developer who is working on implementing message retries in an AS4 product.  

 

AS4 defines Message Retry as Ability for a User message sender that has not received an expected eb:Receipt to resend the User message.

 

When sending messages, an MSH may encounter a variety of error conditions:  DNS lookups failing,  HTTP/SSL connections not established, HTTP errors,  SOAP faults,  ebMS errors.    Some of these errors are recoverable,  and the retry mechanism is there to hopefully be more lucky at a later point in time.   However,  in some cases the error condition may be such that the error can be considered permanent and that it does not make sense to retry as there is no way that the MSH could recover from the error. An implementation that follows the AS4 specification and retries while a Receipt has not been received would make useless retries if instead of a receipt an error is received.  It would be better if instead the sending MSH would stop resending and report the error to the Producer. Unrecoverable errors are like negative receipts, so they should control retries just like receipts.  

 

The question is which situations could be considered recoverable (temporary) and which ones unrecoverable (permanent).   Retries for permanent errors cause unnecessary message traffic and load and prevent the Producer from being informed in time about problems.

 

1) ebMS errors of severity failure. 

 

In ebMS3 Core section 6.2.5 it is stated that failure value indicates that the processing of a message did not proceed as expected, and cannot be considered successful. If, in spite of this, the message payload is in a state of being delivered, the default behavior is not to deliver it, unless an agreement states otherwise (see OpCtx-ErrorHandling).   This error would be wrapped in a SOAP fault according to section ebMS3 Core 6.6.  This situation seems to be a permanent issue.  

 

2)  ebMS errors of severity warning

 

It looks like user messages that lead to warnings (there are only two defined in ebMS3 Core) can be delivered, unlike the failure errors, but warnings seem permanent like failures and like receipts.

 

3)  SOAP faults from the WS-Security module. 

 

These also seem to be unrecoverable.  There is no point in resending messages with bad signatures or that cannot be encryped.  

 

4)  HTTP errors:  these may come from overloaded Web servers,  proxy servers, other networking components.    Whether they are recoverable or not (and therefore if retries make sense or not) could be argued to depend on the exact error code.     From ebMS 2.0 projects I know implementations would interpret this differently, or allowed customers to configure this (e.g. retry on HTTP 503, fail on HTTP 500).  The more robust default option would be to assume they are recoverable.

 

5)  SSL,  DNS, TCP:   recoverable.

 

What do you think?