[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Fwd: Re: [business-transaction] fault message wrappedinSoapFaultin case of]
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> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC