Issue - 182 - Proposal For Vote

The following is a friendly amendment to Alex's proposal but my guess is 
that Alex and I will need to discuss it.
	Yaron

Alex Yiu wrote:
> Hi all,
> 
> Yaron and I have been working together to come up the wordings for the proposal 
> to tackle Issue 180, 182, and 185 in a consistent manner (since all these 3 
> issues are highly inter-related.)
> 
> Please take a look into the proposal attached. I guess we shall try to discuss 
> it in F2F, if time allows.
> 
> (Note:
> 
>     * Parts of this proposal draft comes from Yaron. I just finished the draft
>       of combining pieces right before the long weekend. Hence Yaron has NOT got
>       a chance to review this version of text yet. (But I personally would not
>       expect Yaron would have any major disagreement with that.)
>     * I still decide to send it off to the TC list, since I want to give enough
>       time for people to read on this proposal before the F2F
>     * This proposal draft has been shared in a smaller group. Particularly
>       factoring in some of the Satish's friendly amendments.
> 
> )
> 
> 
> Thanks!
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
>       Proposal for Issue 180, 182, 185
> 
> 
> Last modified date: May 30, 2005 - 1:30 pm PDT
> 
> Parts of Proposal to address: Issue 180 and Issue 185
> 
> (Adopting Satish's friendly amendment concern about resolving contradictory texts)
> 
> The related pargraph quoted from Section 11.3:
> 
> From:
> --------------------------------
> 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.
> --------------------------------
> 
> To:
> --------------------------------
> 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. WSDL 1.1 does not require that fault names be 
> unique within the namespace where the service operation is defined. 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.
> --------------------------------
> 
> In Section 11.3, add the following after the paragraph which starts with "Note 
> that a WSDL fault is identified ... "
> --------------------------------
> When a BPEL processor needs to differentiate faults (e.g. for different handling 
> logic in <faultHandlers>), neither a portType nor an operation name is used to 
> identify a fault, because of the preference of keeping WS-BPEL fault model 
> simple and consistent. That implies, all faults sharing a common name and 
> defined in the same namespace are indistinguishable in WS-BPEL, if no fault 
> message or variable types are provided. Faults of a particular fault name can be 
> associated with multiple variable types and the <catch> construct in WS-BPEL 
> facilitates differentiation of faults with different message / variable types of 
> the same fault name. For details for <faultHandlers> and <catch>, please see 
> section "Fault Handlers".
> 
> On the other hand, when a fault is replied back to a web-service invoker by a 
> WS-BPEL process with a <reply> activity, finer grain level of fault related 
> analysis is possible, since the portType and operation name information is 
> already associated with a <reply> activity and a WS-BPEL processor is able to 
> identify which exact fault the <reply> activity refers to. For details of 
> <reply> activity, please see section "Providing Web Service Operations".
> --------------------------------
> 
> 
> Parts of Proposal to address: Issue 182 and Issue 185
> 
> (After getting an agreement from Satish on "symmetrical" design on <catch>)
> 
> 
> In Section 13.4
> 
> Change #1:
> From:  (copied from Issue 12.1 resolution)
> ===================================
> 
> In the case of faults thrown with associated data the fault will be caught as 
> follows:
> 
> ·        If there is a catch activity with a matching faultName value that has a 
> faultVariable whose type matches the type of the fault data then the fault is 
> passed to the identified catch activity.
> 
> ·        Otherwise if the fault data is a WSDL message type where the message 
> contains a single part defined by an element and there exists a catch activity 
> with a matching faultName value that has a faultVariable whose type matches the 
> type of the element used to define the part then the fault is passed to the 
> identified catch activity with the faultVariable initialized to the value in the 
> single part’s element.
> 
> ·        Otherwise if there is a catch activity without a faultName attribute 
> that has a faultVariable whose type matches the type of the fault data then the 
> fault is passed to the identified catch activity.
> 
> ·        Otherwise if the fault data is a WSDL message type where the message 
> contains a single part defined by an element and there exists a catch activity 
> without a faultName attribute that has a faultVariable whose type matches the 
> type of the element used to define the part then the fault is passed to the 
> identified catch activity with the faultVariable initialized to the value in the 
> single part’s element.
> 
> ·        Otherwise if there is a catchAll handler then the fault is passed to 
> the catchAll handler.
> 
> ·        Otherwise the fault is thrown to the immediately enclosing scope.
> 
> ===================================
> 
> To:
> ===================================
> 
> In the case of faults thrown with associated data the fault will be caught as 
> follows:
> 
>    1. If there is a catch activity with a matching faultName value that has a
>       faultVariable whose type matches the type of the fault data then the fault
>       is passed to the identified catch activity.
>    2. Otherwise if the fault data is a WSDL message type and there exists a
>       catch activity a matching faultName value and a matching faultMessageType,
>       then the fault is passed to the identified catch activity with the
>       faultVariable initialized.
>    3. Otherwise if the fault data is a WSDL message type where the message
>       contains a single part defined by an element and there exists a catch
>       activity with a matching faultName value that has a faultVariable whose
>       type matches the type of the element used to define the part then the
>       fault is passed to the identified catch activity with the faultVariable
>       initialized to the value in the single part’s element.
>    4. If there is a catch activity with a matching faultName value that does not
>       specify a faultVariable value then the fault is passed to the identified
>       catch activity. Note that in this case the fault value will not be
>       available from within the fault handler but will be available to the
>       <rethrow> activity. 
>    5. Otherwise if there is a catch activity without a faultName attribute that
>       has a faultVariable whose type matches the type of the fault data then the
>       fault is passed to the identified catch activity.
>    6. Otherwise if the fault data is a WSDL message type and there exists a
>       catch activity without a faultName attribute but a matching
>       faultMessageType, then the fault is passed to the identified catch
>       activity with the faultVariable initialized.
>    7. Otherwise if the fault data is a WSDL message type where the message
>       contains a single part defined by an element and there exists a catch
>       activity without a faultName attribute that has a faultVariable whose type
>       matches the type of the element used to define the part then the fault is
>       passed to the identified catch activity with the faultVariable initialized
>       to the value in the single part’s element.
>    8. Otherwise if there is a catchAll handler then the fault is passed to the
>       catchAll handler. (Note: there is always a default <catchAll> fault
>       handler, even when users do not specify explicitly.)
> 
> ===================================
> 
> Note:
> 
>     * Only item (4) is added for this issue.
>     * Some suggests to move item (4) down the list of preference of matching to
>       right before item (8).
> 
> 
> Changes NOT related to this issue:
> 
>     * For the addition of Items (2) and (6), it seems to me that we forgot to
>       specify those cases in Issue 12.1 resolution. 
>     * Changes in Item (8) is to remove the last bullet and clarify the role of
>       default fault handler. We need to apply similar changes to the bullet list
>       for "the case of faults thrown without associated data".
> 
> 
> Change #2:
> From:
> ---------------------------------
> A fault caught by a <catchAll> handler or by a custom fault handler that does 
> not specify a faultName, may need to be rethrown. However the <throw> activity 
> that requires a faultName can not be used here as the faultName is not 
> available.  Hence all fault handlers are allowed to rethrow the original fault 
> with a <rethrow> activity that is defined to be an empty element....
> ---------------------------------
> 
> To:
> ---------------------------------
> It is sometimes necessary to rethrow a caught fault. However the <throw> 
> activity requires both a fault name and the fault value. In the case of a 
> <catchAll> handler or a custom fault handler that does not specify a faultName 
> the fault's name won't be accessible for use in the <throw> activity. In the 
> case that a fault with associated data was caught by a customer fault handler 
> that only specified the fault's name  the fault's data won't be accessible for 
> use in the <throw> activity. Hence all fault handlers are allowed to rethrow the 
> original fault with a <rethrow> activity that is defined to be an empty element....
> ---------------------------------
> 
> Other corrections not related to this issue:
> --------------------------------
> From: faultMessageType="qname"
> To: faultMessageType="qname"?
> (Note: this was just a typo in the text.
> AYIU: I already fixed this typo on May 1st editorial.)
> --------------------------------
> 
> 
> 
> 
>