[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 10 - Proposal to vote
this made the scripts revert the status of issue 10 from resolved to "resolution proposed". Since a second vote is being proposed, I've left that as the status and renamed the "Resolution" as "Original resolution", with a bit of explaining text. Peter > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: 08 September 2004 21:24 > To: wsbpeltc > Cc: Furniss, Peter > Subject: Issue 10 - Proposal to vote > > > Playing both sides of Peter's subject-line script -- haven't > done this for a while .. > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Wednesday, September 08, 2004 1:21 PM > To: wsbpeltc > Subject: [wsbpel] Proposal to vote - Issue 10 > > 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 > > 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/le > ave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]