OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



Comment as me, not as chair,

I have to agree with James' point.  I would like to keep BTP faults for
BTP errors and SOAP faults for SOAP errors, and by extension HTTP faults
for HTTP errors but that doesn't really enter into this discussion.

=bill

-----Original Message-----
From: James Tauber - mValent [mailto:jtauber@mvalent.com]
Sent: Friday, April 12, 2002 5:08 AM
To: business-transaction@lists.oasis-open.org
Subject: [Fwd: Re: [business-transaction] fault message wrapped in
SoapFault in case of]


[previously sent from unauthorized address...]

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.

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.

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.

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>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC