SEMANTIC ORCHESTRATION MERGING

Towards Composition of Overlapping Orchestrations

Clementine Nemo, Mireille Blay-Fornarino, Michel Riveill

I3S Laboratory, Rainbow team

CNRS - University of Nice-Sophia-Antipolis

930, route des colles, 06903 Sophia-Antipolis

unter Kniesel

Computer Science Department III, ROOTS group

University of Bonn

omerster. 164, D-53117 Bonn, Germany

Keywords:

Service Oriented Architecture (SOA), composition, merge, transformation.

Abstract:

Service oriented architectures foster evolution of enterprise information systems by supporting loose coupling

and easy composition of services. Unfortunately, current approaches to service composition are inapplica-

ble to services that share subservices or data. In this paper, we deﬁne overlapping orchestrations, analyse

the problems that they pose to existing composition approaches and propose orchestration merging, a novel,

interactive approach to composition of overlapping orchestrations based on their semantic.

1 INTRODUCTION

The need to adapt enterprise information systems

(EIS) to ever changing requirements calls for software

architectures that allow to master complexity without

preventing evolution. Service-oriented architectures

are particularly well-suited for modern EIS. They fos-

ter evolution by supporting loose coupling among ser-

vices and allowing easy composition of new services

from existing ones. Services that do not call them-

selves other services are called basic services (Bartoli

et al., 2005). A service orchestration deﬁnes a com-

posite service from several other services.

An orchestration encapsulates knowledge about

how to handle a task, the adaptations required to in-

tegrate services with mismatching interfaces and the

protocols of the integrated services. The ability to ex-

pose an orchestration as a service enables recursive

composition, which in turn enables inter-workﬂow in-

teraction, higher levels of reuse and additional scala-

bility (Khalaf et al., 2003).

Elaborating a service orchestration is very de-

manding in terms of effort and domain knowledge.

Therefore, different systems have been proposed to

ease the programmer’s tasks For instance, Oracle

BPEL Designer (Chandran and Poduval, 2005) en-

ables completely visual speciﬁcation of orchestrations

for basic services. The ADAPT framework (Bartoli

et al., 2005) additionally supports automated match-

ing of basic service parameters to composite service

parameters with the same name. For other parame-

ters, dataﬂow relations are visually speciﬁed by the

programmer. (Kazhamiakin et al., 2006). For a given

orchestration, Oracle BPEL Designer, Adapt and the

approach of Kazhamian et al. (Kazhamiakin et al.,

2006) support the veriﬁcation of different safety and

liveness properties. Whereas the above approaches

are conﬁned to orchestration of basic services, Kha-

laf et al (Khalaf et al., 2003) support orchestration of

composite services.

Unfortunately, all known approaches to orchestra-

tion composition are inapplicable to overlapping or-

chestrations, that is, to orchestrations that use com-

mon services or share data. In this context, our paper

provides the following contributions :

• deﬁnition of overlapping orchestrations (Sec. 2),

• illustration of the need to compose overlapping or-

chestrations,

• explanation of the problems of existing ap-

proaches in the presence of overlapping orches-

trations,

• introduction of orchestration merging, an alterna-

tive to traditional composition approaches that is

applicable to overlapping orchestrations (Sec. 3).

• introduction of model transformation rules that

guide the merging process (Sec. 4).

378

Nemo C., Blay-Fornarino M., Riveill M. and Kniesel G. (2007).

SEMANTIC ORCHESTRATION MERGING - Towards Composition of Overlapping Orchestrations.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - DISI, pages 378-383

DOI: 10.5220/0002392803780383

 SciTePress

List <hotel_list_1>

Info <hotel_choice_1>

ResBook <pre_book_1>

Bill <hotel_bill_0>

SearchHotel

CreateResBook

ChooseIn

BookHotel

SendBill

DebitBank

StructIn( Criterion <c_1>,

Address <a_1> )

Bill <hotel_bill_1>

GetCriterion1

GetAddr

Bill <flight_bill_2>

List <flight_list_1>

Info <flight_choice_1>

ResBook <pre_book_2>

Bill <flight_bill_1>

SearchFlight

CreateResBook

