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


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


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