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: Issue 10 - Proposal to vote


this made the scripts revert the status of issue 10 from resolved to "resolution proposed". Since a second vote is being proposed, I've left that as the status and renamed the "Resolution" as "Original resolution", with a bit of explaining text.

Peter

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com] 
> Sent: 08 September 2004 21:24
> To: wsbpeltc
> Cc: Furniss, Peter
> Subject: Issue 10 - Proposal to vote
> 
> 
> Playing both sides of Peter's subject-line script -- haven't 
> done this for a while ..
> 
> -----Original Message-----
> 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 the strawman I posted some time ago.
> 
> Starting point:   
> 
> Recall that at one point I had suggested that we make 
> "reversibility" an explicit attribute of scopes and require 
> that all reversible scopes are also isolated.  This would 
> have solved the problem of default compensation order by 
> creating (and therefore forbidding) cycles when links cross 
> reversible scope boundaries in both directions.  There were 
> 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.  We 
> 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.  In other words, the simple way to 
> state the proposal (at 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 Issue 10.  I will then add some explanation.
> 
> 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.
> 
> 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 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.  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 of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]