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

Neil,

WSDL doesn't prevent you from describing faults generated
by the binding or underlying protocols, and it doesn't have
to be a comprehensive list of all possible faults.

In essence it is a design decision of the publisher which 
faults they choose to highlight in the description. I'd therefore
agree with Arthur, and my rule of thumb would be to describe
those faults you anticipated a consumer to handle in a switch 
statement inside high-level 'application' code.

HTH 
Paul


-----Original Message-----
From: www-ws-desc-request@w3.org on behalf of Arthur Ryman
Sent: Tue 11/1/2005 5:54 AM
To: Neil Hudson
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: What should be declared as a Fault in a WSDL
 
Neil,

IMHO, WSDL should declare application level faults. These are faults that 
the client of the Web service could reasonably be able to react to, e.g. 
semantic errors, like. invalid customer id. Other faults, like bad SOAP 
envelope or messages that violate the XML schema should be generic and not 
explictly defined in WSDL. Such faults can be detected by the middleware 
and they apply to all Web services so there is no point in declaring them 
in the WSDL. In general, an application does not generate the SOAP 
envelope or serialize the message as XML - that is handled by the runtime 
so errors there are beyond the control of the application programmer.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



Neil Hudson <nahudson@sqc.co.uk> 
Sent by: www-ws-desc-request@w3.org
10/31/2005 05:03 PM

To
www-ws-desc@w3.org
cc

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 Tuesday, 1 November 2005 10:21:37 UTC