Issue - 2- Compensation and sub-functions

["Yaron Goland" <ygoland@bea.com>]

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:nickolas.kavantzas@oracle.com]
Sent: Wednesday, October 29, 2003 4:06 PM
To: ygoland@bea.com
Cc: 'Trickovic, Ivana'; wsbpel@lists.oasis-open.org; B.Eckenfels@seeburger.de; arkin@intalio.com; '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:ivana.trickovic@sap.com]
> Sent: Wednesday, October 29, 2003 5:22 AM
> To: 'wsbpel@lists.oasis-open.org'
> Cc: 'B.Eckenfels@seeburger.de'; 'arkin@intalio.com'; 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.