[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] AS4 receipts, retries and recoverable/unrecoverable errors
|
I have reviewed WSS, ebMS-core, AS4 etc on these issues and here are some observations and proposals to consider, ignore, or reject. The example 5.3.3 is described as illustrating (and examples were non-normative) the ebMS error message in the soap:header section. The soap:body is empty, so a soap:fault is not illustrated. 6.6 and elsewhere we say that when sending certain kinds of “failure” errors using the ebMS error
header, the soap:fault must be present. (and the 5.3.3 illustration does involve a “failure”).
Now wss faults, like most soap faults actually) may not actually be sent, but only “generated.” WSS says whether to send its faults is a matter of policy, and
it seems that the soap perspective is really that sending faults is a policy choice (probably as set out by ws-policy but that is another matter).
Because we always maintained that we wanted to leverage the WS-* technology stack wherever possible in ebMS core, the somewhat policy-level option on generating,
but not sending faults really should IMO be one we leave open. So to my mind, if we want to have an errata about this, I would much prefer making the MUST of 6.6 into a SHOULD. Three reasons: First because if we use the ebMS error at failure level, the cases are mainly broad uses of mustUnderstand faults (ebMS header requires that mustUnderstand
be true) and stretches the meaning of this fault to encompass, not only not having a handler registered for the header, but having a handler that runs into problems! Second because if we have the ebMS fault, the soap fault could be viewed as redundant. And
finally because we intended not to “step on” any provision of ws-* conventions (such as generating faults but not sending).
I can also see just leaving the MUST alone, and trusting that people can understand that this MUST is one that is setting policy, and the the desired policy
of protocol users might be something that conflicts with our MUST. As a side note, because “wrapping” something in a soap:fault is really a wsdl kind of idiom, it is probably a little misleading to use it here. A wrapping in
this sense puts the “exceptional situation” in the soap:body but ebMS errors go in the soap:header. I think we deliberately did not want to follow the wsdl wrapping conventions. A little long, but still just $.02 worth. Dale From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org]
On Behalf Of Pim van der Eijk 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:rxing@tibco.com]
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 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?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]