Proposal to vote - Issue 10

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

I would like to see this issue resolved by the upcoming F2F.  To start that process here is the formal proposal to vote.  Comments welcome as usual.

The formal proposal simply collates the note I sent this morning with the strawman I posted some time ago.

Starting point:   

Recall that at one point I had suggested that we make "reversibility" an
explicit attribute of scopes and require that all reversible scopes are
also isolated.  This would have solved the problem of default
compensation order by creating (and therefore forbidding) cycles when
links cross reversible scope boundaries in both directions.  There were
concerns with that proposal having to do with the complex state
semantics of non reversible scopes, nesting of isolated scopes, etc.,
which caused me to withdraw that proposal.  We continue to treat all
scopes as being reversible, but of course we cannot make all scopes
isolated.

The new proposal essentially amounts to simply separating the cycle
detection consequences of the old one and making that an explicit
restriction.  In other words, the simple way to state the proposal (at
least my intent in formulating it, modulo any mistakes I made) is that
we should treat all scopes as if they were isolated *but only for
purposes of cycle detection regarding links crossing scope boundaries*.

Proposal:

I begin with a formal restatement for Part II of the resolution of Issue 10.  I will then add some explanation.

Definition: Peer-Scopes.  Two scopes S1 and S2 are said to be peer scopes if they are both directly nested within the same parent scope (including process scope).  

Definition:  Scope-controlled set.  An activity A is within the scope-controlled set of activities of scope S if either A is S itself, or A is nested within S, at any depth.

Definition:  Peer-Scope Dependency.  If S1 and S2 are peer scopes then we say that S2 has a direct peer-scope dependency on S1 if there is an activity B within the scope-controlled set of S2 and an activity A within the scope-controlled set of S1 such that B has a control dependency on A.  The peer-scope dependency relation is the transitive closure of the direct peer-scope dependency relation.

Part II:  The peer-scope dependency relation MUST NOT include cycles.  In other words, BPEL forbids a process in which there are peer scopes S1 and S2 such that S1 has a peer-scope dependency on S2 and S2 has a peer-scope dependency on S1.

Explanation:  

The basic motivation for Part II is to make the "respect for control dependency" rule of Part I consistent with a depth-first traversal of the scope tree for default compensation.  If we can guarantee that there is a depth-first (post-order variant) traversal consistent with Part I, we no longer have any difficulty in defining default compensation of any scope, since depth-first order implies that such compensation is only dependent on the compensation of its nested scopes.  The question then reduces to constraining control paths so we can make this guarantee.  I claim that we need only concern ourselves about control dependencies between peer scopes in the sense defined above.  An example illustrates the point.
Consider the following example (taken from an earlier exchange with Alex)

<scope name="s0"> 
        <scope name="s1">
            <flow> 
                <anActivity> <source linkName="lnk1" /> </anActivity> 
                <!-- Assume that the above anActitity does not contain a 
                     scope activity -->
                <scope name="s2">
                    <target linkName="lnk1" /> 
                </scope>
            </flow>
        </scope> 
</scope> 

Does the link create a dependency between s1 and s2 that has any relevance to compensation order?  If this example is changed to

<scope name="s0"> 
        <scope name="s1">
            <flow> 
                <scope name="s7"> 
                    <source linkName="lnk1" /> 
                </scope> 
                <scope name="s2">
                    <target linkName="lnk1" /> 
                </scope>
            </flow>
        </scope> 
</scope> 

Does the situation change?  The only difference between the examples is that, whereas s1 was theoretically responsible for the compensation of the previous generic anActivity (since we assumed it does not contain a scope), it's replacement scope is an activity that is responsible for its own compensation.  But let us look further.  If we think about default compensation behavior for s1 it is going to do absolutely nothing about compensating any non-scope activities nested inside it.  Thus the fact that fact that s1 was theoretically responsible for the compensation of the generic anActivity has no consequence regarding a required ordering of compensation between s1 and s2.  Part II exploits this point and its generalization to control chains and multiply nested scopes.

Satish