RE: [ws-caf] Fault message formats

["Murray, Bryan P." <bryan.murray@hp.com>]

Responses below in <bpm/>.

Bryan

-----Original Message-----
From: Jim Webber [mailto:Jim.Webber@newcastle.ac.uk] 
Sent: Wednesday, May 12, 2004 6:58 PM
To: ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] Fault message formats


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.

<bpm>While it is certainly possible for applications to treat faults in
any way they wish, the SOAP specs define the Fault element to include
several standard fault fields and an extensibility model. If the Fault
element were only for the use of SOAP, I doubt that the authors would
have gone to so much trouble. Furthermore the SOAP binding in WSDL 1.1
defines that the SOAP fault element is used to transmit the faults
described in the binding. However, neither the SOAP specs nor WSDL
requires that applications use this mechanism.</bpm>


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.

<bpm>You have a good point that a message that reports on the state of
an entity is different from a message that indicates that a previous
message was not understood or valid. However, WS-Context defines some
messages that are sent to indicate that a previously received message
could not be properly processed. For instance,
validContextExpectedFault, unknownContextFault, and even generalFault
seems to be used for this purpose in many cases. These messages are not
just reporting that an entity has found itself in a particular state,
but to inform the sender of a previously received message that something
was missing from the message, or something specified by the message
could not be found. These seem like real faults to me, and as such, I
would relay these messages using the SOAP fault element.</bpm>


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

<bpm>Could you explain the failure recovery characteristics you are
trying to achieve - I don't remember reading about them in the spec?
Also, just because you describe something as request-response does not
mean it can't be implemented asynchronously. I think if something really
is request-response it helps the reader to understand the relationship
between the messages to actually document it as request-response. The
problem with describing the message pairs as asynchronous in WSDL
portTypes is that you loose the relationship between the messages. You
either need an orchestration language to describe the relationships or
you use the text of a specification as WS-Context has done to describe
these relationships. The unfortunate aspect of using the text of a spec
is that it is human readable, but not machine readable. What about
defining request-response operations and using something like
WS-MessageDelivery to define an asynchronous binding?</bpm>


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

<bpm>Lets not discuss the merits for now. I should not have mentioned
WS-BaseFaults unless there was some agreement about the use of SOAP
Faults.</bpm>

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