[no subject]

Especially, according to our understanding, further properties of scope=
s
have no additional impact on the underlying (graph-) structure of the
process.

Kind Regards
DK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

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 t=
he
strawman I posted some time ago.

Starting point:

Recall that at one point I had suggested that we make "reversibility" a=
n
explicit attribute of scopes and require that all reversible scopes are=

also isolated. =A0This would have solved the problem of default
compensation order by creating (and therefore forbidding) cycles when
links cross reversible scope boundaries in both directions. =A0There we=
re
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. =A0We 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. =A0In other words, the simple way to state the proposal (a=
t
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 Issu=
e
10.=A0 I will then add some explanation.

Definition: Peer-Scopes.=A0 Two scopes S1 and S2 are said to be peer sc=
opes
if they are both directly nested within the same parent scope (includin=
g
process scope).

Definition:=A0 Scope-controlled set.=A0 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:=A0 Peer-Scope Dependency.=A0 If S1 and S2 are peer scopes t=
hen 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 with=
in
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 dir=
ect
peer-scope dependency relation.

Part II:=A0 The peer-scope dependency relation MUST NOT include cycles.=
=A0 In
other words, BPEL forbids a process in which there are peer scopes S1 a=
nd
S2 such that S1 has a peer-scope dependency on S2 and S2 has a peer-sco=
pe
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 t=
he
scope tree for default compensation.=A0 If we can guarantee that there =
is a
depth-first (post-order variant) traversal consistent with Part I, we n=
o
longer have any difficulty in defining default compensation of any scop=
e,
since depth-first order implies that such compensation is only dependen=
t on
the compensation of its nested scopes.=A0 The question then reduces to
constraining control paths so we can make this guarantee.=A0 I claim th=
at we
need only concern ourselves about control dependencies between peer sco=
pes
in the sense defined above.=A0 An example illustrates the point.
Consider the following example (taken from an earlier exchange with Ale=
x)

<scope name=3D"s0"> =00=A0=A0=A0 =A0=A0=A0 <scope name=3D"s1">=00
<flow> =00=A0=A0=A0 =A0=A0=A0 =A0=A0 =A0=A0 =A0 <anActivity> <source li=
nkName=3D"lnk1" />
</anActivity> =00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <!-- Ass=
ume that the above anActitity does
not contain a =0D=20                    scope activity -->
=A0=A0=A0 =A0=A0 =A0 =A0 =A0 =A0=A0 <scope name=3D"s2">=00=A0=A0=A0 =A0=
=A0 =A0=A0=A0=A0 =A0 =A0=A0 =A0=A0 <target
linkName=3D"lnk1" /> =00=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </scope=
>=00=A0=A0=A0 =A0=A0 =A0=A0 =A0 </flow>=00
</scope>
</scope>

Does the link create a dependency between s1 and s2 that has any releva=
nce
to compensation order?=A0 If this example is changed to

<scope name=3D"s0"> =00=A0=A0=A0 =A0=A0=A0 <scope name=3D"s1">=00
<flow> =00=A0=A0=A0 =A0=A0=A0 =A0=A0 =A0=A0 =A0 <scope name=3D"s7"> =00=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <source
linkName=3D"lnk1" /> =00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <=
/scope> =00=A0=A0=A0 =A0=A0 =A0 =A0 =A0 =A0=A0 <scope
name=3D"s2">=00=A0=A0=A0 =A0=A0 =A0=A0=A0=A0 =A0 =A0=A0 =A0=A0 <target =
linkName=3D"lnk1" /> =00
</scope>=00=A0=A0=A0 =A0=A0 =A0=A0 =A0 </flow>=00=A0=A0=A0 =A0=A0=A0 </=
scope>
</scope>

Does the situation change?=A0 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 sco=
pe),
it's replacement scope is an activity that is responsible for its own
compensation.=A0 But let us look further.=A0 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.=A0 Thus the fac=
t 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.=A0 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 o=
f
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg=
roup.php
.


To unsubscribe from this mailing list (and be removed from the roster o=
f
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg=
roup.php
.

=