The message from Rong below did not make it to the
mailing list, forwarding this for convenience.
I actually agree that it would be simpler if ebMS
errors could indeed be handled at the ebMS level only.
Since 5.3.3 and 6.6 seem to contradict, we could add
this to the errata for ebMS3 Core.
Pim
From: Rong Xing [mailto:]
Sent: 19 January 2013 00:26
To: Pim van der Eijk;
Subject: RE: [ebxml-msg] AS4 receipts,
retries and recoverable/unrecoverable errors
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:
[mailto:] On
Behalf Of Pim van der Eijk
Sent: Friday, January 18, 2013 5:22
AM
To:
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?
