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

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

James.

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


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