AS4 receipts, retries and recoverable/unrecoverable errors

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?