[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:
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:
Thanks! Regards, Alex Yiu |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]