ChooseIn

BookFlight

SendBill

DebitBank

StructIn( Criterion <c_2>,

Address <a_2> )

GetCriterion2

GetAddr

List <hotel_list_1>

Info <hotel_choice_1>

ResBook <pre_book_1>

Bill <hotel_bill_0>

SearchHotel

CreateResBook

ChooseIn

BookHotel

SendBill

DebitBank

StructIn( Criterion <c_1>,

Address <a_1> )

Bill <hotel_bill_1>

GetCriterion1

GetAddr

Bill <flight_bill_2>

List <flight_list_1>

Info <flight_choice_1>

ResBook <pre_book_2>

Bill <flight_bill_1>

SearchFlight

CreateResBook

ChooseIn

BookFlight

SendBill

DebitBank

StructIn( Criterion <c_2>,

Address <a_2> )

GetCriterion2

GetAddr

a) HBO: Hotel Booking Orchestration. b) FBO: Flight Booking Orchestration.

Figure 1: Initial hotel booking orchestration and ﬂight booking orchestration.

2 PROBLEM STATEMENT

In this section we introduce our representation

of orchestrations, deﬁne overlapping orchestrations,

demonstrate the need for composing them by intro-

ducing a running example and discuss the problems

that they pose to known composition approaches.

2.1 BPEL Orchestrations

In this paper, we focus on orchestrations as deﬁned

by the OASIS Consortium (MacKenzie et al., 2006).

The Business Process Execution Language for Web

Services (BPEL4WS) is the principal standard deﬁn-

ing orchestrations. It supports primitive activities to

receive, return, read, assign, and modify data, invoke

a service, terminate the orchestration, wait or throw

an exception. In order to combine primitive activi-

ties BPEL supports structured activities allowing se-

quential, concurrent and conditional execution of ser-

vices. Orchestrations built from BPEL activities are

described in the following by UML activity diagrams.

For simplicity, we regard an orchestration as a func-

tion with a single parameter. This is no restriction

since a set of parameters can always be replaced by a

single parameter whose value is the aggregation of in-

dividual parameter values. The aggregation of values

and the selection of subcomponents from an aggre-

gate are represented as explicit adaptation activities,

marked by gray boxes in the diagrams. For instance,

in Fig.1a) GetAddr selects the address part of the or-

chestration’s input and CreateResBook generates an

aggregate from the address and the hotel choice infor-

mation.

2.2 Running Example

We use the classic example of a travel agency as our

reference use case (Kazhamiakin et al., 2006). A

travel agency offers booking of ﬂights or hotels. The

booking system consists of two orchestrations. The

ﬁrst describes the hotel booking process (Fig. 1a) and

the ﬂight booking process (Fig. Figure 1b).

We explain in detail the ﬁrst example:

• The Hotel Booking Orchestration (HBO) takes an

input that consists of two data elements with dif-

ferent types. The Criterion variable encapsulates

information used to select hotels. The Address

variable represents the address of the customer.

• The HBO is started by extracting the Criterion

value from the input and passing it as a parameter

to an invocation of the SearchHotel service.

• With the list of bookable hotels returned by

SearchHotel the ChooseIn service is invoked to let

the user select a hotel.

• The selected hotel and the customer address are

aggregated and passed to the BookHotel service.

• Finally, the process invoices the payment to the

customer’s bank and sends him the bill. This is

done by invoking ﬁrst the DebitBank service and

passing the returned Bill to the SendBill service

(which has no return value).

The ﬂight booking orchestration (Figure 1b) only

differs in the objects on which it works (ﬂights instead

of hotels) and in that SendBill and DebitBank are exe-

cuted concurrently. The orchestration returns the Bill

produced by DebitBank.

SEMANTIC ORCHESTRATION MERGING - Towards Composition of Overlapping Orchestrations

379

2.3 Overlapping Orchestrations

We say that two orchestrations overlap if they share

services or would share input or output data after

composition. In the travel agency example, the two

presented orchestrations overlap because they share

the services ChooseIn, DebitBank and SendBill and

because in a composition they would share the cus-

tomer address.

Now assume that the travel agency wants to jointly

