RE: [wsbpel] Issue 3 - Proposal to vote

["Satish Thatte" <satisht@microsoft.com>]

Aniruddha,

Did you have a clarification in mind related to your examples?  The
details seem right to the extent I parsed them.

Satish

-----Original Message-----
From: Aniruddha Thakur [mailto:aniruddha.thakur@oracle.com] 
Sent: Tuesday, October 28, 2003 4:01 PM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 3 - Proposal to vote

Satish,
I support the current stack proposal for issue #3. There is couple of 
details that I think may need clarification regarding the interpretation

of current states. Let's say that we have three scopes Scope-1, Scope-2,

and Scope-3 that are nested. Each scope has a variable defined V-1, V-2,

and V-3 respectively. Each scope has a fault handler (FH-1, FH-2, FH-3) 
and a compensation handler (CH-1, CH-2, CH-3).

Scope-1 that has (V-1, FH-1, CH-1) defined
|...
|--Scope-2 that has (V-2, FH-2, CH-2) defined
| |...
| |--Scope-3 that has (V-3, FH-3, CH-3) defined
| |...
| |--/Scope-3
|...
|--/Scope-2
|...
|--FH-1

Say now, the following sequence happens (assume t5 > t4 > ...> t0)
*At t0:* Scope-3 completes successfully and registers CH-3 with (V-3) =
(3)
*At t1:* Scope-2 finishes successfully and CH-2 is registered with (V-2)

= (2)
*At t2:* A subsequent activity in Scope-1 fails which instantiates FH-1 
with (V-1) = (1)
*At t3:* FH-1 modifies (V-1) to (4) and then invokes CH-2
*At t4:* CH-2 is invoked with (V-1, V-2) = (4, 2)
CH-2 modifies (V-1, V-2) to (5, 6) and then invokes CH-3
*At t5:* CH-3 is invoked with (V-1, V-2, V-3) = (5, 6, 3)
CH-3 could modify V-1 to 0 which will be the final state of execution of

the sequence (FH-1->CH-2->CH-3).

*Another Point (**variable-name overloading):*

**

On page#41 of BPEL4WS specification it states "The name of a variable 
should be unique within it's scope. If a local variable has the same 
name and same messageType/type/element as a variable defined in an 
enclosing scope, the local variable will be used in local assignments 
and/or getVariableProperty functions." Thus, local variable can have the

same name as that in it's enclosing scope-if this statement is true then

in the above example if V-3 were to be re-named to be V-2 then the 
sequence would look as follows:
(assume t5 > t4 > ...> t0)
*At t0:* Scope-3 completes successfully and registers CH-3 with (V-2) =
(3)
*At t1:* Scope-2 finishes successfully and CH-2 is registered with (V-2)

= (2)
*At t2:* A subsequent activity in Scope-1 fails which instantiates FH-1 
with (V-1) = (1)
*At t3:* FH-1 modifies (V-1) to (4) and then invokes CH-2
*At t4:* CH-2 is invoked with (V-1, V-2) = (4, 2)
CH-2 modifies (V-1, V-2) to (5, 6) and then invokes CH-3
*At t5:* CH-3 is invoked with (V-1, V-2) = (5, 3)
CH-3 could modify V-1 to 0 which will be the final state of execution of

the sequence (FH-1->CH-2->CH-3).

*Final Point (**Parallel scopes and common Variable):
*Assume in the above example there was a flow activity inside Scope-1 
and one adds a parallel Scope-4 to Scope-2 as follows:
Scope-1 that has (V-1, FH-1, CH-1) defined
|--Flow
| |--Scope-2 that has (V-2, FH-2, CH-2) defined
| | |...
| | |--Scope-3 that has (V-3, FH-3, CH-3) defined
| | |...
| | |--/Scope-3
| |...
| |--*FH-2*
| |--/Scope-2
| |
| |--Scope-4 that has (V-4, FH-4, CH-4) defined
| | |...*Some activity that Modifies V-1*
| |--/Scope-4
|--/Flow

