Issue - 121 - draft proposal

[Alex Yiu <alex.yiu@oracle.com>]

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.