[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 10 - Satish's Strawman
Hi, AFAIU, your conclusion is right. The BPEL example you mentioned is illegal. Of course, Satish would confirm further. :-) A reminder of the context of this proposal: we want to have a well-defined compensation order among peer scopes for the default compensation of the parent scope. The no-cycle restriction makes sure that there is a partial-ordering among all the peer scopes. And, the compensation order would respect the reverse of the partial-order. Thanks! Regards, Alex Yiu Yaron Y. Goland wrote: > 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 >> >> >> >> >> >> >> > > 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]