Assume the following Sequence (assume t3 > t2 > t1> t0 And for t4, t3 
relationship see below):
*At t0:* Scope-3 completes successfully and registers CH-3 with (V-3) =
(3)
*At t1:* A subsequent activity in Scope-2 fails which instantiates FH-2 
with (V-1, V-2) = (1, 2)
*At t2:* FH-2 modifies (V-1) to (4) and then invokes CH-3
*At t3:* One of the activities in Scope-4 also modifies V-1 to a value
of 5
*At t4:* If (t4 > t3) when CH-3 is invoked then (V-1, V-2, V-3) = (5, 2,
3)
If (t4 < t3) when CH-3 is invoked then (V-1, V-2, V-3) = (4, 2, 3)
So, depending on the time when CH-3 is invoked there could be a 
different invocation pattern.

Thanks,
- Aniruddha


Satish Thatte wrote:

>The proposed resolution of Issue#3 overrides the semantics of variable
usage in compensation handlers as described in Section 13.3.1.   The
discussion thread associated with this issue is also worth reading for
background.
>
>BPEL currently specifies that a compensation handler lives in a
snapshot world in which the state of the associated scope and all
enclosing scopes has been preserved as it was when the associated scope
completed. The handler is able to assign new values to the variables
visible to it in all scopes, but the assignment affects only the
snapshot.  The specification further anticipates Issue#3 and a potential
resolution 
>
>"It is not realistic to expect compensation activities to always be
oblivious to the current state of the world. In fact, compensation both
affects and is affected by the current state. However, the shape of the
world within which compensation is run is difficult to anticipate. It is
therefore necessary to allow the two-way interaction between
compensation activities and the live world to take place in a tightly
controlled manner. In the future, BPEL4WS will add input and output
parameters to compensation handlers for this purpose."
>
>The proposal stated here is to eliminate the notion of a snapshot world
from the semantics of the relationship between compensation handlers and
variable state (including the state of partnerLinks).  This addresses
Issue#3 without the use of parameters.  The relevant text in Section
13.3.1 would be replaced with the following (the picture would also be
included in the specification)
>
>Compensation handlers always interact with the current state of the
process, specifically the state of variables declared in their
associated scope and all enclosing scopes.  The variables include
partnerLinks at the process scope.  Compensation handlers are able to
both get and set the values of all such variables.  Other parts of the
process will see the changes made to shared variables by compensation
handlers, and conversely, compensation handlers will see changes made to
shared variables by other parts of the process, including situations
where a compensation handler runs concurrently with other parts of the
process.  Compensation handlers will need to use serializable scopes
when they touch state in enclosing scopes to avoid interference.
>
>The current state of the process consists of the current local state of
all scopes that have been started.  This includes scopes that have
completed but for which the associated compensation handler has not been
invoked.  For completed uncompensated scopes their current local state
is the state as it was at the time of completion. Such scopes are in
suspended animation because their compensation handlers are still
available and therefore their execution may continue in compensation
mode.  Note that a scope may have been executed several times in a loop,
and the current state of the process includes the state of each
completed (and uncompensated) iteration through the scope.  
>
>The behavior of a compensation handler can be thought of as an optional
continuation of the behavior of the associated scope and as such its
usage of variables is similar to the usage that occurred in the body of
the scope itself, including update actions.   This includes variables in
both the local scope and all enclosing scopes.  Note that the
compensation handler may itself have been called from an enclosing
compensation handler.  It will then share the continuation of the state
of the enclosing scope that its caller is using.  In the attached
picture showing three nested scopes S1, S2 and S3, and their
compensation handlers C1, C2, C3, and failure handlers F1 and  F2, we
may have an error handling call stack F1->C2->C3.  In that case C3 will
share the state of S2 as it is being seen and used by C2.
>
>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.
>