wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Issue - 121 - draft proposal
- From: Alex Yiu <alex.yiu@oracle.com>
- To: wsbpeltc <wsbpel@lists.oasis-open.org>
- Date: Tue, 02 Nov 2004 13:39:57 -0800
Hi, all,
Glenn, Muruga and I work together and come with this draft proposal for
Issue 121 for <finally>.
Feedback are very welcome.
Thanks!
Regards,
Alex Yiu
Title: Issue 121 - proposal
Issue 121: <finally> construct
Last modified: October 27, 2004 - 6PM
Currently there is not a construct allowing developers to define a
fragment of BPEL code that needs be executed any time a scope is exited
(whether it be a normal exit or due to a fault).
Draft Proposal for Issue 121.
Define an optional
"finally" construct as a child of the scope construct. It contains only
one activity (finally activity), which will be executed when the scope
is being exited in either successful completion of the scope or the
case where the scope is faulted. The finally activity has access to all
the local partnerLinks and variables of the scope it's attached to. The finally activity can be a sequence, scope or flow itself which can contain nested activities.
<scope>
<partnerLinks> ... </partnerLinks>?
...
<faultHandlers> ... </faultHandler>?
<finally> activity </finally>?
<compensationHandler> activity </compensationHandler>?
...
<scope>
Faults that happened inside finally construct will bubble up out of the scope the finally construct is attached to.
A scope with finally construct can be compensated as usual.
Compensation happens after a scope has succesfully exited, at which
time the finally activity, if defined, was already exeucted. Therefore
finally construct has no effect on the bpel compensation mechanism.
More elaboration of <finally> semantics
- normal completion: After the main activity enclosed by the
scope construct is finished, the fault handlers will be uninstalled.
Then the finally activity will be executed. If a fault happens
within the finally activity, the fault will be bubbled-up. The scope will be kept marked as "completed".
- faulted (F1) within the main activity of the scope:
- After
the fault handler is completed successfully, the finally activity will
be executed. If there is a fault (F3) within the finally activity, the
fault (F3) will be bubbled-up instead of F1. The scope will be kept marked as "faulted".
- After
another fault (F2) happened within the fault handler, the finally
activity will be executed before F2 is being bubbled up. If there is a
fault (F3) within the finally activity, the F3 will be bubbled-up instead of F2. The scope will be kept marked as "faulted".
- termination
handler: The situation will be similar to fault handler, except the
fault in finally activity will not bubble up and it will be swallowed silently instead.
- After the termination handler is completed successfully, the
finally activity will be executed. If there is a fault (F3) within the
finally activity, the fault (F3) will be swallowed silently. The scope will be kept marked as "terminated".
- After
a fault (F2) happened within the termination handler, F2 will be swallowed siliently. Then, the finally
activity will be executed. If there is a
fault (F3) within the finally activity, the F3 will be swallowed silently. The scope will be kept marked as "terminated".
- early completion: If we adopt an early completion semantics
similar to Satish's proposal, the semantics of finally activity will be
similar to the case of normal completion.After the early completion activty is finished,
the fault handlers will be uninstalled. Then the finally activity will
be executed.
Rationale:
This proposal defines a way to let user to do clean-up jobs at the end
of the scope, no matter how the scope finishes. This is very simiar to
the java "finally" constrct, except for that the java "finally" doesn't
have access to the local variables of the block.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]