FW: [ebxml-msg] AS4 receipts, retries and recoverable/unrecoverable erro

Pim,

So per my understanding of your inputs, the recoverable errors can normally be considered as those occur on transport layers, including transport security like SSL.

I have another question which might be side-tracking: you mentioned that a "failure" ebMS error would be wrapped in a SOAP fault according to section ebMS3 Core 6.6. However in 5.3.3 the example doesn't indicate such a wrapping.

Also I'm wondering why this is suggested by the spec. Errors could also be returned back asynchronously, such as in the case of a Pulled Message, the errors occur on the message consuming side have to be sent back in such a way. In this case it has to be sent back as a "pure" ebMS3 error message. So here for the same type of error it can be sent back in packages of different format, which increases the implementation complexities.

I remember in ebMS2 it was designed in a simpler way: whatever error occurs on SOAP layer is sent back as SOAP fault, whatever on ebMS layer would be sent back as ebXML errors.

Thanks,

Rong

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: Friday, January 18, 2013 5:22 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] 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?

ebxml-msg message