[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