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

FW: What should be declared as a Fault in a WSDL

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 14 Nov 2005 14:49:33 -0800
Message-ID: <37D0366A39A9044286B2783EB4C3C4E8BB0AE5@RED-MSG-10.redmond.corp.microsoft.com>
To: <nahudson@sqc.co.uk>
Cc: <public-ws-desc-comments@w3.org>

Thanks for your comment.  The WS Description Working Group tracked this
as a Last Call comment LC361 [1].  Although it was not clear this was
intended as a Last Call comment, we felt it was valuable feedback and
added the explanation at
http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0051.html as a
result.

As we plan to go to CR shortly, if we don't hear from you within 10
days, we will assume this satisfies your concern.

[1] http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC361

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Neil Hudson
> Sent: Monday, October 31, 2005 2:03 PM
> To: www-ws-desc@w3.org
> Subject: What should be declared as a Fault in a WSDL
> 
> 
> 
> I am trying to get a clear understanding of what actually should be
> declared as a fault in the WSDL.  Looking at the various types of
things
> that could occur, some based on recent proposals, it appears there
could
> be:
> 1. Anomalies specific to the operation to be performed such as the
> client failing to supply a mandatory value.
> 2. A generic anomaly such as the XML data supplied to the client being
> malformed.
> 3. A generic anomaly such as the faults described in the WS-Addressing
> proposal.
> 4. A generic anomaly such as an inconsistent SOAP envelope "Client"
> soapFault ( Basic Profile R2724 ).
> 6. An HTTP 4xx error.
> 7. An HTTP timeout.
> 
> Should the WSDL only declare Faults for the cases covered by (1)? The
> argument for this would be that the abstract WSDL defines the
Operation
> and others are generic, existing for all operations, and for 4, 5, and
6
> the particular "faults" depend on the protocols of the bindings and if
> multiple bindings were used would be different for each case.
> 
> The use of an In-Only mode for an operation would also appear to
require
> that the lower level faults are not explicitly declared for the
> operation as that would appear to violate the rules for declaring an
> In-Only operation.
> 
> For example say there is an op where the service reserves the right to
> discard calls in busy periods without telling the client that a
discard
> has occurred.  This is best defined in the WSDL as an In-Only MEP op.
> Now Basic Profile R2724 still requires a SOAP fault be sent back if
the
> SOAP envelope is corrupt, even if you wanted to you can't decide not
to
> do this because the op is In-Only as the corruption may mean you can't
> identify which op was invoked.  So in the WSDL the op has no faults
> because it is In-Only but in fact the consumer can receive SOAP faults
(
> and possibly WS-* faults ).
> 
> So this seems to me that there are explicit Faults declared for the
> operation and implicit faults resulting from the binding to WS-*
> protocols, SOAP and so on.  There seem to be two issues here:
> 1. How are the implicit faults defined / listed?  Should this be part
of
> the definition of the binding?
> 2. What about cases where WSDLs are used as input to toolkits, is
there
> a separate binding-independent set of explicitly declared Faults and a
> concrete binding-dependent set of faults that have to be derived or
put
> in a derived concrete WSDL that can have Faults even in In-Only ops or
> that converts the In-Only to an In-Optional-Fault pattern?
> 
> Any help in clarifying whether I am completely off track here would be
> much appreciated.
> 
> Neil
> 
> --
> ------------------------------------------------------------
> Neil Hudson CEng MBCS MIEEE
> British Computer Society Registered Consultant
> ------------------------------------------------------------
> SQC Technology Limited
> Phone: +44(0)1283 763632
> Fax  : +44(0)1283 763631
> ------------------------------------------------------------
Received on Monday, 14 November 2005 23:04:01 GMT

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