Re: [ws-caf] Fault message formats

[Simeon Greene <simeon.m.greene@oracle.com>]

Bryan et al,
Kinda late to chime in but here's my $.02.
IMO, the way the specs are designed does not prohibit the use of SOAP
faults through the use of corresponding soap:faults in bindings of the
WSDLs.  The current bindings in the wsdls only make use of the one-way
operations that are specified in the existing PortTypes (interfaces). 
Because these bindings are one-way, SOAP faults would not be a suitable
medium for communicating error conditions for 2 major reasons:
1) This is not WS-I BP compliant (see R2714 and R2750 of the BP 1.0
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16651160).  I believe the CAF TC has agreed to adopt BP 1.0 compliance (I recall being at a meeting where we voted on that).

2) The current bindings can be implemented by different endpoints.  Who
gets the fault?  If it's not the sender (and in some cases the sender
doesn't want to receive messages) then it's no different or better than
what is currently in place for fault handling.

That said however, we can have the best of both worlds.  AFAIK the specs
(particularly WSCTX) do not prevent additional bindings from being
used.  To support the soap fault mechanism for request-response messages
we could simply add a new set of wsdls that import the current one-way
wsdls and add new PortTypes with request-response operations and then
add bindings for these PortTypes with soap:faults for the corresponding
operations.  IMO this is the best way to go about supporting SOAP faults
in a simplistic way and a way that supports interoperability. 
Regardless of SOAP faults, I think we should provide some
request-response bindings because I think that they are easier to
implement and easier to understand.
I hope my contribution to this discussion was helpful.

Regards,
Simeon
On Wed, 2004-05-12 at 21:36, Murray, Bryan P. wrote:
> 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
>