RE: [ws-caf] Fault message formats

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

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