[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] Fault message formats
+1 ----- Original Message ----- From: "Dale Moberg" <dmoberg@cyclonecommerce.com> To: "Mark Little" <mark.little@arjuna.com>; "Murray, Bryan P." <bryan.murray@hp.com>; <ws-caf@lists.oasis-open.org> Sent: Thursday, May 13, 2004 4:44 PM Subject: RE: [ws-caf] Fault message formats > My perhaps simplistic view of WS faults is that SOAP faults are mainly > those defined in the XMLP WG and are emitted by the SOAP processor > during the processing of SOAP header blocks. Then WSDL has in its > operations, a provision for defining a message, in addition to input and > output, called fault. That is a service specific fault that is defined > as part of the "interface" of the web service, much like in a > programming language you would have formal parameters with data types as > a signature and for return values, and then also have an exception type > declared. > > I am not aware of a push to use SOAP faults where WSDL fault definitions > ordinarily would be used. Moreover, that seems to me to be an > unmotivated revision of the current convention. I would not favor this > group being a trend setter encouraging the collapse of WS interface > faults into SOAP processor faults... > > > > > -----Original Message----- > From: Mark Little [mailto:mark.little@arjuna.com] > Sent: Thursday, May 13, 2004 1:58 AM > To: Murray, Bryan P.; ws-caf@lists.oasis-open.org > Subject: Re: [ws-caf] Fault message formats > > > Bryan, as Jim mentioned, when the CAF specifications were first being > written we took the approach that SOAP faults would be used to convey > information about errors/faults that occurred from the comms. protocol > aspect, whereas application/specification specific faults would be > explicitly called out as messages in the specs. That was in line with > the way in which other specifications seemed to approach things too. > > Are you saying that the approach of using SOAP faults to convey higher > level specification/implementation faults is the way things are moving > in the industry? If so, then you're right and we should re-examine this. > > However, as to tying to WS-BaseFaults, I think that's a really bad idea > at this stage. For a start I have no idea where things coming from the > WS-RF TC will fit into a WS architecture - do you think that it's going > to be the case that all SOAP server vendors will really have to > implement some or all of WS-RF? If we go with SOAP faults then we're in > a pretty good place, since we can guarantee that all vendors will > implement that. Then there's the fact that WS-RF is just starting and > who knows that's going to happen in the next 12 months. > > Let's tackle one thing at a time. I would be against any tie to WS-RF at > this stage, but as the work of that TC evolves and becomes clearer we > can always revisit the situation. There are several things that we have > deferred until a 1.x release, for example, and perhaps this is another > one of them. > > Mark. > > ---- > Mark Little, > Chief Architect, Transactions, > Arjuna Technologies Ltd. > > www.arjuna.com > > ----- Original Message ----- > From: "Murray, Bryan P." <bryan.murray@hp.com> > To: <ws-caf@lists.oasis-open.org> > Sent: Thursday, May 13, 2004 2:36 AM > Subject: [ws-caf] Fault message formats > > > > Both the 1.1 and 1.2 versions of the SOAP specification indicate that > > "A SOAP fault is used to carry error information within a SOAP > > message." (from SOAP 1.2). Tools and SOAP stacks are able to make use > > this statement by having a specific place to look for or generate > > error information. The tools and stack may be optimized for processing > > > faults because this is how error information is communicated. > > > > I suggest that it might be better if WS-Context sent error messages > > using the SOAP Fault element rather than defining a new element for > > transmitting fault information. Since SOAP messages are defined only > > as something sent from a sender to a receiver, it should not matter > > that the message gets sent in the HTTP request (for a binding to SOAP > > over HTTP). > > > > Something that is less clear is how best to describe this use of fault > > > messages in WSDL. For an input-output binding it is clear that the > > wsdl:fault element would be used. With the binding proposed for > > WS-Context (is this binding normative?), it is necessary to describe > > that the client will be receiving the fault message rather than that > > the service will be sending the fault message. WSDL 1.1 is not clear > > about any message flow direction implied by the use of the wsdl:fault > > element, but I think most people understand the fault to be sent from > > the entity described by the WSDL. WS-I does not clarify this any > > further. > > > > I think it would be best not to use the wsdl:fault element to describe > > > the receipt of a fault message. Instead, the SOAP Fault message should > > > be extended for the specific WS-CAF faults and specified on the fault > > receiver using wsdl:input. I believe most SOAP stacks will still > > recognize the fault correctly and be able to optimize its processing > > as done for other faults. > > > > Another option is to consider that many of the messages exchanged in > > WS-Context are simply request-response message pairs. It is possible > > for WS-Context to map those message exchanges that do represent > > request-response pairs to operations having both an input and an > > output message defined. For these operations, the wsdl:fault element > > should be used to describe the faults. We would need to examine the > > remaining messages that require an asynchronous mapping to see which > > fault messages are defined for these cases and then decide how best to > > > describe these fault messages. > > > > I think it is important that SOAP Fault messages be used to > > communicate fault information. I further suggest that it would be > > prudent to define WS-Context faults such that they are compliant with > > WS-BaseFaults. > > > > Comments? > > > > Bryan > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]