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

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

> <pyounguk>
> If my understanding is correct, SOAP Fault is a mechanism 
> provided for the application using SOAP messaging to wrap 
> nicely application errors as well as SOAP level errors. 
> Without it, there is no way to describe application errors 
> other than exactly what we're doing in BTP. For instance, 
> UDDI does not have a separate UDDI message like Fault or 
> Error but uses SOAP Fault to pass around the error info, 
> which I think is elegant. 

<mark>
Hmmm... dont know if I agree  - Faults are meant to be for their layer.  You
are right however, the problem is the mapping between WSDL and SOAP in terms
of application faults, and the problems of marrying the two up. I have seen
many people use document style binding where the return document contains
the return semantics as well as an optional Error semantic. The requestor
must then check the document for the Error segment before processing the
return. I think this is a good way to get round the problem of the mapping.
At least this way there is a way of specifying the explicit error conditions
(known) for a service in the WSDL through Schema - although many simply use
generic exception!
</mark>

> 
> 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>

> >
> > Confusion in this area has mostly arisen because in the 
> worldview that
> > takes HTTP to be an application protocol, an argument can 
> be made for
> > using HTTP error code 500 for faults higher up.
> 
> IMO, and others, Http is a transfer protocol not an 
> application protocol or
> a transport protocol. Because it has a abstracted semantic 
> meaning and a
> message set POST, GET etc... doesn't make it an application 
> protocol to me,
> it denotes a way and meaning for the type of transfer being 
> completed. Http
> error code 500 denotes a specific problem with the transfer 
> of information
> on any transport protocol, but not the application protocol layer.
> 
> Of course many uses of SOAP are a violation themselves, in 
> some peoples
> eyes, because it "tunnels" everything through Http POST. I 
> can forgive  the
> abstraction of the semantic for upper layers ( mainly because 
> the whole
> industry does too) but not the direct use, leverage/bastardisation of
> semantic meaning for higher levels - i.e. keep faults for the 
> layers within
> the layers.
> 
> <pyounguk>
> Http is quite different. It does not provide any way to pass 
> application errors back to the requester. And that's why 
> different applications with http for transport use different 
> ways to do so. The most popular one is to send error messages 
> that will be checked only when the http response code is 
> greater than 300. No standard way on this.
> </pyounguk>
> 
> >
> > However, if one wants a clean separation of layers, then it seems
> > incorrect to indicate a fault in a lower layer when that
> > layer succeeded
> > in its communication and the fault occurred only at a higher
> > (or in the
> > case in point, highest) layer.
> 
> Agreed, BTP Faults are faults at the btp protocol later they are not
> transfer errors or encoding/enveloping errors and should not 
> be mixed. For
> example when checking a Stock a GetStockQuote services that 
> returns unknown
> symbol has completed correctly at the transport level, the 
> transfer level,
> the encoding level  - its an application error and should be 
> represented as
> an application error not an error at any other level.
> 
> <pyounguk>
> I agree that the transport level errors should not be mixed 
> with application errors. My point is that SOAP Fault is 
> defined to cover both transport level and application errors. 
> In the example above, Soap Fault can be used not only for 
> "Server not found" or "Invalid elements found in request SOAP 
> message" cases but also for "No such stock symbol found" or 
> "The requested service not available any more" cases. For the 
> latter cases, it is also possible to put anything to describe 
> futher information about the application error. And, the 
> client application can handle both of them in a more uniform 
> manner. I believe that's the recommended way of using SOAP in 
> JAX* API's.
> </pyounguk>
> 

<mark>
Hmmm so this is religious somewhat, but there is the same debate going on
over at the W3C Arch group right now about http error codes and what they
mean in SOAP land. Server not found is an example of the transfer layers
problem  - its not application or enveloping - its an known error because of
a transfer protocol built upon a unreliable transport layer. So on that I
disagree. Who's responsible for unknown/invalid element and symbol not found
are separate in my opinion! One application specific  - the application has
to handle a error condition that's possible and should therefore be
forwarded that error, that's not the case for the unknown element  - that's
a marshalling exception at the soap layer.
</mark>

> 
> >
> > James
> >
> >
> > > Hello BTPers,
> > >    Currently the BTP draft spec says that BTP Fault message
> > is treated
> > >    as others meaning that it is sent as a normal soap
> > message in case
> > >    of SOAP binding. I think we can take advantage of Soap Fault
> > >    mechanism for BTP Fault messages. For instance, UDDI defined a
> > >    message called disposionReport, which allows UDDI
> > registry servers
> > >    to compose a UDDI message describing error
> > code/message/... in the
> > >    event of UDDI error. This dispositionReport is sent as
> > part of Soap
> > >    Fault message under "detail" element.
> > >
> > >    One good thing of this approach is that the client
> > application can
> > >    check whether it's a fault or not using standard Soap
> > handling api's
> > >    such as JAXM, and can retrive the information easily. Since we
> > >    already have a message format for BTP Fault message defined, we
> > >    could make it possible to pass BTP Fault inside Soap
> > Fault message
> > >    in case of SOAP binding.
> > >
> > >    I do not think it's a big issue. Just want to see what
> > others think.
> > >
> > > Regards,
> > > Pyounguk
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
>

<<attachment: winmail.dat>>