Issue 10 - Proposal to Vote (with example attached)

["Satish Thatte" <satisht@microsoft.com>]

Forgot to attach the example!  The problem is defining the default compensation behavior for scope S1 independent from the compensation of scope S2.  This is the same example we were looking at 6 months ago at the F2F in Redmond and scratching our heads.

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Friday, June 18, 2004 9:36 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue 10 - Proposal to Vote

Informally, we propose that default compensation order need only respect the control dependencies that are explicitly modeled.  With the proposed resolution of Issue 1, it is far from easy to emulate strict reverse order of completion with explicit fault and compensation handlers.  But with the proposed resolution of Issue 10 here, that does not matter since strict reverse order is permitted but not mandated for the default behavior.  This does require an additional restriction on links, as described below more formally.

Definition:  Control Dependency.  If an activity A must complete before activity B begins, as a result of the existence of a control path from A to B in the process definition, then we say that B has a control dependency on A.  Note that control dependencies may occur due to control links in <flow> as well as due to constructs like <sequence>.

Part I:  Consider scopes A and B such that B has a control dependency on A.  Assuming both A and B completed successfully and both must be compensated as part of default compensation behavior, then the compensation handler of B must run to completion before the compensation handler of A is started.  This permits scopes that executed concurrently on the forward path to also be compensated concurrently in the reverse path.  Of course, if one follows the strict reverse order of completion, then that necessarily respects control dependencies.  

Definition:  Reentrant control path.  Consider activities A and B enclosed in a scope S, such that B has a control dependency on A.  The control path from A to B is said to be reentrant if it includes an activity C that is outside scope S, i.e., there is an activity C outside scope S such that C has a control dependency on A and B has a control dependency on C.  Informally, such a reentrant path starts at A, "leaves scope S" to reach activity C and then "reenters scope S" to reach activity B.  Note that reentrant control paths always involve links, at the least, one to leave the scope and one to reenter the scope.

Part II:  It is necessary to be able to define the default compensation behavior of a given scope independent of its peer and enclosing scopes.  One reason is that such a default compensation handler may be invoked explicitly by the fault and compensation handlers of its enclosing scope.  However, there are currently legal cases where the proposed resolution in Part I makes this impossible.  One such example is attached.  We propose to resolve this by banning reentrant control paths.  This restriction would be added to the list of restrictions on links at the end of section 12.5.

Nick Kavantzas
Frank Leymann
Dieter Koenig
Satish Thatte
Alex Yiu



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.

compensation order.jpg