offer ﬂights and hotels to its customers. For this, it

needs to have an integrated process for booking ﬂights

and hotels. Implementation of such a process either

requires writing a completely new service (which is

certainly undesirable) or the ability to compose the

existing services.

Unfortunately, known approaches to service com-

position are inapplicable in our example. They would

treat the existing orchestrations as black boxes that

are executed either sequentially or in parallel. In both

cases, black-box reuse of the existing orchestrations

would lead to highly undesirable effects:

• The payment service (DebitBank) would be called

twice for the same journey, resulting in double as

high network trafﬁc and twice as long time for

payment authorization.

• Separate processing of hotel and ﬂight payment

might result in authorization of the ﬁrst and rejec-

tion of the second payment if the customer’s ac-

count balance is insufﬁcient for paying both. Such

cases need further invocations of the payment ser-

vice for revoking the already performed ﬁrst pay-

ment. In addition to the added costs and network

trafﬁc, their treatment complicates the task of the

programmer who speciﬁes the orchestration, re-

quiring complex additional code for transaction

management.

• In the case of direct debit payments, which are

preferred by many companies because they only

involve a relatively small, ﬁxed fee per transaction

the double service invocation will result in double

online payment costs.

• Two separate bills would be sent to the customer,

increasing the postage costs of the company and

confusing the customer. If the bills do not arrive

simultaneously, customers might believe that the

booking not shown on the received bill had failed.

The problem illustrated by this small example is that

black-box reuse prevents identiﬁcation and proper

treatment of shared data and shared services. For in-

stance, in our example one would need to send just

one joint bill to the customer and ask the online pay-

ment service just once for the total sum of the journey.

Bill <journey_bill_1>

List <flight_list>

Info <flight_choice>

ResBook <pre_book_2>

Bill <flight_bill_1>

SearchFlight

CreateResBook

ChooseIn

BookFlight

DebitBank

StructIn( Criterion <c_1>, Criterion <c_2>, Address <a_2> )

Criterion <c_2>

GetCriterion2

List <hotel_list>

Info <hotel_choice>

ResBook <pre_book_1>

Bill <hotel_bill_0>

SearchHotel

CreateResBook

ChooseIn

BookHotel

Criterion <c_1>

GetCriterion1

GetAddr

Address <a_12>

CreateJourneyBill

SendBill

Bill <journey_bill_0>

Bill <journey_bill_2>

Figure 2: Merged Journey Booking Orchestration (JBO).

3 ORCHESTRATION MERGING

When confronted with overlapping orchestrations

without proper tool support, developers typically cre-

ate a new orchestration in which they integrate the

initial orchestrations via a series of routine transfor-

mations. The application of the following standard

actions on our example yields the merged orchestra-

tion illustrated in Figure 2:

(i) Unifying input data: Input parameters that rep-

resent the same data are uniﬁed. In our example,

the programmer determines that this is the case for

the Address a

1 and Address a 2 components of

both inputs (Figure 1). Therefore they are uniﬁed

in Figure 2. The search Criterion c 1 and Cri-

terion c 2 components for hotels and ﬂights are

different, so both are kept. In order to have only

one input parameter, a structure is created to en-

capsulate a 1, c 1 and c 2.

(ii) Detecting multiple calls to the same service: If

the same service is invoked on the same data and

the result is assigned to the same (or a uniﬁed)

variable, then the invocations can be uniﬁed. If

the input or output variables are different, the

programmer can still decide that they should

be uniﬁed. For instance, in our example, the

programmer decides to send just one joint bill

to the customer and ask the online payment

service just once for the total sum of the journey.

Therefore she merges the ﬂight and hotel bills

using the CreateJourneyBill adapter. However,

the two calls to the ChooseIn service are kept

ICEIS 2007 - International Conference on Enterprise Information Systems

380

since their input data and output data is different

and must not be uniﬁed.

(iii) Preserving the partial order of instructions:

The order of instructions in the resulting or-

chestration has to respect the orders of the input

orchestrations. The hotel booking orchestration

(Fig. 1a) imposes an order between DebitBank

and SendBill. The ﬂight booking orchestration

