OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] Issue - 180 - an alternative proposal

I think the "distributed management of WSDL" argument is not very strong -- distributed management of a namespace does not exempt anyone from the responsibility to avoid name collisions.  I don't think we would make the same argument for portType names.
That said, the real issue is that for names that are not "top level", WSDL 1.1 (and WSDL 2.0 afaik) follows the lexical scoping convention, i.e., uniqueness is required only within the "enclosing scope" for the name, if that.  However, name visibility does not follow the lexical scoping convention; nested names such as fault names are globally visible and we use them as such in BPEL.  And there is nothing we can do about this.
I am sympathetic to the "keep things as they are" approach for compatibility reasons.  It would be painful to add too many restrictions that invalidate perfectly legal WSDL 1.1 namespaces especially when we have a reasonable way to avoid that, especially when WSDL 2.0 does not seem to be making things any better.  But we will have to modify the existing language in the 11.3 paragraph you mention below because it clearly suggests a more restrictive interpretation: "all faults sharing a common name and defined in the same namespace are indistinguishable in WS-BPEL" is in fact not true--they can be distinguished based on the associated message type if one chooses to do so in the <catch>.


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Tue 5/3/2005 6:36 PM
To: wsbpeltc
Cc: Alex Yiu
Subject: [wsbpel] 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.


*	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. 


Alex Yiu

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]