Issue - 2- Compensation and sub-functions

Here 
is an example of how I thought compensation would work with subfunctions. Keep 
in mind that subfunctions pass parameters by reference.

 

1 
 <process name="compensateExample">

2 
   <variables>

3 
       <variable name="test" 
type="xsd:string"/>

4     </variables>

5  

6     <subfunction name="set1">

7        
<parameters>

8           <parameter 
name="astring" type="xsd:string"/>

9           
<parameter name="compvalue" type="xsd:string"/>

10        
</parameters>

11       
<compensationHandler>

12          
<assign><copy><from variable="compValue"/><to 
variable="astring"/></copy></assign>

13       
</compensationHandler>

14       <empty/>

15    </subfunction>

16

17    <sequence>

18        <function 
name="firstFunction" functionName="set1">

19           
<parameters><parameter variable="test"/><parameter 
variable="firstFunction"/></parameters>

20        
</function>

21        <scope 
name="theScope">

22           
<compensationHandler>

23              
<sequence>

24                 <compensate/>

25                 
<assign><copy><from>theScope</from><to 
variable="test"/></copy></assign>

26              
</sequence>

27          
</compensationHandler>

28           
<function name="secondFunction" functionName="set1">

29              
<parameters><parameter variable="test"/><parameter 
variable="secondFunction"/></parameters>

30           
</function>

31        
</scope>

32        <throw 
faultName="o:y"/>

33     </sequence>

34  </process>

 

When 
line 32 is reached the compensation handler structure looks 
like:

 

Root

  
|

  
-- firstFunction compensation handler

  
| 

  
-- theScope compensation handler

         |

        -- secondFunction 
compensation handler

 

Line 
32 - A fault is thrown. The fault is caught by the implicit global fault handler 
who will call compensate.

Line 
22 - theScope's compensation handler is called first.

Line 
24 - theScope's compensation handler calls compensate which triggers 
secondFunction's compensation handler.

Line 
11 - secondFunction's compensation handler sets 'astring', which is a reference 
to 'test', to 'secondFunction' & exits.

Line 
25 - theScope's compensation handler then runs and sets 'test' to 
'theScope'.

Line 
11 - Once theScope's compensation handler exits firstFunction's compensation 
handler is called and sets 'astring' (which is just a reference to 'test') 
to 'firstFunction'.

 

So 
'test' will be set, in turn, to 'secondFunction', 'theScope' and 
'firstFunction'.

 

Note, 
btw, the line 24 could have read <compensate scope="secondFunction"/> but 
I wanted to show that the subfunction compensation handlers can 
be called by the default compensate behavior.

 

        
Yaron

  
-----Original Message-----
From: Nickolas Kavantzas 
  [mailto:]
Sent: Wednesday, October 29, 
  2003 4:06 PM
To: 
Cc: 'Trickovic, Ivana'; 
  ; ; ; 
  'Liu, Kevin'
Subject: Re: [wsbpel] Issue - 2- requirements for a sub 
  function solution

Yaron, 
  
By reading your requirements below, it seems to me that there is another 
  requirement: 
  "BPEL4WS MUST add input and output parameters to 
  compensation handlers". 
  
Yaron Goland wrote: 
  Here is my view on what the requirements are for a 
    solution to Issue 2. 
    
Terminology: 
    
Host - This is the process that called the sub-function. 
    
Requirements: 
    
Integration into host fault/compensation model - The sub-function MUST be 
    
able to throw faults that will propagate to the host. The host MUST be able 
to call 
    compensation handlers defined in the sub-function. 
    
Functional Programming - One of the key concepts of functional 
    programming 
is the idea of isolation. Functions in 
    functional programming systems are 
expected 
    to be able to run in their own context and to only have contact 
    
with the host context through explicit value passing. 
    The sub-function 
solution MUST enable for 
    isolation. 
    
Human Usable - It MUST be reasonably easy for a programmer to read/write 
    
sub-function definitions and calls without requiring the aid of a tool. 
    
By Reference - Messages seem only to get larger with multi-megabyte XML 
    
messages now commonly seen. Therefore when passing data into a 
    sub-function 
it is critical that it be possible to hand over the data by 
    reference so 
that the data does not have to be copied on its way in or 
    out. 
    
Use in Expressions - It MUST be possible to call a sub-function anywhere 
    one 
could call a XPATH or other type of general/query/date expression 
    and have 
the sub-function return the desired value. 
    
Import - A mechanism is needed to allow sub-functions to be defined in 
    stand 
alone files which can then be referenced by multiple BPEL 
    processes. 
    
> -----Original Message----- 
> From: Trickovic, Ivana [mailto:] 
    
> Sent: Wednesday, October 29, 2003 5:22 AM 
> To: 
    '' 
> Cc: ''; 
    ''; Liu, Kevin 
> Subject: Re: [wsbpel] Issue - 2- 
    sub functions 
> 
> 
> We should be able to reuse pieces 
    of BPEL code within a 
> single process or across multiple processes. 
    The question is 
> how these reusable pieces of BPEL code should be 
    modeled and 
> integrated in the calling processes. 
> 
> 
    It seems that one idea would be to model reusable parts of 
> BPEL 
    code (sub-processes) as BPEL processes. As Bernd 
> suggested some 
    time ago, one way or two-way <bpel:invoke>s 
> can be used for 
    asynchronous and synchronous calls, 
> respectively, and the 
    specification could also give a 
> recommendation how to differentiate 
    between internal and 
> external process ports. If we take that 
    approach, we also 
> have to review consequences for the control flow, 
    especially 
> compensation and error handling. Satish pointed out that 
    the 
> BPEL specification includes as its integral part the BA 
    
> protocol defined in the WS-Transaction specification. This 
> 
    protocol specifies the parent-child relationship between 
> scopes. 
    But, BPEL usage of the BA protocol makes the 
> assumption of 
    localized behavior in a single service. If we 
> model sub-processes 
    as BPEL processes and use the invoke 
> action as mentioned above, we 
    do not have localized behavior 
> in a single service anymore. So, 
    what is missing in BPEL is 
> the semanti! 
> cs! 
>  
    for compensation and error handling. It cannot be that for 
> the 
    sub-processes protocols such as 
> WS-Coordination/WS-Transaction are 
    needed. This semantics 
> must be an integral part of the language. 
    
> 
> Also, sub-processes will be modeled as partners, which is 
    
> misleading from the modeling point of view and at the end the 
    
> process model will be overloaded with partner link 
> 
    definitions (partner links will be used extensively). I 
> believe 
    this is also an area where some simplifications 
> should be made. 
    
> 
> Kind regards, 
> 
> Ivana 
> 
> 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. 
    
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.