Fault message formats

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

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