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
- From: Alex Yiu <alex.yiu@oracle.com>
- To: wsbpeltc <wsbpel@lists.oasis-open.org>
- Date: Mon, 30 May 2005 12:54:12 -0700
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:
- 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 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.
- 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.
- 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.
- 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 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.
- 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. (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.)
--------------------------------
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]