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: Issue - 182 - Proposal Draft for Issue 180, 182 and 185



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: Issue 180, 182 and 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 ... "
--------------------------------
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:

Changes NOT related to this issue:

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







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