Issue - 182 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

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

Title: Proposal for Issue 180, 182, 185

 

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 ... "
--------------------------------
BPEL faults are defined exclusively in terms of a fault name and optional fault data. This means, for example, that if a fault is generated from a messaging activity (as opposed to the throw activity or a system fault) no record will be made in the fault of the portType or operation the message activity was using when the fault was received. A consequence of this model is that 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 and sharing the same data type (or lack there of) are indistinguishable in WS-BPEL, if no fault message or variable types are provided. Faults of a particular fault name can MAY 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 regarding thefor <faultHandlers> and <catch> elements, please see section "Fault Handlers".

In the case that On the other hand, when a fault is being sent using a <reply> activity it is possible to enforce WSDL's fault semantics to some degree, to whit, the fault being sent be defined on the portType and operation specified by the <reply> or a BPEL system fault will be thrown internally and the reply will fail.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, pPlease see section "Providing Web Service Operations" for more details on the <reply> activity..
--------------------------------


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 or faultMessageType whose type matches the type of the fault data then the fault is passed to the identified catch activity.

2.1.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.2.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.3.If there is a catch activity with a matching faultName value that does not specify a faultVariable or faultMessageType 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.4.Otherwise if there is a catch activity without a faultName attribute that has a faultVariable or faultMessageType whose type matches the type of the fault data then the fault is passed to the identified catch activity.

6.4.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.5.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.6.      Otherwise if there is a catchAll handler then the fault is passed to the catchAll handler.

7.      Otherwise the fault is thrown to the immediately enclosing scope. (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 (34) down the list of preference of matching to right before item (68).

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


Section 11.4:

 

Add after the sentence that ends "...will indicate a variable of the message type for the corresponding fault." If the reply activity is to transmit a fault then the specified fault MUST be defined on the WSDL portType/operation or the reply activity MUST fail with a "bpws:faultNotDefinedinWSDL" fault.

 

Appendix A:

 

faultNotDefinedinWSDL - A fault was submitted to a reply that was not defined on the portType/operation.