OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]