(Fig. 1b) in the resulting orchestration, these two

invocations are executed in the order speciﬁed for

hotel booking.

(iv) Unifying output data: In order to be correctly

deﬁned, the resulting orchestration must return a

single output data element. Therefore, the devel-

oper has to unify the output parameters or aggre-

gate them into a joint structure. This is similar to

point (i). This case does not occur in our exam-

ple since one of the input orchestrations returns

no result.

3.1 Interactive Orchestration Merging

With the current state of the art, developers per-

form all of the above steps manually when confronted

with the need to compose overlapping orchestrations.

They inspect the BPEL speciﬁcation of the input or-

chestration, identify shared data and shared service

calls and manually create the integrated orchestration.

Some environments ease understanding BPEL code

by providing graphical notations (Bartoli et al., 2005),

(Ben Mokhtar et al., 2006). However, this is insufﬁ-

cient since the identiﬁcation of overlaps and the detec-

tion of uniﬁcation candidates, the decision about uni-

ﬁcation and the merge process itself is still left to the

programmers. They have to repeat these steps after

every change of the input orchestration, even if none

of the sharing relations has been modiﬁed. This is not

only a waste of human resources but also a source of

errors that can be injected in the course of the manual

process.

One could consider automated orchestration mer-

ging as an alternative. However, full automation is

infeasible unless semantic speciﬁcations of each ser-

vice and data item are available. Without them we

cannot deduce, for instance, how to compose the two

calls to the ChooseIn service. Therefore, we propose

an interactive orchestration merging process that indi-

cates potential merging points to developers, remem-

bers their decisions for later reuse, automates the uni-

ﬁcation of invocations or data items decided by the

programmers in order to eliminate potential sources

of errors and automatically uniﬁes input and output

data whose conceptual identity can be derived from

previous uniﬁcation steps.

3.2 Merge Process

The interactive merge process illustrated in Figure 3

comprises three phases: the creation of an orchestra-

tion model, the transformations of the orchestration

model and the reverse engineering of BPEL from the

model.

From BPEL to an Orchestration Model (OM): In

the ﬁrst step, the BPEL speciﬁcation of each input or-

chestration is transformed to an internal representa-

tion. This phase corresponds to the transformation T

in Figure 3. It veriﬁes and normalizes the input. Vari-

ables are renamed to avoid accidental name clashes,

as shown in Figure 1a) and 1b). Multiple basic in-

vocations of the same service are grouped in a struc-

ture named complex invocation. We verify that each

branch of an alternative has at most one reply. These

preparations simplify the later steps.

Guiding the developer throughout the merging of

OMs: The merging tool explores all the orchestration

models given as inputs and detects required decision

points. Decision points can be potential merge points

or problem cases. For instance, concurrent reading

and writing of the same variable is a problem case

that requires the programmer to decide about an order

of these operations. Alternatively, two variables with

the same type in invocations of the same service could

be candidates for a uniﬁcation. Developers choose

to unify the merge candidates or mark them as se-

mantically different. The transformation process au-

tomatically computes the resulting orchestration and

updates the remaining merging points. After every

transformation, the process veriﬁes that the partial or-

der of instructions from the input orchestrations is still

preserved. For example, if in some block of an input

orchestration the service A is invoked before the ser-

vice B, the corresponding block of the resulting or-

chestration must not invoke the service B before A. In

addition, the precedence relationship must not contain

cycles introduced by uniﬁcation of two variables. If

a cycle is detected the last merge is undone and the

programmer is asked to revise his related decision.

Back to BPEL: The merge is ﬁnished when the re-

sulting orchestration is a function with one input and

one output, and all shared calls are uniﬁed or marked

as different. When this ﬁnal state is reached the result

model is transformed back to BPEL with the transfor-

mation T

out

shown in Figure 3.

Figure 3 shows the global process in which trans-

formation rules implement the steps explained above

and guide the actions of programmers. The transfor-

mation rules are detailed in Section 4.

SEMANTIC ORCHESTRATION MERGING - Towards Composition of Overlapping Orchestrations

381

Merge process

orch_1

orch_2

orch_n

mod_1

mod_2

mod_n

