W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > June 2005

RE: Faults that are not described in WSDL?

From: David Booth <dbooth@w3.org>
Date: Wed, 08 Jun 2005 12:03:15 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: Jonathan Marsh <jmarsh@microsoft.com>, public-ws-desc-comments@w3.org
Message-Id: <1118246596.19955.267.camel@nc6000.w3.org>

Yes, SOAP 1.2 does define how faults are transmitted:
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapfault
But that is at the transport level.  Something still needs to say how
SOAP's notion of a fault maps to WSDL's notion of a fault, which is
independent of transport.  For faults that are declared in a
wsdl:interface, this is already covered by the spec, because the
wsdl:binding must explicitly specify how they are mapped.  But for
Undeclared Faults, the spec does not say how they are to be
mapped/recognized.

My suggested additional verbiage for the WSDL SOAP MEP Binding Extension
may not be worded quite right.  Perhaps it should talk about the
soap12:Fault element instead of fault codes.  But the point is that
something in the spec should say how Undeclared Faults are to be
recognized at the WSDL abstract level.  Otherwise, different
implementations are apt to handle them differently -- all supposedly
being faithful to the wsdl:interface that the service exposed.  

David Booth

On Thu, 2005-06-02 at 07:15 -0700, Martin Gudgin wrote:
> Doesn't SOAP define what a fault is? I always thought it was any message
> that had soap:Fault as a child of soap:Body...
> 
> Gudge 
> 
> > -----Original Message-----
> > From: David Booth
> > Subject: RE: Faults that are not described in WSDL?
> > 
> > 
> > I think this needs more attention, and perhaps I was not clear enough
> > about my concern.  I'm fine with faults being an open set.  
> > That is not my concern.  
> > 
> > My concern is that the spec is not clear about how faults that are not
> > described by the WSDL interface would be recognizable as faults when
> > they are received.  In other words, if a client receives an unexpected
> > message X, how does it know whether message X represents a 
> > well-formed,
> > undeclared fault message or is an erroneous message containing random
> > gibberish?  Something must indicate to the client, in a
> > machine-processible language that the client understands, 
> > that message X
> > represents a fault.  
> > 
> > I think there is an implicit assumption being made that either:
> > 
> > a. binding/transport-level mechanisms will permit undeclared faults to
> > be recognizable as undeclared faults (for example, by the use of SOAP
> > fault codes or HTTP error codes); or
> > 
> > b. the parties must agree out-of-band (i.e., outside of the WSDL
> > description) how undeclared faults can be recognized as undeclared
> > faults.
> > 
> > Section 2.3.1 seems to be saying that conceptually every interface has
> > one more fault type implicitly declared -- call it 
> > UndeclaredFault -- in
> > addition to the explicitly declared faults, and this is a catch-all
> > fault type that can indicate any kind of fault.  Thus, an application
> > written against the interface must be prepared to handle an
> > UndeclaredFault in addition to the declared faults.  But how is this
> > UndeclaredFault at the abstract level bound to an underlying
> > binding/transport mechanism?  AFAICT, the spec does not say.  In other
> > words, if a party wishes to send an UndeclaredFault, what 
> > mechanism must
> > be used to send it?  Both parties need to know what mechanism will be
> > used, thus either the WSDL document or the WSDL spec should say
> > explicitly what that mechanism is.  Rather than being silent and
> > assuming that "magic occurs", I think it would be much better for the
> > spec to discuss these UndeclaredFaults explicitly.
> > 
> > In general, the binding is responsible for indicating how 
> > notions at the
> > abstract level are manifested at the transport level.  In theory, a
> > binding extension could provide syntax to permit 
> > UndeclaredFaults to be
> > bound explicitly to an underlying mechanism via 
> > wsdl:bindings.  However,
> > in practice, the binding extensions may always bind 
> > UndeclaredFaults in
> > a fixed, default way.  For example, UndeclaredFaults might always be
> > bound to SOAP fault codes if the WSDL SOAP binding extension 
> > is used, or
> > using HTTP error codes if the HTTP binding extension is used.
> > 
> > In summary, I think clarification along the following lines 
> > would help:
> > 
> > 1. Part 1 should give some indication of how UndeclaredFaults are
> > expected to be bound.  For example, it could add a subsection like:
> > [[
> > Undeclared Faults
> > Faults other than the ones described in the Interface 
> > component can also
> > be generated at run-time, i.e. faults are an open set.  
> > Faults that are
> > not declared in the Interface component are known as 
> > Undeclared Faults. 
> > 
> > Note: It is the binding extension's responsibility to specify how
> > Undeclared Faults are transmitted.  For examples, see Part 2 SOAP
> > Binding Extension section @@BindingUndeclaredFaults@@ or Part 2 HTTP
> > Binding Extension section @@BindingUndeclaredFaults@@.
> > ]]
> > 
> > 2. The binding extensions should say explicitly how 
> > UndeclaredFaults are
> > transmitted.  For example, the WSDL SOAP MEP Binding 
> > Extension could add
> > a subsection to section 4.7 like:
> > [[
> > Binding Undeclared Faults
> > In addition to any faults that are explicitly declared for an 
> > interface,
> > the WSDL SOAP Binding Extension can transmit Undeclared Faults
> > @@reference Part 1 Undeclared Faults@@ associated with the interface.
> > Undeclared Faults are always transmitted using SOAP fault code/subcode
> > combinations that are not associated with any declared faults for the
> > interface.
> > ]]
> > (The above might need to be stated in a little tighter spec-ese, but
> > hopefully this gives you the idea.)
> > 
> > The WSDL HTTP Binding Extension could say something similar.
> > 
> > Please let me know if further clarification would help.
> > 
> > Thanks,
> > David Booth
> > 
> > 
> > On Fri, 2005-05-20 at 20:44 -0700, Jonathan Marsh wrote: 
> > > Thank you for your comment - we tracked this as a Last Call 
> > comment LC72
> > > [1].  The Working Group declined to make any changes to the 
> > spec as a
> > > result.  Faults by their very nature need to be an open set.  
> > > 
> > > If we don't hear otherwise within two weeks, we will assume this
> > > satisfies your concern.
> > > 
> > > [1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC72
> > > 
> > > > -----Original Message-----
> > > > From: public-ws-desc-comments-request@w3.org 
> > [mailto:public-ws-desc-
> > > > comments-request@w3.org] On Behalf Of David Booth
> > > > Sent: Thursday, October 28, 2004 8:37 AM
> > > > To: public-ws-desc-comments@w3.org
> > > > Subject: Faults that are not described in WSDL?
> > > > 
> > > > 
> > > > Part 1 section 2.3.1 says "Note that faults other than the ones
> > > > described in the Interface component can also be generated at run-
> > > > time,
> > > > i.e. faults are an open set.".
> > > > 
> > > > I think this needs clarification.  How can a client 
> > application or Web
> > > > service know what additional faults to expect, and what message
> > > > schemas
> > > > would describe such faults?
> > > > 
> > > > --
> > > > 
> > > > David Booth
> > > > W3C Fellow / Hewlett-Packard
> > > > 
> > > 
> > -- 
> > David Booth <dbooth@w3.org>
> > 
> > 
-- 
David Booth <dbooth@w3.org>
Received on Wednesday, 8 June 2005 16:06:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:31 GMT