Re: [wsbpel] Issue - 182 - Proposal For Vote

[Alex Yiu <alex.yiu@oracle.com>]

Hi all,

I have merged most of changes suggested by Yaron as friendly amendment. 
And, I made a few minor other changes as well. And, I have shown text 
Yaron (on computer screen during F2F) and he feels comfortable with 
those text also.

Hence, this is updated version of the proposal to vote (attached).

Thanks!


Regards,
Alex Yiu


Yaron Y. Goland wrote:

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

Title: Proposal for Issue 180, 182, 185

 

Proposal for Issue 180, 182, 185

Last modified date: June 01, 2005 - 6: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 all faults sharing a common name, defined in the same namespace and sharing the same data type (or lack there of) are indistinguishable in WS-BPEL. Faults of a particular fault name 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 the <faultHandlers> and <catch>, please see section "Fault Handlers".

In the case that 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 MUST be defined on the portType and operation specified by the <reply> or an internal BPEL system fault (bpws:faultNotDefinedinWSDL) MUST be thrown internally and the <reply> activity will fail. Please 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. 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.

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. 

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

6.      Otherwise if there is a catchAll handler then the fault is passed to the catchAll handler.

7.      Otherwise,  the fault will be handled by the default fault handler.

===================================

Note:

·         Some suggests to move item (3) down the list of preference of matching to right before item (6).

 

Changes NOT related to this issue:

·        Fixing some mistakes in Issue 12.1 in item (1) and (4) by adding “faultMessageType”.

·        Add clarification of default fault handler.

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