Issue 2 - Proposal for discussion (first cut)

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

There is still some disagreement about the set of requirements for this issue. Nevertheless, here is a first cut of the proposal (without syntax). 

Regards,

Ivana


Motivation
===========
At the moment, the only way to reuse a piece of a BPEL code is to define it as a BPEL process and call it within another process using activity <invoke>. But, many problems arise. For example, there is no possibility to terminate the process if the calling process terminates although the invoke activity will be interrupted and terminated prematurely. The BPEL processes are primarily designed for modeling loosely coupled processes. 

Sub-processes
===============
Sub-processes: 
* Should be understood as outsourced pieces of BPEL codes that can be reused within a process or across multiple processes. They may also be long-running processes, which include interactions with other partners. 
* Can be defined locally within a single bpel process and reused only within that process, or defined as a top-level bpel process and reused across multiple bpel processes. Sub-processes may be defined directly under the <process> element, inside local scopes or as top-level processes.
* Are executed in the context in which they are defined. This means that a sub-process may "see" variables from the scope where it is defined. For example, a sub-process defined as a top-level process "sees" no variables, because it is a top-level process and there is no parent process. A sub-process defined directly under a process element "sees" only process variables but not those defined within local scopes. 
* Must have input/output parameters in order to "pass" data between calling processes and sub-processes; the data is passed by value. (Note: this decision is motivated by the fact that sharing data "by reference" introduces additional complexity (especially when a sub-process is defined as a top-level process), because we have to ensure consistent access to shared (transient) data.) So, a sub-process shares data with their parent scope(s) in addition to having explicit parameters. This is needed is cases such as following one. A sub-process C defined inside a local scope A may be called within a scope B nested inside A. In this case, sub-process C does not "see" local variables of B. Input/output parameters may be variables, partnerLinks or correlationSets.

Invoking sub-processes
=========================
Sub-processes may be called in two ways:
(1) Calling process invokes a sub-process and waits until it completes.
(2) Calling process invokes a sub-process and continues with the next step. This part needs to be extended. I envisage that we need a mechanism for sub-processes, which may run in parallel with other activities of the calling process, to signal that they completed/not completed. 

Sub-processes and fault handling
=================================
If sub-process fails and cannot recover from the failure, the fault must be propagated to the calling process.
If calling process is terminated the sub-process must be terminated as well.

Compensation and sub-processes
===============================
The idea is to equip sub-processes with the same capabilities/features as scopes. This should not be controversial for locally defined sub-processes. For sub-processes defined outside a bpel process it could be an issues. But, it could be more matter of syntax and not semantics. That means, sub-processes do not exist in isolation; they are always called by a process and may be see as part of that process.