Re: [wsbpel] Issue 3 - Proposal to vote

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

Satish,
    I just wanted to spell it out more clearly using these examples.
Thanks,
- Aniruddha

Satish Thatte wrote:

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