Hi, Yaron,
[ I know you are on vacation now ... Still, I would like to reply this
thread. :-) ]
Thanks for clarification.
Few points to add:
- +1 to the part of rename <teminate> activity to
<halt> activity. Because, I got a similar confusion between
"forcedTermination" fault and <terminate> activity, when I first
read the spec. Also, the term "terminate" is used everywhere in the
spec. But, the usage of "terminate" has no relation with
<terminate> activity.
- Regarding to the fault handler part of proposal,
- Default fault handler: For clarity, we may want to
change the description of default fault handler in Section 13.4.1 as
well. Currently, it said: "Rethrow
the fault to the
next enclosing scope.". I think it should say: "Rethrow
the fault to the
next enclosing scope, if the fault is not bpws:forcedTermination".
- In
the case of <catch faultName="bpws:forcedTermination">:
We may want to enforce the prohibition <throw> or <rethrow>
within this particular kind of <catch> construct by static
analysis.
- In
the case of <catchAll>:
I think users should be able to use <catchAll> to catch
"bpws:forcedTermination" fault. Because users should be able to
specify an explicit fault handler to perform any partial undo
operation, no matter which fault is causing the problem. In order to
observe "bpws:forcedTermination",
I have two alternative proposals to refine catchAll semantics.
[A] If a <catchAll> handler exists without a
<catch faultName="bpws:forcedTermination"> handler in the same
scope, <throw> or <rethrow> will be disallowed in the
<catchAll> handler. This restriction can be enforced by static
analysis. This restriction will essentially force BPEL developers to
have two fault handlers when then want to throw fault in
<catchAll>. [Better code clarity; more burden on users]
[B] If a <catchAll> get a "bpws:forcedTermination",
any <throw> or <rethrow> activity within that
<catchAll> fault handler instance will become an NO-OP. [Less
code clarity; less burden on users]
Thoughts ... ? Particularly for the last item.
Thanks!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
I am not
proposing any functional changes, I am just proposing changing the name
of "terminate" to "halt" so as to prevent confusion with the completely
unrelated bpws:forcedTermination fault.
Thanks,
Yaron
Alex Yiu wrote:
Hi, Yaron,
Do you mean to introduce a new activity "halt"?
If so, could you highlight again what is the difference between "halt"
and "terminate"?
Thanks!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
Below is a first attempt to creating a
proposal for vote for issue 135.
Thoughts? Comments?
Yaron
Proposal Summary:
* Change the name of the terminate activity to the Halt activity.
* Specify that the bpws:forcedTermination fault cannot be caught by
catchAll handlers.
Proposed Language Changes:
Change all instances of the Terminate activity name to Halt.
Change section 14.6 to read:
The halt activity can be used to immediately halt the business process
instance within which the halt activity is performed. All currently
running activities MUST be halted as soon as possible without any fault
handling or compensation behavior.
<halt standard-attributes>
standard-elements
</halt>
Section 13.4:
Current Language: A catchAll clause can be added to catch any fault not
caught by a more specific catch handler.
Proposed Language: A catchAll clause can be added to catch faults not
caught by a more specific catch handler, with the exception of the
bpws:forcedTermination fault.
Delete the following sentence, it appears twice: Otherwise, the default
catchAll handler is selected if present.
Add an extra bullet after the existing two bullets in section 13.4 that
reads: If the fault is not caught by any of the handler's catch clauses
per the previous two rules, the fault is not a bpws:forcedTermination
fault, and there is a catchAll handler then the fault MUST be caught by
the catchAll handler.
Insert the following sentence after the previous bullet: The
bpws:forcedTermination fault cannot be caught by the catchAll handler
because the environment in which bpws:forcedTermination faults are
handled is different than the normal BPEL fault environment and so a
dedicated fault handler is needed. If a dedicated
bpws:forcedTermination fault handler is not provided then
bpws:forcedTermination fault is dropped.
Current Language: If there is fault data associated with the fault, the
third catch will be selected if and only if the type of the fault’s
data matches the type of variable “bar”, otherwise the default catchall
handler will be selected. Finally, a fault with a fault variable whose
type matches the type of “bar” and whose name is not “x:foo” will be
processed by the second catch. All other faults will be processed by
the default catchall handler.
Proposed Language: If there is fault data associated with the fault,
the third catch will be selected if and only if the type of the fault’s
data matches the type of variable “bar”. Finally, a fault with a fault
variable whose type matches the type of “bar” and whose name is not
“x:foo” will be processed by the second catch. All other faults, other
than the bpws:forcedTermination fault, will be caught by the catchall
handler and discarded.
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
|