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

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

> Doing this might be considered a layer violation if one
> considered SOAP
> to be a transport rather than application protocol. For example, one
> wouldn't expect an error code at the TCP/IP layers just
> because there was
> an error at the application layer.

I think this a layer violation, SOAP Fault is meant to be faults at that
layer - i.e. the envelope layer. We have already gone round on this with
others about "web architecture friendly" bindings.

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

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>

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


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