[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 10 - Satish's Strawman
Satish, I'm not sure I fully understand what you are proposing. I give an example BPEL below and try to analyze it using the proposed rules as I understand them. I would appreciate it if you could confirm if I got it right. If I didn't get it right I'd appreciate it if you could explain where I went wrong. EXAMPLE: process flow links link PrepToExecute link ExecuteToClose scope name="A" sequence ... scope name="PrepStartProcess" sources source linkname="PrepToExecute" ... ... scope name="CloseProcess" targets target name="ExecuteToClose" ... ... scope name="Execute" targets target name="PrepToExecute" sources source name="ExecuteToClose" ... ANALYSIS: Scope A and Scope Execute are peer scopes because they share the same parent scope, Process. PrepStartProcess and CloseProcess are within the scope controlled set of scope A Execute is within the scope controlled set of Execute Scope Execute has a direct peer scope dependency on Scope A because Scope Execute has a control dependency on Scope PrepStartProcess and PrepStartProcess is in the scope controlled set of Scope A and Scope A is a peer scope to scope Execute. Scope A has a direct peer scope dependency on Scope Execute because Scope CloseProcess has a control dependency on Scope Execute and CloseProcess is in the scope controlled set of Scope A and Scope A is a peer scope to scope Execute. CONCLUSION: The example BPEL is illegal because A has a peer scope dependency on Scope Execute and scope Execute has a peer scope dependency on scope A thus causing a cycle. Is the analysis correct? Thanks, Yaron Satish Thatte wrote: > > > I begin with a strawman for Part II of the resolution of Issue 10. I > will then add some rationale. I haven’t written down an actual theorem > and proof, but see what you think . I am especially interested in > counter-examples that show this to be broken for the claim that the > restriction articulated here makes default compensation order consistent > with depth-first traversal. > > * My current strawman for Part II: * > > 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. > > * Rationale: * > > 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. The strawma n > attempts to exploit this claimed insight and its generalization to > control - chains and multiply - nested scopes. > > Of course the proof of the pudding is in the (absence of) counter > examples J > > Satish > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]