mod_merged orch_merged

out

BPEL

Orchestration

model

Transformation

rule

Legend:

transformation

rules T

Figure 3: Interactive merge process guided by transformation rule execution.

4 TRANSFORMATION RULES

FOR ORCHESTRATION

MERGING

We deﬁne an orchestration as a tuple o = (V, I, prec,

cond) where V is a set of variables described by a

name and a type, I is a ﬁnite set of instructions, prec

is a function that returns the list of instructions pre-

ceding a given instruction and cond is a function that

returns a list of conditions that must be true before

executing a given instruction. A ‘switch’ statement is

expressed by a set of mutually exclusive conditions.

An instruction is characterized by an identiﬁer, an

ordered list of input variables, an ordered list of out-

put variables and a primitive activity. A primitive ac-

tivity is a basic invocation, a return or an adapter. A

complex invocation groups several basic invocations

to the same service in order to normalize orchestra-

tions. It is characterized by the name of the invoked

service, the set of basic invocations to this service and

a composition function that deﬁnes how the results of

basic invocations are related (Montagnat et al., 2006).

In order to deﬁne and analyze

transformations of

orchestrations, we use an orchestration model and de-

ﬁne transformation rules on this representation. We

adopt the logic-based model representation and the

conditional transformation formalism developed by

Kniesel (Kniesel and Koch, 2004; Kniesel, 2006). For

lack of space, we do not describe the formal details of

the representation but conﬁne ourselves to an infor-

mal description of the transformation rules that guide

the developer in creating new orchestrations:

• At most one input variable: This rule detects a

Describing the use of Condor (Kniesel and Bardey,

2006) for analysing dependencies between transformation

rules is outside the scope of this paper.

potential merge point when an input variable is

free, i.e. unconnected to the output of any instruc-

tion. The programmer is asked to formulate re-

lationships between free variables. Depending on

the variable types, different relationships can be

expressed. Variables with identical types can be

uniﬁed (e.g. type Address in our example). If the

value of a variable is contained in another one, the

variables are in an inclusion relationship. For in-

stance, the bill identiﬁer is contained in the vari-

able denoting the bill. In this case, an adapter is

added with the Bill variable as input and the Iden-

tiﬁer variable as output. If none of these relation-

ships hold between the input variables (v1...vn),

we generate a new variable (v) whose type aggre-

gates the input variables types. This new variable

is the input of the merged orchestration. We gen-

erate adapters that yield the values of each for-

mer input variable (v1...vn) by accessing the cor-

responding component of (v).

• A single return in each branch : When an output is

expected, there must not exist more than a single

returned element for each branch. As in the previ-

ous rule, if we detect that there exist several return

instructions, the developer must specify relation-

ships between these instructions, e.g. mathemat-

ical operations that combine their results. Vari-

ables are then composed or some return instruc-

tions are removed.

• Unifying basic invocations : This rule detects a

potential merge point when there are several basic

invocations to the same service and when these

invocations (i1...in) are not part of a complex in-

vocation. The user can either unify them, or create

a complex invocation. In the ﬁrst case, an adapter

can be used to unify input variables. Output vari-

ables are uniﬁed automatically. A new basic invo-

ICEIS 2007 - International Conference on Enterprise Information Systems

382

cation i is created that is subject to all the guard-

ing conditions of the uniﬁed instructions (i1...in).

In the second case, invocations (i1..in) have to be

separately executed : a complex invocation (i) is

created by the user who speciﬁes the composition

function. Each basic invocation (i1..in) references

the complex invocation (i). The functions cond

and prec concerning the orchestration remain the

same.

• Unifying complex invocations : This rules consid-

ers the need for a merge when a complex invoca-

tion to a service A, and another invocation (basic

or complex) to the same service A are detected.

The developer must specify the result of the merge

as a new complex invocation that is referenced by

all the merged basic invocations.

• Unifying adapters: When several instructions use

the same adapter with the same input variable, this

rule proposes to the user to unify these instruc-

tions and subsequently also the output variables.

5 CONCLUSION AND

PERSPECTIVES

In this paper we addressed the need to broaden the

applicability of orchestration composition to overlap-

