Issue - 180 - an alternative proposal

Hi all,

What I am suggesting:

I am suggesting an alternative proposal, which perserves the fault
handling capability in BPEL 1.1 and current state of BPEL 2.0, instead
of restricting the WSDL designs that BPEL can support. (That is I think
Dieter Koenig also prefers)

As Yaron mentioned in the last conf call, he does not have a strong
preference whether to keep or restrict our current fault handling
capabilies, as long as our BPEL spec is clear and consistent. I
think/hope this alternative proposal provides a clear enough
clarification to section 11.3 to avoid any further confusion of our
intention of fault identification and handling. 

Actual Text Changes Suggestion:

In Section 11.3, add the following to the end of the paragraph which
starts with "Note that a WSDL fault is identified ... "

-------------------------------------

Even though a fault in WS-BPEL is just identified by the fault name, 
it does NOT enforce that faults of a particular fault name can be
associated with one fault message type. On the contrary, faults of a
particular fault name can be associated with multiple message types and
the <catch> construct in WS-BPEL facilitates differentiation of 
faults with different (message) types of the same fault name. 

-------------------------------------

The related pargraph quoted from Section 11.3 (for your convenience)

--------------------------------

Note that a WSDL fault is identified in WS-BPEL by a qualified name
formed by the target namespace of the corresponding portType and the
fault name. This uniform naming mechanism must be followed even though
it does not accurately match WSDL’s faultnaming model. Because WSDL
does not require that fault names be unique within the namespace where
the service operation is defined, all faults sharing a common name and
defined in the same namespace are indistinguishable in WS-BPEL. In WSDL
1.1 it is necessary to specify a portType name, an operation name, and
the fault name to uniquely identify a fault. This limits the ability to
use fault-handling mechanisms to deal with invocation faults. This is
an important shortcoming of the WSDL fault model that will be removed
in future versions of WSDL. 

--------------------------------

Lengthy version on why we should keep the current fault handling
capabilities:

One of key decision of Issue 180 is about whether we want to support /
ban "fault overloading", which BPEL 1.1
has been already supporting that. That is, the same fault name can be
associated with more than one (message) types.

(Note: 

  
the "fault overloading" may not be a good term to describe this
concept. But, let's use this for now. 

  

  
IMHO, "fault overloading" is very different from "operation
overloading".

  
IMHO, again, we should keep the current state of BPEL design with
just some clarification in the spec.)

In WSDL 1.1 world, a fault name is uniquely identified by
portType+operation+faultName. 

In BPEL world, a fault name is uniquely identified by just the
faultName. (See Section 11.3)

[My guess on the rationale of BPEL usage on faultName is: (a) We have
<throw> activity, which is not associated with any portType and
operation. (b) This fault name identification allow us to have one
fault handler for the faults of the same fault names from different
operations and portTypes.] 

However, some people tend to extend the interpretation of section 11.3
to suggest that the faultName should be restricted to be associated
with one fault (message) type only. 

Personally, I don't see the necessity of that extended interpretation.
Reasons:

  
Currently, we have already have variation of <catch> clause
to catch the same faultName with different message types. There is no
big problem for that. 

  

  
Today, WSDL of the same targetNamespace can be created and
maintained in a distributed fashion. It is quite probable that
different people in the same organization will use the same faultName
in different WSDL. It will be associated with different message types
under different operations or different portTypes. It will be a big
loss to BPEL functionality, if we say we cannot support those set of
WSDLs within a BPEL process. 

  
If we ban "fault overloading" in BPEL 2.0, we create some truely
profound backward compatibility problem with BPEL 1.1. And, we need to
make
a bunch of clear-up changes to <catch> syntax and semantics. 

The reasons that we ban operation overloading is quite different: In
BPEL 1.1 or 2.0, we
don't have constructs to support WSDL 1.1. operation
overloading properly. And, in WSDL 2.0, operation overloading
is likely gone. What we needed was just a clear clarification to say we
don't support operation overloading without other changes. 

Thanks!

Regards,

Alex Yiu