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).
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
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.
generates this mail. You may a link to this group
and all your TCs in OASIS