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

[Mark Potts <mark.potts@talkingblocks.com>]

Thanks for the clarification Doug  - I agree whole heartedly as was evident
in my last mail..

> -----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 wrapped
> inSoapFaultin 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
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>