Re: [wsbpel] Issue 3 - Proposal to vote

[Aniruddha Thakur <aniruddha.thakur@oracle.com>]

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_workgroup.php.
>