The interaction behavior between processes of organizations and their suppliers can be modeled by using choreographies. When an organization decides to gain more control about their suppliers and to minimize transaction costs they may decide to insource these companies. This also requires the integration of the partner processes into the organization. In previous work we proposed an approach to merge (consolidate) interacting BPEL process models of different partners into a single process model by deriving control flow links between the process models from their interaction specification. In this work we are detailing this consolidation approach. Thereby, special attention is turned on extending the consolidation operations in a way that process models with fault handlers can be merged.
To reduce transaction costs or to gain more control companies often decide to integrate suppliers into their organization (in-sourcing, mergers, and acquisitions). This requires the integration of the processes and the organizational structure of the two companies. In this work we focus on the integration on the process-level. More precisely, we want to merge (or consolidate) complementing process models whose interaction behavior is described by a choreography.
Process modeling languages such as BPEL [
We use BPEL4Chor [
We assume that the reader is familiar with BPEL. Nevertheless, we give a brief overview about BPEL’s fault handling concepts in Sect. 2. In Sect. 3 an overview on the merge operations is provided and extensions to them are discussed. Then, Sect. 4 presents a technique to merge processes that communicate via BPEL fault handlers. After discussing related work in Sect. 5, Sect. 6 concludes this paper and provides an outlook on future work.
BPEL offers three language constructs to repair faulty situations during process execution, namely fault handlers, compensation handlers and termination handlers. If a fault occurs within a scope all running activities within this scope are terminated and its fault handlers are called. A fault handler is represented by a catch or catchAll block. Thereby, multiple catch blocks can be defined for a scope. Each catch block catches a particular fault that may be thrown during execution of the scope and contains BPEL activities to handle this fault. A catchAll block contains logic to catch all other faults that do not match to a particular catch block. If no explicit fault handlers are defined for a scope it has an implicit default fault handler attached to it. If any kind of fault occurs during the execution of the scope the default fault handler triggers compensation handling for its child scopes (see below) and finally rethrows the fault to its parent scope. If this scope does not provide a fault handler for this fault either, it is propagated up to its parent scope and so on until the process scope is reached. If the process scope cannot catch the fault the process fails and is terminated.
Compensation handlers contain activities to undo work that was successfully performed by a scope they are attached to, e. g., canceling a flight that was booked by the activities of the scope. Hence, they are only executed if their associated scope has completed successfully.
To control the termination of a scope that is still running a termination handler can be
attached to it. Within the termination handler activities can be defined that are performed
before the actual termination of the scope. If no explicit termination handler was defined
for a scope its default termination handler compensates its child scopes. A more detailed
discussion about fault and compensation handling concepts in BPEL was provided by
Khalaf et al. [
Asynchronous Merge 3
We introduced the consolidation op- Process A Process B Process Pmerged icenhrar[to1ino3on]us.sTtochomemeamrimguenoaicfsayttnhinceghcrpoornnosocouelssidsaamntdioodsnyenilss- Odpae•fqS:uvein Odp•eaRfq:Cuverc deS•fS:AvindeRfo:ovtrc •SRBC tphhaaavrtteitchtihpeeaantstoasmminiecthcaeocntmitvreiotrilgeeflsdoowpfrtorhceeelasdtsiifomfneosredanestl IvninvS→So•kme m RemcRR→eCCi•vvrce AOvspSinsaY→iqNguvSrnec anOdEpSmYapNqtRuCye in the original choreography. The basic Opaque Opaque S• RC• idea behind the consolidation algorithm is OSpCaOqPuEe OSpCaOqPuEe that the message links imply control flow Flow relations between the activities of the com- Choreography CAB Merged Process Model municating process models. The message Figure 1. Asynchronous Merging Operation link m in Fig. 1 implies for instance that the successor RC of the receive activity is always performed after the predecessor activity S of the invoke activity S in process model A as RC cannot be performed before S completed. However, no statement can be made about the execution sequence between S and RC , e. g., if they have to be performed simultaneously or if S is performed before RC and so on. This is different from the synchronous scenario depicted in Fig. 2. There RC is always performed before S . As activity S does not complete until it received a response message from RP that is performed after RC . Given these implicit control flow dependencies, the sending and receiving activities can act as merge points. Therefore the consolidation operation materializes the implicit control flow to explicit control flow relations between the activities.
The consolidation algorithm to merge an arbitrary number of process models is
described in the following. As a prerequisite we assume that the choreography is modeled
correctly [
In a first step a new process model Pmerged is created that contains a flow as root activity. For each of the process models P1 to Pn to be merged a separate scope is created in the flow activity of Pmerged. This ensures that the scope activities are performed simultaneously. Each scope contains the root activity (along with its child activities) of one of the process models P1 to Pn. The purpose of the scope is to isolate the activities of the process models from each other as they were also isolated in the original choreography. To avoid that an uncaught fault thrown in one scope causes the other scope to crash (as uncaught faults are propagated up to the process scope) a catchAll fault handler is added to the scopes as shown in Fig. 2. The catchAll contains a compensate activity to emulate the default compensation that would have been triggered in an original process without an explicit fault handler. In case an explicit fault handler was defined in a catchAll block on the original process scope nothing is changed. If a process scope of a process to be merged has already a a catch block defined simply the catchAll block is added to this fault handler.
Then the message links are materialized to control flow links. In the asynchronous
case the invoke activity S is replaced by an assign activity SY NS and the receive
activity RC by an empty activity SY NRC. SY NS emulates the message transfer between
between the former invoke and receive activity, i. e., it copies the message from the
input variable vs of the invoke to the variable vrc of the receive activity where the
message was copied to before. To perform the assignment the declaration of variable
vrc is lifted to the parent scope that encloses the two scopes that contain the participant
activities. Otherwise, SY NS could not access vrc. The empty activity SY NRC replaces
the former receive RC. To avoid name clashes between variables it might be necessary
to adapt the variable names accordingly during the consolidation. The incoming and
outgoing links of S and RC are mapped to SY NS and SY NRC, respectively. An additional
link from SY NS to SY NRC is created. This link ensures that SY NRC is not started before
SY NS was executed.
1 Static Analysis (SA) Fault Codes defined in the BPEL specification [
Process A
The synchronous merge is sketched in5 Fig. 2. There additionally the reply activity © Sebastian Wagner RP is replaced by the reply activity SY NRP to emulate the transfer of the response message sent via message link m0. SY NRP copies the value of the former reply variable vrp to the output variable of the former invoke activity vout. The declaration of vout has to be lifted to the parent scope as well to make this variable accessible for SY NRP. The empty activity SY NSR is added for the same reason SY NRC was added. The control links of RC are mapped to SY NRP and the outbound links of S are mapped to SY NRC. Moreover, a new link is created to connect SY NS and SY NSR and another one between SY NRP and SY NSR to ensure that the successors of the former invoke activity are not started before. 4
In this section we discuss the challenges that arise when materializing the control flow from message links between communication activities that reside within BPEL fault handlers. Thereby, we focus on the cross boundary link constraint imposed by the BPEL specification [SA00071]. This constraint specifies that no control link must point to a target activity within a fault handler from outside the fault handler, i. e., no link must point into a catch or catchAll block.
In the following we distinguish between three different scenarios (i) fault handlers without communicating activities (ii) fault handlers with only outgoing message links and (iii) fault handlers with at least one incoming message link.
The first scenario is trivial as there is no communication between the fault handlers of the two process models that have to be merged. Consequently, they can be simply merged with the consolidation operations introduced in 3.
The second is scenario is depicted in Fig. 3. In process model A the fault handler F HA is attached to the scope SA. F HA contains an asynchronous invoke activity A4 that is related to the corresponding receive activity B2 in process model B via message
Scenario 2: FHs with Outbound Links link m. Note, that for simplicity reasons the flow activity containing SA and SB is not explicitly depicted in Fig. 3 and in the following figures.
Process A
To merge the process models in a first step the merge operations introduced in Sect. 3 are apCplhieodre.oTghriasprehsyuCltAsBin process model Pmerged. As the new control flow links materialized from the message links leave the fault handler boundaries outbound only, the cross boundary link constraint is not violated.
T© hSeebasstiacneWnaganerrio in Fig. 4 is very similar to the prev7ious one except that invoke activity A4 is synchronous, hence, a second message link from the reply activity points back StocAe4n.Tahreisoync3h:roFnoHusscownsolidation operantiodn createkssfrom the message link m2 the ith Inbou Lin control flow link l2. This link crosses the fault handler boundary of F HA inbound in order to realize that A5 is performed after B2 or B3 respectively. This violates the cross boundary link constraint.
SA def: vin …
A1 Opaque
A2 Opaque …
FHA def: vout def: va
A3
A4 Ininv→omke vm2 →vou1t A5 Opaque Flow m1
def: vrc def: vrp
SB …
B1 Receive
B2 Opaque
B3 Reply vrp → m2 … Scenario 3: FHs with Inbound Links - Solution Process Pmerged
def: va SFH def: vin
A8 SA …
A1 Opaque
A2 Opaque …
Flow
FHA A7 Empty A3
A4 Avsins→igvrnc
A6 Em^pty
A5 Opaque Flow l1 l2
To develop a solution to overcome this problem control flow links pointing into a fault handler have to be avoided, hence, the control flow has to be modified accordingly.
To resolve the incoming link issue we can either remove the fault handler completely or we move the activities with incoming links out of fault handler. Removing the fault handler completely is not an option as a fault handler can be activated any time during runtime of a scope if a fault is thrown. This behavior cannot be emulated by using other BPEL constructs. Hence, we suggest a solution where the fault handler is kept and the fault handling activities are factored out of it. usually happens immediately after SA was completed) and SFH terminated due to an error in its parent scope the default termination handler compensates all successfully executed child scopes of SFH. In case a fault is thrown during the execution of the fault handler FHA this fault is simply thrown to its parent scope. Also this behavior is kept as SFH does not catch any fault, i. e., it simply rethrows the fault to its parent scope that used to be the parent scope scope of SA. This also happens when SA throws a fault that is not caught by fault handler FHA. 5
Compared to many other techniques that merge processes that are semantically equivalent
such as different variants of the same process, we aim to merge collaborating processes.
Mendling and Simon [
Instead of directly generating a BPEL orchestration out of a BPEL4Chor
choreography, an intermediate format may be used. There is currently no approach keeping the
structure of the generated orchestration close to the structure of the original choreography.
For instance, Lohmann and Kleine [
In this work we extended the process consolidation approach presented in [
In future works we also have to propose a way to merge process models that interact via compensation handlers and event handlers. This is even more challenging as they allow neither inbound nor outbound control flow links. Another issue we have to address is that our current merge operations create process models that violate the peer-scopedependency rule. Basically, this rule states that two scopes enclosed within the same parent scope must have no cyclic control-flow dependencies, otherwise the compensation order of these scopes cannot be determined. However, in practice this rule is not enforced by engines such as the Apache ODE2 or BPEL-g3. 2 http://ode.apache.org/ 3 http://code.google.com/p/bpel-g/
In this paper, we informally argued that the consolidation approach is correct. A first
approach to provide a more formal validation has been presented in [
Acknowledgments This work was partially funded by the BMWi project Migrate! (01ME11055) and the BMWi project CloudCycle (01MD11023).