WSDL faults

I took an action item on clarifying what the problem was with WSDL faults
and what the options to deal with it. Thinking about the issue I have
changed my view of what the correct solution is from what I defended in the
last f2f. Here it is:

A Proposal to Eliminate the Fault Name Attribute
========================================

The problem with Fault Names
---------------------------------------------
WSDL 1.1 introduces faults in request-response operations in the form of
alternative output messages, to be returned when normal processing cannot
be completed for any reason. The <fault> element identifies the type of the
returned message and assigns a name to the fault. Names are required to be
unique among the different faults of an operation.

Fault names are local to the operations where the fault is defined, while
the message type name is global. Any two operations within the same port
type or in different port types can use similar names for faults that are
otherwise completely unrelated in both their type and semantics. The result
is that in general it is not possible to identify a fault message unless
the names of the port type and operation are explicitly specified.

This design makes processing faults unnecessarily cumbersome. To design a
"try-catch" mechanism based on WSDL signatures, as the one proposed by
BPEL4WS, a fault handler would need to identify the port type, operation
and fault names of each fault it needs to catch in order to deal with fault
name clashes. This makes it difficult to factor out common fault handling
for different operations in a single handler. A similar situation would
arise in a network deployment in which an intermediary is installed to deal
with faults generated in the course of an interaction. The ability of the
intermediary to react in an uniform and unambiguous way to faults cannot be
based on local fault names.

The common requirement in these examples is the need to identify faults
regardless of the operation where they appear. WSDL 1.1 fault names are
clearly not suited for this purpose.

Alternatives
-----------------
If we accept that it is appropriate for WSDL 1.2 to enable the
identification of faults regardless of the operation that generated them,
there are three options available:

1. Assign global (qualified) names to faults. This may be accomplished in
two ways:

a. Explicitly: Faults are defined as using a top level <fault> element,
nested directly under <definitions>; the <fault> element would associate a
name with a message type. A qualified name is assigned to the fault
following the usual WSDL naming rules for top level definitions. Faults in
operations simply need to identify the fault's qualified name.

b. Implicitly: Faults are implicitly defined when they are declared within
an operation definition. The message attribute for the fault (or it future
replacement) only appears in the <fault> element when the fault is defined.
The name attribute in <fault> becomes a qualified name.

2. Identify faults based on the type of the fault message. A different
message type is defined for each distinct fault type; the message type name
uniquely identifies a fault.

Option 1.a introduces an additional level indirection and unnecessarily
complicates the definition of operations (by introducing an extra
definition or lookup step). Option 1.b is inconsistent with the decision of
not assigning global names to non-global definitions such as operations.
Option 2 is simpler of the three and uses well established mechanisms (the
type system) to globally identify faults.

Proposal
-------------
Consistent with option 2, the proposal is to eliminate the "name" attribute
from the <fault> element, thus requiring authors to define appropriate
message types to identify faults used in operations definitions. The
(global) fault type would uniquely identify the fault.

Received on Saturday, 18 January 2003 19:25:07 UTC