RE: [ws-caf] Fault message formats

["Jim Webber" <Jim.Webber@newcastle.ac.uk>]

Hey Bryan,

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

You raise an interesting point here. When the original CAF documents
were written, there was a lot of debate around this area and I don't
think there were any clear cut answers. 

One philosophy is that the SOAP fault mechanism should be there to
convey things that have gone wrong at the SOAP level (e.g. the service
you sent the message to doesn't exist). The other school of thought is
that all fault information should be propagated via SOAP faults.

I think the clincher for me was that a "fault" in the WS-CAF sense does
not necessarily imply a "fault" in the application per se - it is just a
report on a condition that a particular software agent can get itself
into and is as such a valid application state not really a fault.

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

This is not an unreasonable suggestion. I think it comes down to
personal preference, and my personal preference would be to define
protocol error messages within the protocol itself, and use SOAP faults
to propagate things that have gone wrong with SOAP message transfers.

[snip]

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

That depends. You are free to define your own mapping of course (the
WSDL isn't normative), but the asynchronous nature of WS-CAF was
deliberate to allow for better failure recovery characteristics.
Personally I'd keep it async and tie requests and responses together
somewhere else (like in your implementation).

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

To the first point I'd say it's personal preference - put it to the vote
and see who likes what. However coupling this spec in progress to
another spec in progress - especially one with such dubious merit as
WS-BaseFaults - is something I would strongly oppose (insofar as
non-voting members can :-) ).

Jim
--
http://jim.webber.name