ping orchestrations, which share services or parame-

ters. We demonstrated that traditional black-box com-

position of orchestrations is inappropriate in the case

of overlapping orchestration because it fails to avoid

redundant or erroneous multiple invocations of the

same service. Therefore, programmers facing the task

to combine overlapping orchestrations must currently

perform a tedious and error-prone manual process.

As a remedy, we presented orchestration merg-

ing, an interactive, computer supported process that

guides programmers step-by-step through the integra-

tion task, automating many subtasks. Orchestration

merging identiﬁes potential merge points and gives

programmers a chance to to unify them or mark them

as distinct. If programmers decide to merge, the sys-

tem automates the merging steps. After each trans-

formation it checks the consistency of the orchestra-

tion model and computes remaining merging points.

When errors are detected, developers can undo pre-

ceding merging steps. We believe that our approach

is a contribution to more reliable and easy to evolve

service-oriented systems.

Besides the ongoing implementation of our ap-

proach there are different interesting conceptual ex-

tensions. Continuous evolution of orchestrations by

substitution, addition and deletion of services sug-

gests the need to integrate veriﬁcation of service com-

patibility (Martens, 2005), substitutability of services

(Camara et al., 2005) and equivalence of services

(Ben Mokhtar et al., 2006).

REFERENCES

Bartoli, A., Jiminez-Peris, R., Kemme, B., Pautasso, C.,

Patarin, S., Wheater, S., and Woodman, S. (2005).

The ADAPT framework for adaptable and compos-

able web services. IEEE Distributed Systems Online,

6(9).

Ben Mokhtar, S., Geogantas, N., and Issarny, V. (2006).

COCOA : Conversation-Based Service Composition

for Pervasive Computing Environments. In IEEE In-

ternational Conference on Pervasive Services (ICPS),

Lyon (France).

Camara, J., Canal, C., Cubo, J., and Vallecillo, A. (2005).

Formalizing WSBPEL Business Processes Using Pro-

cess Algebra. In Foundations of Coordination Lan-

guages and Software Architectures (FOCLASA), San

Francisco (CA). Springer.

Chandran, P. and Poduval, A. (2005). Adding BPEL to the

Enterprise Integration Mix. Technical report, ORA-

CLE.

Kazhamiakin, R., Pistore, M., and Santuari, L. (2006).

Analysis of communication models in web service

compositions. In WWW ’06: Proceedings of the 15th

international conference on World Wide Web, pages

267–276, New York, NY, USA. ACM Press.

Khalaf, R., Mukhi, N., and Weerawarana, S. (2003).

Service-Oriented Composition in BPEL4WS. In In-

ternational World Wide Web Conference (WWW), Bu-

dapest (Hungary). W3C.

Kniesel, G. (2006). A Logic Foundation for Conditional

Program Transformations. Technical report IAI-TR-

2006-01, ISSN 0944-8535, CS Dept. III, University

of Bonn, Germany.

Kniesel, G. and Bardey, U. (2006). An analysis of the cor-

rectness and completeness of aspect weaving. In Pro-

ceedings of Working Conference on Reverse Engineer-

ing 2006 (WCRE 2006, pages 324–333. IEEE.

Kniesel, G. and Koch, H. (2004). Static composition of

refactorings. Science of Computer Programming (Spe-

cial issue on Program Transformation), 52(1-3):9–51.

http://dx.doi.org/10.1016/j.scico.2004.03.002.

MacKenzie, M., Laskey, K., McCabe, F., Brown, P., and

Metz, R. (2006). Reference Model for Service Ori-

ented Architecture 1.0. Technical Report wd-soa-rm-

cd1, OASIS.

Martens, A. (2005). Simulation and equivalence between

bpel process models. In Design, Analysis, and Simu-

lation of Distributed Systems Symposium, San Diego

(California).

Montagnat, J., Glatard, T., and Lingrand, D. (2006). Data

composition patterns in service-based workﬂows. In

Workshop on Workﬂows in Support of Large-Scale

Science (WORKS’06), Paris, France.

SEMANTIC ORCHESTRATION MERGING - Towards Composition of Overlapping Orchestrations

383