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

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]
> 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
> that could occur, some based on recent proposals, it appears there
> 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
> and others are generic, existing for all operations, and for 4, 5, and
> 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
> 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
> 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
> SOAP envelope is corrupt, even if you wanted to you can't decide not
> 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
> the definition of the binding?
> 2. What about cases where WSDLs are used as input to toolkits, is
> a separate binding-independent set of explicitly declared Faults and a
> concrete binding-dependent set of faults that have to be derived or
> 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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:57 UTC