[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] RE: Issue - 10 - Satish's Strawman
My proposal is only slightly more nuanced than what you describe. I propose that the compensation rules be: IF a BPEL process meets the no circularity rules you describe in your 6/19/2004 proposal THEN compensation MUST occur in depth first order with respect for links. IF a BPEL process does not meet the no circularity rules you describe THEN compensation occurs as you summarized in your mail immediately below this text. Thanks, Yaron Satish Thatte wrote: > I am certainly not the expert on link behavior. People with much deeper > experience in that model probably have strongly founded arguments about > your proposal. The gist of your proposal as I understand it is that we > make no restrictions like the ones I proposed and that the default > compensation behavior should be depth-first, reverse completion, > parallelism allowed. This amounts to closing issue 10 with no change to > the spec except for clarifying that parallelism is allowed. The fact > that link order may be taken into account becomes a vendor specific > implementation choice. Do note that in some cases, enforcing depth > first and reverse completion make it impossible to respect link order. > This was the motivation for the proposed restrictions in the first > place. > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Tuesday, August 24, 2004 11:40 AM > To: Satish Thatte > Cc: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] RE: Issue - 10 - Satish's Strawman > > I must admit that I'm no fan of links. I suspect they will generally > cause more harm than value. But if we are to have links in the spec then > > they should probably work somewhat like people would expect. The > restrictions that issue 10 seems to require would prevent some extremely > > common link patterns such as 1/2 and full diamonds. [1] > > Furthermore I challenge any programmer to really understand these > restrictions well enough to create links in non-trivial cases that don't > > violate them. We will need a lot of tool support to make this work. > > I suspect that perhaps our simplest strategy is to remove all of these > restrictions and specify that the default compensation behavior should > be depth-first, reverse completion, parallelism allowed and while the > engine MAY take into consideration link order it is not required to be > bound by it. We can even go further and specify that if links have the > behaviors you describe below, e.g. acyclic, then they MUST be executed > with respect to the link order. > > This means that the wrong thing could happen if someone has cyclic > links. In that case the programmer will need to write their own custom > compensation handlers. But hey, easy things should be easy (acyclic > dependencies) and hard things should be possible (cyclic dependencies). > > Just a thought, > > Yaron > > [1] The example I gave in my e-mail below is a 1/2 diamond. A Full > diamond looks like: > Execution Flow > Scope A | > / \ | > Scope B Scope C | > \ / | > Scope A \_/ > > Satish Thatte wrote: > > >>The analysis is correct. Thanks for taking the trouble to construct > > the > >>example! >> >>The derivative point is that if this process were allowed, the default >>reversal behavior of the process would not be able to operate in a >>depth-first manner because of Part I of the resolution of Issue 10 >>(which we have accepted). The reason is that in order to respect >>forward control paths as mandated by Part I, the compensation of > > Execute > >>must precede the compensation of PrepStartProcess and the compensation >>of CloseProcess must follow the compensation of Execute, thus the >>default compensation of A must be interleaved with the compensation of >>its peer scope execute. The aim of the proposal is to avoid such >>required interleaving, so that the default compensation of any scope > > can > >>be seen as a self-contained unit in a default compensation regime, and >>therefore has a simple consistent semantics. In other words, the > > point > >>of ensuring consistency with depth-first order is to make sure the >>semantics of default compensation for any (non-isolated) scope is >>well-defined regardless of links crossing its boundaries. >> >>A related point is also worth pointing out. The original resolution > > of > >>Issue 10 made the claim that the compensation order mandated by the >>resolution was consistent with strict reverse order of completion. > > That > >>is still true but not in depth-first order. For example, eliminate > > the > >>link ExecuteToClose in the example below. Now Execute has a > > peer-scope > >>dependency on A but it is nevertheless impossible to tell whether >>Execute or A will complete first. In other words, strict reverse > > order > >>of completion applied to compensation of all scopes may still require >>interleaving of the kind mentioned above even with the strawman >>proposal. >> >>Thus, with the strawman proposal, I believe there would be several >>permitted implementation modes: >> >>1. Do the peer-scope dependency analysis and run compensation in >>depth-first order using reversed peer-scope dependency for control > > flow > >>(but this is not necessarily in strictly reverse order of completion) >> >>2. Simply "reverse the control edges" and run compensation > > concurrently > >>respecting reversed control edges >> >>3. Strict reverse order of completion (with interleaving as in the >>above example if necessary) >> >>Where 3 is a special case of 2 in some sense. >> >>Hope that helps :-) >> >>Satish >> >>-----Original Message----- >>From: Yaron Y. Goland [mailto:ygoland@bea.com] >>Sent: Thursday, August 19, 2004 9:42 AM >>To: Satish Thatte >>Cc: wsbpel@lists.oasis-open.org >>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 >>> >>> >>> >>> >>> >>> >>> >> >> >>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_workgr > oup.php. > >>From - Tue > > > 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]