[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Especially, according to our understanding, further properties of scope= s have no additional impact on the underlying (graph-) structure of the process. Kind Regards DK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= 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 t= he strawman I posted some time ago. Starting point: Recall that at one point I had suggested that we make "reversibility" a= n explicit attribute of scopes and require that all reversible scopes are= also isolated. =A0This would have solved the problem of default compensation order by creating (and therefore forbidding) cycles when links cross reversible scope boundaries in both directions. =A0There we= re 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. =A0We 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. =A0In other words, the simple way to state the proposal (a= t 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 Issu= e 10.=A0 I will then add some explanation. Definition: Peer-Scopes.=A0 Two scopes S1 and S2 are said to be peer sc= opes if they are both directly nested within the same parent scope (includin= g process scope). Definition:=A0 Scope-controlled set.=A0 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:=A0 Peer-Scope Dependency.=A0 If S1 and S2 are peer scopes t= hen 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 with= in 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 dir= ect peer-scope dependency relation. Part II:=A0 The peer-scope dependency relation MUST NOT include cycles.= =A0 In other words, BPEL forbids a process in which there are peer scopes S1 a= nd S2 such that S1 has a peer-scope dependency on S2 and S2 has a peer-sco= pe 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 t= he scope tree for default compensation.=A0 If we can guarantee that there = is a depth-first (post-order variant) traversal consistent with Part I, we n= o longer have any difficulty in defining default compensation of any scop= e, since depth-first order implies that such compensation is only dependen= t on the compensation of its nested scopes.=A0 The question then reduces to constraining control paths so we can make this guarantee.=A0 I claim th= at we need only concern ourselves about control dependencies between peer sco= pes in the sense defined above.=A0 An example illustrates the point. Consider the following example (taken from an earlier exchange with Ale= x) <scope name=3D"s0"> =00=A0=A0=A0 =A0=A0=A0 <scope name=3D"s1">=00 <flow> =00=A0=A0=A0 =A0=A0=A0 =A0=A0 =A0=A0 =A0 <anActivity> <source li= nkName=3D"lnk1" /> </anActivity> =00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <!-- Ass= ume that the above anActitity does not contain a =0D=20 scope activity --> =A0=A0=A0 =A0=A0 =A0 =A0 =A0 =A0=A0 <scope name=3D"s2">=00=A0=A0=A0 =A0= =A0 =A0=A0=A0=A0 =A0 =A0=A0 =A0=A0 <target linkName=3D"lnk1" /> =00=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </scope= >=00=A0=A0=A0 =A0=A0 =A0=A0 =A0 </flow>=00 </scope> </scope> Does the link create a dependency between s1 and s2 that has any releva= nce to compensation order?=A0 If this example is changed to <scope name=3D"s0"> =00=A0=A0=A0 =A0=A0=A0 <scope name=3D"s1">=00 <flow> =00=A0=A0=A0 =A0=A0=A0 =A0=A0 =A0=A0 =A0 <scope name=3D"s7"> =00= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <source linkName=3D"lnk1" /> =00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /scope> =00=A0=A0=A0 =A0=A0 =A0 =A0 =A0 =A0=A0 <scope name=3D"s2">=00=A0=A0=A0 =A0=A0 =A0=A0=A0=A0 =A0 =A0=A0 =A0=A0 <target = linkName=3D"lnk1" /> =00 </scope>=00=A0=A0=A0 =A0=A0 =A0=A0 =A0 </flow>=00=A0=A0=A0 =A0=A0=A0 </= scope> </scope> Does the situation change?=A0 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 sco= pe), it's replacement scope is an activity that is responsible for its own compensation.=A0 But let us look further.=A0 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.=A0 Thus the fac= t 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.=A0 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 o= f the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg= roup.php . To unsubscribe from this mailing list (and be removed from the roster o= f the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg= roup.php . =
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]