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