RE: [Fwd: Re: [business-transaction] fault messagewrappedinSoapFaultin case of]

["Cho, Pyounguk" <pyounguk.cho@iona.com>]

Hi Doug,
    Thanks for correcting me. What I described earlier was based on the discussion with my colleage here who's implemented ebXML messaging layer. I think I got to check with him to see if his implementation is correct for this matter. :-)
    I agree with you that it would not be a good idea to use SOAP Fault for asynch messaging in BTP or in general. But, there seems to be a good use case for synch messaging. For instance, the way UDDI uses SOAP Fault to pass around detailed description about UDDI level errors/exceptions is completely synchronous.

Regards,
Pyounguk

-----Original Message-----
From: Doug Bunting [mailto:db134722@iplanet.com]
Sent: Wednesday, April 24, 2002 5:12 PM
To: mark.potts@talkingblocks.com
Cc: Cho, Pyounguk; 'James Tauber - mValent';
business-transaction@lists.oasis-open.org
Subject: Re: [Fwd: Re: [business-transaction] fault message
wrappedinSoapFaultin case of]


Sorry to be catching up on this thread so late.

Mark Potts wrote:

> ...
>
> >
> > I know ebXML has a similar problem(Doug might correct me if
> > I'm wrong on anything described here) Before it decided to
> > use SOAP Fault to report ebXML errors, it had a separate
> > message for errors just like BTP Fault. The rationale was the
> > following. If there is any error during Soap message
> > processing such as parsing error, it was the assumption that
> > it would be handled by Soap Fault by the receiving Soap
> > processor. But once it passes that point, any error is
> > considered ebXML error and handled using the message
> > introduced above without using Soap Fault. IMO, the idea came
> > out because ebXML mainly depends upon asynchronous messaging
> > even though that's not the only option. Now I think ebXML
> > allows to use Soap Fault to process any errors during
> > processing the message because Soap Fault provides a unified
> > error handling framework.
> > </pyounguk>
>
> <mark>
> Well If that's true  - I am no ebXML guru - I think they had it right and
> originally.
> </mark>

I'm not sure I agree with Pyounguk's description of the SOAP Fault history in
ebXML messaging.  This element originally found its way into the ebXML document
because we had chosen to remind implementers of errors that might come back when
they send an ebXML message.  That is, we needed to tell senders to expect /
allow soap:Fault responses.  Use of this element expanded and contracted over
versions of the specification but the msh:ErrorList element was never removed
nor placed within the soap:Fault element (though the second was proposed at
least once).  The current specification makes very few references to the
soap:Fault element and uses lots of "MAY" when it does.  A case in point (lines
2539 -2551 in the current text):

     B.2.4 SOAP Error conditions and Synchronous Exchanges
     The SOAP 1.1 specification states:

     "In case of a SOAP error while processing the request, the SOAP HTTP server
MUST issue an HTTP
     500 "Internal Server Error" response and include a SOAP message in the
response containing a SOAP
     Fault element indicating the SOAP processing error. "

     However, the scope of the SOAP 1.1 specification is limited to synchronous
mode of message exchange
     over HTTP, whereas the ebXML Message Service Specification specifies both
synchronous and
     asynchronous modes of message exchange over HTTP. Hence, the SOAP 1.1
specification MUST be
     followed for synchronous mode of message exchange, where the SOAP Message
containing a SOAP
     Fault element indicating the SOAP processing error MUST be returned in the
HTTP response with a
     response code of "HTTP 500 Internal Server Error". When asynchronous mode
of message exchange is
     being used, a HTTP response code in the range 2xx MUST be returned when the
message is received
     successfully and any error conditions (including SOAP errors) must be
returned via separate HTTP Post.

I've got an issue or two with how that's phrased because (in part) "SOAP error"
is never explained in either the SOAP or ebXML Messaging documents.

On the other points in this thread, I would not recommend using the soap:Fault
element for BTP error responses and especially not those that may be sent
asynchronously.  Our SOAP binding should leave SOAP to handle SOAP errors and
provider our own mechanism for BTP errors.  This has the obvious benefit of
allowing BTP implementations that understand the btp:FAULT element throughout
the code but implement bindings (including the SOAP binding) at a much lower
level.

SOAP 1.1 isn't entirely clear whether it's providing a fault return mechanism
for its own use or for all application errors.  If it's providing a substrate
for application errors, it doesn't handle asynchrony well and it's not clear
whether use of the soap:Fault element is required for all application errors.

I prefer to ignore the OSI 7 layer boundaries and focus on an application / BTP
/ SOAP / HTTP / TCP / IP layering whether or not that matches any architectural
model.  The issue is that each layer has success and failure cases which should
be handled within themselves.  BTP isn't providing a generic mechanism for
returning application errors and SOAP doesn't provide a suitable container for
BTP errors.  Note: The btp:FAULT element is explicitly a message and suitable
for asynchronous notification of errors.

thanx,
    doug