RE: WSDL faults

Francisco,

I have always considered the fault name to be a global name with name
equality across operations. In other words, if two operations defines in the
same target namespace use the same fault name they actually refer to the
same fault. I believe this is what you refer to in option 1.b.

As you said that simplifies the use of fault handlers in the process
definition, but still presents two problems.

Let's say I have a service that implements an operation and to implement
that operation must invoke two other operations against two other services.
Both services return the fault tns:badRequest and so the aggregate service
also returns the fault tns:badRequest.

First, each operation can decide to use a different message to describe the
information that is returned as part of the fault. One service may return
element X and another service may return element Y. The aggregate service
must return either X or Y, or yet another schema that can contain either X
or Y. This would complicate the process definition and would impede
reusability.

It becomes more effective if a fault could be associated with a specific
schema such that this fault would also communicate information conforming to
that schema, or even better if the schema implies the fault (as your propose
in option 2).

Second, for modularity it might be easier to define each service using a
different target namespace. That however would make all the faults have
different names if the fault's namespace name is derived from the target
namespace of the WSDL document (as for option 1.b and our current practice).

This problem is solved if the fault is defined separately from the operation
and is referenced by the operation.

I agree with you that option 2 would be the best option to pursue. In
addition it allows WSDL 1.1 service definitions to be written in a
conformant matter by electing to use a fault name that is identical to the
message name.

regards,
arkin

> 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 Sunday, 19 January 2003 01:14:10 UTC