DYNAMIC DECENTRALIZED SERVICE ORCHESTRATIONS

Ustun Yildiz

1,2

and Claude Godart

INRIA - LORIA

BP 239 Campus Scientiﬁque11

F-54500 Vandœuvre-l`es-Nancy, France

Gabriel Lippmann Research Center

41, rue du Brill

L-4422 Belvaux, Luxembourg

Keywords:

Web Services, Decentralized Orchestration, Peer-to-Peer Computing, Workﬂow, Dynamic Service Composi-

tion.

Abstract:

This paper reports a new approach to decentralized orchestration of service compositions. Our contribution is

motivated by the recent advances of service orchestration standardizations that enable the exchange of modeled

processes among different tools and organizations. Precisely, we provide an efﬁcient process transformation

technique that converts a process conceived for centralized orchestration to a set of nested peer processes. Each

peer process is conceived to be executed by a dynamically orchestrated service. Assuming that services are

invokable with peer processes, we provide a decentralized orchestration setting where services can establish

direct interconnections via the peer processes that they execute. Our proposition considers conversation-based

services and dynamic service binding.

1 INTRODUCTION

Web services are emerging as a new standardized

way to design and implement business processes

within and across enterprise boundaries. Basic XML-

based service technologies provide simple but pow-

erful means to model, discover and access software

applications over the Web. The term orchestration is

used to describe the design and implementation issues

of the combination of distinct services into a coherent

whole in order to fulﬁll sophisticated tasks that can-

not be fulﬁlled by a single service. Service orches-

tration and workﬂow management have many simi-

larities for both design and execution aspects. A ser-

vice orchestration environment implicitly assumes a

centralized execution setting where orchestrated ser-

vices interact with a centralized orchestrator service

as analogous to traditional workﬂow management.

As the relevant workﬂow literature (Chen and Hsu,

2001)(Alonso et al., 1995) conﬁrms, this approach

falls short of supporting a wide range of ubiquitous,

mobile , large-scale and secure process management.

In view of these challenges, it is desirable to imple-

ment decentralized orchestration settings where or-

chestrated services can establish direct interconnec-

tions following the principles of peer-to-peer comput-

ing. The key question of this approach is how com-

posed services that work following simple ”request-

response” and ”one-way” communication modalities

can be able to establish direct interconnections with

services other than the orchestrator that invokes them

for the purpose of the same process that they are in-

volved in.

In addition to basic service technologies, ser-

vice orchestration is the subject of various spec-

iﬁcation and standardization efforts. Among

others WS-BPEL(IBM et al., 2005) (BPEL for

short) has emerged as the de-facto standard for

implementing service orchestration by means of

processes(Weerawarana et al., 2005). A major out-

come of process standardization is the common com-

prehension and execution semantics that they pro-

vide. With respect to commonly agreed process spec-

iﬁcations, processes can be moved between distinct

tools and organizations and then it is very reason-

able to assume that orchestrated services can execute

processes. Consequently, a service that can behave as

an orchestrator can manage sophisticated interactions

with other services following the application logic of

the process that it executes. Following the motiva-

Yildiz U. and Godar t C. (2007).

DYNAMIC DECENTRALIZED SERVICE ORCHESTRATIONS.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 36-45

DOI: 10.5220/0001273000360045

 SciTePress

tion that services can be able to execute processes,

this paper takes on the challenge of designing a tech-

nique that enables decentralized orchestration. Our

proposition introduces the concept of peer process.

Peer processes are partitions of centralized orchestra-

tion speciﬁcation. Each peer process is executed by

a dynamically orchestrated service. Peer processes

behave as cooperating workﬂows during the execu-

tion and enable truly peer-to-peer interactions of or-

chestrated services. Thus, our precise contribution

is to provide such peer processes using initial peer

process speciﬁcation. As we mentioned above, our

approach assumes that services can execute processes

which can be also considered as they are invokable

with processes rather than their regular input. The

proposed approach is not an attempt to solve all of

the problems of decentralized process executions, our

aim is to provide a level of automation for the distri-

bution of relevant peer processes on autonomous ser-

vices. In the remainder of this paper, we present our

model that enables decentralized orchestration with

peer processes. The proposed technique that provides

peer processes deals with many different aspects of

decentralized orchestrations. First, it supports dy-

namic binding of services and introduces a new syn-

chronization technique for services that are likely to

be concurrently bound. We consider the orchestration

of conversation-based services where service inter-

faces externalize the business protocol supported by

the latter. Moreover, with the modeled processes, we

are taking sophisticated control and data dependen-

cies of process activities into account. Next subsec-

tion presents a motivating example and overviews our

approach. Section 2 describes a language independent

process model that we use to reason with processes.

Section 4 presents the core of our contribution. Sec-

tion 5 discusses the current status of our architectural

consideration while the last section reviews very re-

lated works and concludes.

1.1 Motivating Example and Overview

As example scenario, we consider the manner in

which the claim of a policyholder is handled by an

Insurance Company (IC) service. Figure 1 outlines

the process executed by IC. It depicts different activi-

ties that consist of service interactions with their con-

trol/data dependencies and interacting service identi-

ties. A control dependency expresses a precedence

relationship of two activities while a data edge means

that the data provided by an activity is used as the

input of another. In the process, ﬁrst, IC contacts

Emergency Service(ES) that the policyholder con-

tacted at the time of accident in order to receive the in-

a

1

:ES

A

N

D

a

2

:H

a

4

:P

A

N

D

a

5

:Ins

a

6

:DS

a

3

:DS

IC

Data dependency

Control dependency

Figure 1: Process Example for Insurance Case.

formation relevant to Hospital(H) and Police(P) ser-

vices that hold accident reports. After the invocation

of ES, P and H are invoked with the outcome pro-

vided from ES and a Delivery Service (DS) is pro-

visioned. It should be noted that DS provisioning ac-

tivity (a

) does not require any data provided by ES.

However, DS requires the outcome of H when it is

invoked a second time by activity a

. After the invo-

cations of P and H, concurrently received reports are

used to invoke an independent Inspection(Ins) ser-

vice to decide whether the claim must be reimbursed.

The outcome of Ins and H are sent to the policyholder

using DS (a

). In this example, DS is a conversation-

based service as it is invoked twice during the same

process.

Centralized Orchestration. In a centralized orches-

tration, all of the exchanged messages ﬂow back and

forth through IC that is the centralized orchestrator

service. For example, when IC invokes ES, the for-

mer receives the outcome of ES and then uses it to

invoke H and P. Similarly, the outcomes of H and P

are received by IC and sent to Ins from IC. In the same

time, the outcome received from H is also sent to DS

from IC in a successive stage of the process.

Decentralized Orchestration. If a decentralized or-

chestration setting is required, IC can invoke ES and

ES that terminates its execution can send its outcome

to H and P. In the same time, as the ﬁrst activity that

interacts with DS(a

) has a incoming control depen-

dence with ES, ES can invoke DS. Similarly, H and

P can send their outcomes directly to Ins. It should

be noted that in order to execute a

of Ins, a

must be

terminated. Consequently, DS must inform Ins about

the termination of a

. When H sends its outcome to

Ins as the input of a

, it can send the same outcome

to DS as it is used by a

too.

Dynamic Service Binding. One important point that

must be considered is the dynamic binding of services

rather than their binding at design time. Following the

same decentralized approach, ES must be able to dy-

namically bind H, P and DS before it sends its out-

DYNAMIC DECENTRALIZED SERVICE ORCHESTRATIONS

S

Data receiving activity

Data sending activity

Service implementation

Interactions between

peer processes

P

i

P

H

P

ES

P

IC

H

ES

A

N

D

P

ES

IC

Ins

A

N

D

P

DS

A

N

D

A

N

D

A

N

D

Figure 2: Decentralized Orchestration of Insurance Case.

come to them. In their turn, H, P and DS can bind

commonly an Ins that they can invoke. It should be

noted that Ins must not bind the service DS to which

it can send its outcome, because DS has been bound

in its previous step by ES. However, Ins must know

the service DS to which it must route its outcome.

Decentralized orchestration can be enabled if the

service interfaces support sophisticated P2P interac-

tions. For example, in the centralized orchestration

H must have some operations that receive the identity

of the service Ins to which it must route its outcome

instead of responding to IC that invokes it. Thus, in

centralized execution, with its regular input IC can in-

form Ins about where to send its relevant outcome.

However, if all of the service interfaces do not in-

clude the relevant operations to support decentralized

orchestration, it is not possible to have the above set-

ting.

With our approach, we aim to enable sophisticated

P2P interactions via the peer processes that are exe-

cuted by orchestrated services. A peer process that a

service S executed is noted P

. Let’s take the service

H. With respect to its simple interface, we aim to al-

low it to route its outcome to Ins. We make it execute

a peer process P

that receives the data sent by ES,

invokes the core operations of H characterized by a

and routes the outcome of a

to Ins which executes in

fact P

Ins

. In the same way, P

send the same outcome

to P

. It should be noted that ES is supposed to ex-

ecute its peer process denoted by P

that receives

the invocation message of P

, executes a

and routes

the outcome of a

to P

and P

. The same setting is

considered for other services that have to route their

outcome to other services directly. Figure 2 depicts a

decentralized setting of the motivating example with

peer processes. As readers will notice immediately,

peer processes are not direct partitions of the origi-

nal process speciﬁcation. They include additional ac-

tivities that enable interactions with other processes.

If the dynamic binding is supported, peer processes

must include activities that accomplish service bind-

ing operations. For example, if DS, H and P are re-

quired to be dynamically bound, the ﬁrst peer process

that must interact with them, which is P

, must bind

them. Moreover, their corresponding peer processes

that are P

, P

must be deployed by P

in or-

der to involve them in the overall decentralzied or-

chestration. Consequently, P

must include the peer

processes that it must deploy.

2 PROCESS MODEL

This section describes the formal underpinnings of

our approach that requires rigorous semantics on

modeled processes. It is important to clarify what we

do not intent to propose a new process language or

extends an existing one. The presented concepts are

applicable to a variety of process modeling languages

and execution engines. A process can be represented

as a message passing program modeled by a directed

acyclic graph (Leymann and Roller, 2000)

Deﬁnition 1 (Process) A process P is a tuple (A, C,

, E

, D) where A is the set of activities, C is the set

of control connectors, E

⊆ A × C × A is the set of

control edges, E

⊆ (A × A) × D is the set of data

edges and D is the set of data elements.

A process P has a unique start activity, denoted with

, that has no predecessors, and has a unique ﬁnal ac-

WEBIST 2007 - International Conference on Web Information Systems and Technologies

tivity, denoted with a

, with no successors. A control

edge from an activity a

to another activity a

means

that a

can not be executed until a

has reached a cer-

tain execution state (termination by default). A data

edge exists between two activities if a data is deﬁned

by an activity and referenced by another without inter-

leaving the deﬁnition of the same data. For example,

a data received from a service s

with the execution

of an activity a

can be used as the input value of an

activity a

that consists of an interaction with a ser-

vice s

. In this case, there is a data edge between a

and a

. It should be noted that our process model-

ing does not consider control edges between control

connectors. We associate source, target: E

∪ E

→

A functions return the target and source activities of

control and data edges. With respect to control ﬂow

we can also deﬁne a partial order, denoted by ≻, over

A, with ≻ ⊆ A × A such that a

≻ a

means there is

a control path from a

to a

A service oriented process consists of synchro-

nous/asynchronous interactions with services and lo-

cally executed activities such as variable assignments.

We can deﬁne a function ser: A → S that returns a

service interacted with an activity. As the dynamic

service binding is supported, the return value of func-

tion ser can be a real service instance if there is al-

ready a bound service and if not it can be another

value that identiﬁes the service that is supposed to

interacted with that activity. Thus, we can deﬁne a

process activity as below.

Deﬁnition 2 (Activity) An activity a is a tuple (in,

out, s, type) where in, out ∈ D that are input and

output values of a, s ∈ S is the interacting service

with S is the set of services, and type ∈ Σ

is the

type of activity with Σ

is the set of activity types.

The set of activity types can be deﬁned as follows

= {read, write, write/read, local} where read

activities receive data from services, write activities

send data to services, write/read activities consists of

synchronous interactions that sends a data and waits

the reply and ﬁnally, local refers to activities that do

not consist of service interactions. During the exe-

cution of sophisticated processes, some services can

be used with conversations. This means that dif-

ferent operations of the same service can be inter-

acted several times with distinct activities. The ac-

tivities that characterize these conversation-based in-

teractions with the same service are correlated activ-

ities

. In our example, activities that refer to interac-

tions with the same DS service are correlated. The

set of correlated activities belonging to a service s

denoted by A

Note that the term of correlation is literally different

from the usual correlation term used in BPEL

Activities of a process are structured using control

connectors (or control ﬂow patterns) (van der Aalst

et al., 2003). A control ﬂow connector can be seen as

an abstract description of a recurrent class of interac-

tions based on partial ordering of activities. For ex-

ample, the AND-split connector describes a choreog-

raphy by activation dependencies as following: an ac-

tivity is activated after the completion of several other

activities. Following the works presented in (van der

Aalst et al., 2003) that discusses the concrete imple-

mentation of patterns, we can consider a set of seven

relevant control connectors to use to express differ-

ent activation dependencies of activities. We gather

them into three categories as follows: Sequence,

Split = {AND-split, OR-split, XOR-split} and Join

= { AND-join, OR-join, XOR-join}. For each activ-

ity, with respect to its incoming and outgoing control

and data edges, we can identify two sets that include

corresponding source and target activities pointed by

these edges. The preset of an activity a is •a = {a

∈

A|∃d ∈ E

∨∃c ∈ E

, (source(d) = a

∧ target(d) =

a) ∧ (source(c) = a

∧ target(c) = a)}. The postset

of an activity a is a• = {a

∈ A|∃d ∈ E

∨∃c ∈ E

(source(d) = a

∧ target(d) = a) ∧ (source(c) = a

∧ target(c) = a)}.

3 PEER PROCESSES

In this section, we describe the core of our decentral-

ization approach. First, we focus on issues related to

the dynamic service binding. Next, we present our

process transformation technique that produces rele-

vant peer processes.

3.1 Service Binding

Service binding is the identiﬁcation of a concrete ser-

vice for the fulﬁllment of a single or set of correlated

activities. Both in centralized and decentralized ex-

ecution settings, service binding operations can be

done at different stages of process life cycle. Basi-

cally, a service instance (or endpoint) can be identi-

ﬁed prior to execution or it can be dynamically bound

during the process execution when it must be inter-

acted. The difference of decentralized orchestration

is that there is no centralized entity that does this op-

eration. So, if dynamic service binding is supported,

orchestrated services are also responsible for service

binding operation. It is intuitive that if a peer process

must send a coordination message or a process data

to another peer process, executed by another service,

it must know that process. If the corresponding ser-

vice end-point is not bound yet, the peer process that

DYNAMIC DECENTRALIZED SERVICE ORCHESTRATIONS

wants to interact with it, can bind it and deploy its

peer process. Consequently, the outcome can be sent

to the bound service. It should be noted that the

bound service identity must be propagated to other

peer processes that must interact with the same peer

process. At this point, we assume that control and

data messages exchanged among peer processes in-

clude also bound service identities.

Example 1 (Service Binding) In the insurance or-

chestration example, P

must send the outcome of

ES to H and P. In the same time, DS must be in-

voked following the termination of activity a

. If at

the moment P

must send its outcome, if there are

no bound H, P and DS services, P

can bind H,

P, DS and deploy their peer processes (this can be

explained also bound services can be invoked with

their respective peer processes that are P

, P

Thus, H and P can receive data sent by P

by exe-

cuting the ﬁrst activities of their peer processes and

accomplish the rest of their role following their de-

ployed peer processes. In this case, P

must include

relevant activities that bind services and also deploy

corresponding peer processes. In their turn, P

, P

and P

must interact with P

Ins

. If Ins is expected to

be dynamically bound, P

, P

can bind a ser-

vice Ins and send their outcome. However, the con-

current binding can cause a synchronization problem

as the former may bind different Ins service instances.

As explained in the above example, when peer

processes are produced, service binding operation

must be taken into account such that only one peer

process binds a precise service and other dependent

peer processes learn the bound service. In order to

do so, we use service binding dependencies. A ser-

vice binding dependency interconnects two activities.

It characterizes service binding and peer process de-

ployment activities that must be executed by the peer

process that executes the source activity of the bind-

ing dependency. With service binding dependencies

we aim to prevent concurrent service binding problem

by privileging a single peer process such that other

dependent peer processes can learn bound services. It

should be noted that during run-time binding opera-

tion is done if there is no service yet bound. More-

over, if an activity that belongs to a set of correlated

activities is considered, the binding operation is done

for the very ﬁrst activity and correlated activities are

initiated with the identity of bound service. In the ex-

ample, DS is bound only once for the ﬁrst activity that

it is interacted with. The binding policy that we adopt

postpones service binding operation as late as possi-

ble such that a service is bound in a stage that every

peer process that must interact with bound service’s

process can learn its identity correctly. The identiﬁ-

cation of a binding dependencythat targets an activity

is governed by the control and data dependencies that

target it.

Below, we make a classiﬁcation of the situations

that deﬁne binding dependencies among activities.

With respect to the different dependencies of activi-

ties in the centralized speciﬁcation and to the under-

lying services, we identify two cases.

Case 1: In the preset activities of an activity a for

which its fulﬁllment a service is supposed to be dy-

namically bound, there can be one or several activi-

ties. The respective peer processes that execute these

preset activities will have to send messages to the peer

process of a. In the ﬁrst case that identify binding

dependencies, if there is a unique preset activity a

that precedes all of the rest, there is a binding depen-

dency between this activity and a. This means that

the peer process that executes a

must bind the ser-

vice for the fulﬁllment of the activity a and deploy its

peer process. It should be noted that a service can be

dynamically bound to an activity if there is no corre-

lated activity that precedes the former. More formally

this binding dependency can be explained as follows:

|•a|≥1, ∃!a

∈•a such that ∀a

∈•a, a

≻a

⇒ a

→ a.

The relation

→ characterizes the binding depen-

dency of two activities. Activity a

is executed by

the ﬁrst peer process that must interact with the peer

process of a. Naturally, the service invoked by a must

be bound by the peer process of a

. However, a

must be unique and it must precede all preset activ-

ities, because the bound service identity is expected

to be propagated to other peer processes that execute

other peer processes that include preset activities. For

example, if we consider the activity a

that interacts

with H, in its preset, there is only a

that interacts

with ES. As H is expected to be dynamically bound

and there is no other preceding activity that interacts

with H, there is a binding dependency between a

and

that invoke respectively ES and H.

Case 2: The preset of the activity a include several

activities. In contrast to Case 1, there is not an a

in the preset that precedes all of the preset activi-

ties. Thus, an activity outsite of preset activity is

considered as the source of the binding dependency

that targets a. Intuitively speaking, an activity that

precedes all of the preset activities is chosen as the

source of binding dependency. Formally this situation

can be described as follows:

|•a| > 1, ∄a

∈ •a, ∃!a

∈ A such that ∀a

∈ •a, a

≻

, and a

≻ a

⇒ a

→ a.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

For example, in contrast to case 1, a

has three

preset activities. Consequently, if Ins is expected to

be dynamically bound, three peer processes of these

activities can not concurrently bind a service Ins as

they might not bind the same service. The privilege

can not be given to one of them as they have no inter-

actions before the invocation of Ins. In this situation,

we identify an activity that precedes all preset activi-

ties as the source of binding dependency. In the exam-

ple, this activity is a

that interacts with ES. With this

dependency, after a

is executed, P

binds a service

Ins. Furthermore, as P

has interactions with P

and P

, it can inform them about the relevant

identity of Ins service that allows them to send their

outcome to the common Ins.

By deﬁnition, there can be more that one activity

that precedes all of the preset activities. If this

is the case, one of them must be privileged for

the binding dependency, thus the peer process that

includes it can bind a service to a and peer processes

that execute preset activities can learn bound service

correctly. As we mentioned above, we aim to bind

a service as late as possible. Consequently, among

others a

must be an activity that precedes preset

activities but succeeds other activities that can be

the source of binding dependency. The sketch of

the algorithm that deﬁnes the activity a

that is

the source of the binding dependency is informally

described above:

Var:

: the set of all a

that ∀a

∈ •a, a

≺a

begin

if ∃!a

min

∈ a

that succeeds all activities then

bb min

is the source of binding dependency to a.

if a

min

is not unique then one of them is chosen as

the source of binding dependency (e.g. the activity with the

smallest identiﬁcation)

end

It should be noted the above algorithm is one of

the possible solutions for privileging an activity as

the source of binding dependency. The important

point that governs the operation is the precedence

of the source activity comparing to preset activities.

With service binding dependencies, each activity

can have at most one incoming binding dependency.

However, it can have several outgoing binding

dependencies. In order to characterize the activities

for which an activity a is the source of their incoming

binding dependencies, we use a(b). For each element

in a(b), a is the source of the binding dependency

that targets a

4 PEER PROCESS

The deﬁnition of binding dependencies is the very

ﬁrst step of our decentralized orchestration approach.

The essential part of decentralization is the character-

ization of peer processes. We call this step the pro-

duction of peer processes as they are produced using

a transformation that operates on centralized speciﬁ-

cation. Naturally, this step uses binding dependen-

cies. Peer process production is accomplished in sev-

eral steps. First, let us resume the content of peer

processes. A peer process that is to be executed by

a service s

is denoted by P

. As essential elements,

includes the elements of A

. Each element a

is preceded and succeeded by activities that ex-

change coordination and data messages with relevant

peer processes. Activities of A

can have outgoing

binding dependencies towards other activities which

means that the execution of source activities must be

followed by correspondingbinding operations and the

deployment of corresponding peer processes. Con-

sequently, P

must include the peer processes that

must be deployed to the services that it has bound.

However, the peer processes included within others

are like regular data elements to the latter that include

them. Another point that must be considered is the

propagation of service identities that are bound fol-

lowing binding dependencies. When peer processes

exchange coordination and data messages, they are

expected to exchange the relevant information about

the bound service identities that they received from

others and bound themselves. Instead of propos-

ing an additional coordination information that carry

bound service identities, we prefer to integrate these

information to exchanged coordination and data mes-

sages. For bound service identities propagation, the

peer processes must be able to update messages with

the service identities that they must send to other peer

processes. Consequently, peer processes must include

locally executed activities for update operations. In

this way, when a peer process learns the identity of a

bound service, it can update messages that it sends to

other processes.

We identify two main steps to examine the pro-

duction of peer processes. The ﬁrst step operates on

single activity level and consists of adding relevant

activities that enable the interaction with other peer

processes concerning that activity. The second step

deals with two issues: the ﬁrst is the structuring of

correlated activities in peer processes. The second is

the nesting of peer processes within each other.

Step 1: Adding relevant activities for coordination

purposes. Each peer process P

includes activities

DYNAMIC DECENTRALIZED SERVICE ORCHESTRATIONS

of A

. Naturally, in order to be able to execute each

element a

of A

, P

must collect all of the input

data of a

. Moreover, all of the control dependent pre-

set activities of a

must be terminated. This implies

that P

must collect also control messages of the pre-

set activities of a

. Thus, in P

, each activity a

preceded by a number of activities that collect coor-

dination and data messages coming from other peer

processes that include preset activities of a

. When all

of the activities that collect messages related to a

are

executed, a

can be executed by P

. Peer processes

that send messages related to a

to P

can be exe-

cuted concurrently, however the synchronized recep-

tion of sent messages is required to execute a

. Due to

exclusive choice and merging situations (XOR-split

and XOR-join) all of the preset activities might not

be executed. Consequently, the exclusivity of preset

activities must be taken into account when they are

collected. The execution of a

by P

can produce an

outcome to be sent to other activities to be executed in

their proper peer processes. Moreover, control mes-

sages corresponding to the termination of a

must be

sent accordingly. As the reception of messages from

peer processes that execute preset activities, the send-

ing of coordination and data messages can be accom-

plished concurrently.

Example 2 (Step 1) Step 1 is applied separately for

each activity of the centralized speciﬁcation. Let’s

take a

interacting with DS. The execution of a

re-

quires the termination of a

interacting with ES. Con-

sequently, P

must receive a control message about

the termination of a

from P

. The same activity has

an outgoing control dependency with a

interacting

with Ins. Thus, its execution must be followed by an

activity that sends a control message to P

Ins

. If we

take the second activity a

that interacts with DS, it

has two preset activities (a

, a

) interacting respec-

tively with Ins and H. Consequently, P

must collect

the outcome of a

and a

from their corresponding

peer processes that are respectively P

and P

Ins

In addition to control and data edges that interconnect

activities, there can be also binding edges that charac-

terize binding dependencies and relevant binding ac-

tivities. As we mentioned earlier, collected coordina-

tion and data messages of a

contain also identities

of previously bound services. These information and

services identities bound following the execution of

must be propagated to interacted peer processes.

Consequently, P

updates the messages that it must

send to other peer processes respectively.

Example 3 (Step 1 bis) In our example, the activi-

ties a

and a

have a binding dependency which

means that P

must bind a service Ins and deploy

Ins

. In the same time P

must bind H, P and DS.

Algorithm 1 Adding relevant activities for coordination

purposes

Input: a

∈ A

Output:

1: AND-split

2: for all a

∈ •a

3: read(ser(a

), a

.coor) //concurrent reception of

coordination messages from peer processes that ex-

ecute preset activities

4: end for

5: AND-join

6: local(extract) //extraction of the input values of a

and

service identities from received coordination messages

7: a

//execution of regular activity

8: AND-split

9: for all a

∈ a(b) do

10: local(bind) // binding operations are executed

11: end for

12: AND-join

13: local(update) // coordination messages and peer

processes are updated with service identities collected

from other processes and bound by the current peer

process

14: AND-split

15: for all ser(a

) of a

∈ a(b) do

16: write(ser(a

), P

ser(a

)

) //peer process deployment

for bound services

17: end for

18: AND-join

19: AND-split

20: for all a

∈ a

• do

21: write(ser(a

), a

.coor) // concurrent sending of co-

ordination messages to peer processes that execute

postset activities

22: end for

23: AND-join

Furthermore, P

Ins

must interact with P

. In order

to let P

Ins

to interact with P

(it must send a data

message for the execution of a

in P

), P

must

include the identity of DS in the P

Ins

that it deploys.

This operation is accomplished as follows: When P

is deployed to ES, it includes P

, P

Ins

data elements. When P

executes the service binding

operating, it must update peer processes with bound

service identities. This means that P

, P

and P

must be updated with the identity of Ins while P

Ins

must be updated with DS’s identity. Consequently,

must include relevant local activities that imple-

ment update operations after the binding operations.

Algorithm 1 describes the pseudo-code of the mech-

anism that consists of the ﬁrst step of transformation.

We note the output of the algorithm that takes an ac-

tivity a

as input with ea

. Besides the iterations, each

instruction of the algorithm characterizes an activity

or a control connector that must be added to ea

. Step

1 operates on each activity of the initial process speci-

WEBIST 2007 - International Conference on Web Information Systems and Technologies

ﬁcation. It adds the relevant activities that ensures the

coordination of peer process that includes this activ-

ity with other peer processes that include control and

data dependent activities of the same activity. Coordi-

nation messages related to an activity a

are denoted

by a

.coor. They can include either process data or

light-weight coordination messages with bound ser-

vices identities. Moreover, following the outgoing

binding dependencies, they include also the identi-

ties of bound services. Locally executed activities let

peer processes manage the content of the coordination

messages exchanged with other peer processes.

Step 2: Structuring Correlated Activities and Iter-

ative Nesting. The operation of step 2 is to gather

correlated activities manipulated by step 1 within

their corresponding peer processes and to nest peer

processes within each other to support dynamic ser-

vice binding and peer process deployment. Both op-

erations are conducted together because when a peer

process is produced, the peer processes that it in-

cludes, must have been produced in previous itera-

tions. Consequently, the production of peer processes

is started from the ones that do not include activities

that have outgoing binding dependencies. This oper-

ation is followed by the processes that include pro-

duced peer processes.

The operation that gathers correlated activities is

expected to preserve the partial order between them

within their peer processes. Basically, two correlated

activities a

≻a

of the centralized speciﬁcation must

preserve the same order ea

≻ ea

in their peer processes

after being transformed in step 1. If their partial or-

der is total, ea

must precede ea

. If a

and a

are

on concurrent paths, the concurrency of ea

and ea

must be preserved in the peer process that include

them. At this point, their exclusivity must be con-

sidered. This means that if ea

and ea

are exclusive

activities and only one of them is executed then their

peer process must structure them on exclusive paths.

Similarly, if they are expected to be concurrently exe-

cuted and synchronized before executing another cor-

related activity, they must be concurrently structured

within their peer processes.

Example 4 (Step 2) Figure 3 depicts the structuring

of the correlated activities a

and a

that refer to DS.

As we mentioned in the previous example, step 1 pro-

duces ea

and ea

. When they are gathered in P

, ea

and ea

must preserve the same order of a

and a

Consequently, step 2 puts ea

after ea

with a sequen-

tial dependency.

It should be noted that peer processes must be exe-

cutable processes that satisfy properties such as dead-

lock freeness, soundness etc. In order to do so,

P

DS

ã

6

ã

3

a

3

.coor

a

3

a

5

.coor

a

6

A

N

D

a

6

.coor

a

6

.coor

Sequential

structuring

P

Ins

P

ES

P

H

Figure 3: Structuring correlated activities in peer processes.

dummy activities and control connectors are added to

peer processes.

Algorithm 2 depicts the mechanism that operates

on the outcome of step 1. The operation starts with

peer processes that have no activities with outgoing

binding dependencies and iterates with ones that bind

the latter. We can identify a set P = (P , ≻) with P =

, ,P

} being the set of peer processes. If there

are two processes P

and P

with P

≻ P

, this

means that s

is bound by P

and P

is deployed by

. Consequently, P

must be produced before P

In order to describe peer processes that have no out-

going binding dependencies, we use the set min(P).

Similarly, the partial order ≻ of centralized speciﬁca-

tion is the same for the correlated activities of a ser-

vice s

included in A

. For both sets, the function

prec() returns the preceding element with respect to

the partial order. As correlated activities cannot be

always ordered, it is possible to have some subset of

activities that are incomparable. We note activities

that are incomparable by a set denoted as Inc

. All of

the activities of an incomparable set Inc

are included

in a common split and a join point in the centralized

process speciﬁcation. In the peer processes, after be-

ing transformed with step 1, these activities must be

structured within common split and join connectors.

The common split and join points of the activities of

an Inc

are deﬁned as below:

Deﬁnition 3 (Split-point) Let Inc

be a set of un-

ordered concurrent activities. A split-point of Inc

is the ﬁrst backward control connector c such that its

preceding activity a

split

precedes all elements of Inc

More formally, ∀a

∈ Inc

, a

≻a

split

Deﬁnition 4 (Join-point) The joint point of Inc

the ﬁrst forward control connector c such that its suc-

cessive activity a

join

follows all elements of Inc

More formally, ∀a

∈ Inc

, a

join

≻a

The type of split or join connectors is deﬁned accord-

ing to activation conditions of the elements of Inc

For example, if there are two activities ea

and ea

that

are not activated because of their exclusivity, they are

DYNAMIC DECENTRALIZED SERVICE ORCHESTRATIONS

Algorithm 2 Structuring and nesting peer processes

Input: A

⊂ A //The algorithm is executed for correlated

activities modiﬁed with the step 1

Output: P

//The peer process to be executed by the ini-

tial service

1: P

← min(P) //initialization of peer processes with a

process that does not include any activity with outgoing

binding dependencies

2: a

← a

//initialization of the current activity with the

ﬁnal activity of the produced process

3: for all P

∈ P do

4: for all

, a

∈ A

5: if ∃Inc

⊂ A, a

∈ Inc

/* if a

is a set of concur-

rent activities, split and join point detection pro-

cedures are started */ then

6: call

split

(Inc

)

7: call

join

(Inc

)

← prec(a

) //the structuring is repeated

with preceding activities that are not in Inc

9: else

10: Sequence //If there is no Inc

that a

belongs

to, sequential structuring is considered

11: a

← prec(a

) //the structuring is repeated

with preceding activities

12: end if

13: end for

14: P

← prec(P

) //the operation is repeated for peer

processes that include produced processes

15: end for

split by an XOR-split. Similarly, if activities are pre-

cisely executed, they are structured after an AND-

split. Due to lack of space, we don’t give the full de-

tails of mechanism that identiﬁes control connectors

of an Inc

. In the algorithm, we call the operation that

identiﬁes the split and join points of concurrent corre-

lated activities with call

split

(Inc

)and call

join

(Inc

The structuring algorithm begins with peer processes

that do not deploy other peer processes(min(P)) and

continues with those that include them. When a

peer process is structured, the structuring operation

is started with the ﬁnal activity and continues toward

the beginning.

5 ARCHITECTURAL

CONSIDERATIONS

The abstract concepts described in this paper are ap-

plicable to a variety of process modeling languages

and execution engines. However, it is important to

clarify some of the implementation details. In this

section, we present the current state of our implemen-

tation.

We use BPEL that characterizes the current state

of art in process modeling standardization efforts, as

Container service

Service

Implementation

Execution Engine

Peer

Process

Service

Interface

Figure 4: Implementation overview.

process speciﬁcation. In contrast to centralized exe-

cution settings, decentralized executions require ad-

ditional assumptions on composed services. As we

assume services to execute relevant peer processes,

the core services must be implemented inside ser-

vices that have process execution engines such as

BPWS4J(cf. Figure 4). The container services must

be invokable with peer processes. When they are

invoked with peer processes, they must also imple-

ment corresponding WSDL interfaces with corre-

sponding portTypes and partnerLinkTypes.

The basic method to support the dynamic service

binding can be supported with the reassignments of

partnerlinks. At this point, we assume a local

method that interacts with core service implementa-

tion reassigns required partnerlinks for dynamic ser-

vice binding purposes.

The essential operation of decentralization that

provides the nested peer processes is accomplished

on a single site which can be the ﬁrst service where

the overall process starts. BPEL allows specifying a

process in different ways. Typically, there are two

essential ways, additionally a third style that com-

bines both can be considered. The ﬁrst is the block-

oriented approach whereby there process is modeled

through nested use of structured activities (sequence,

ﬂow, while, switch). The second is the explicit use

of link constructs that allow the expression of arbi-

trary precedences and related join/transition condi-

tions. We use block-oriented modeling that makes

the data and control dependence analysis of processes

easier. The core module that produces peer processes

is a Java application that uses XPath to analyze BPEL

speciﬁcation. Xpath expressions query BPEL process

for control and data dependencies of basic activities

that consist of service interactions. Analyzed depen-

dencies are stored to deﬁne binding dependencies. We

prefer to not manipulate BPEL process that is ana-

lyzed as the concurrent analyze and manipulation of

tree structures have an important complexity.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

6 RELATED WORK AND

CONCLUDING REMARKS

The idea of decentralized execution setting is not new.

Issues related to decentralized execution of workﬂows

has been considered as very important in the relevant

research literature a decade ago. If we consider pre-

vious works that are not relevant to service oriented

paradigms and technologies, much of them are con-

ceived to prevent the overloading of a central coordi-

nator component. Their basic proposition is to mi-

grate process instances from an overloaded coordi-

nator to a more available according to some metrics

(e.g. (Bauer et al., 2003)) or execute sub-partitions

of a centralized speciﬁcation on distinct coordinators

(e.g. (Wodtke et al., 1997)). Although efﬁcient, these

approaches do not consider P2P interactions of work-

ﬂow elements.

The implementation of decentralization is rela-

tively new for service oriented applications. A simple

but crucial observation is that some of the recent ap-

proaches deal with decentralization by using central-

ized services or additional software layers what can

be a strong hypothesis in the Web context (Schuler

et al., 2005)(Benatallah et al., 2002) rather than rea-

soning decentralization with decentralized processes.

In contrast to the latter, the unique assumption of our

approach for orchestrated services is the capability of

executing processes. This is a reasonable assumption

in the context of modern virtual organizations that al-

ready implement internally their published interfaces

as processes.

(Nanda et al., 2004) proposes a process parti-

tioning technique similar to ours. However, the dy-

namic service binding and conversations are not con-

sidered. The authors focus on the partitioning of vari-

able assignment activities of a BPEL processes. The

works presented in (Maurino and Modafferi, 2005)

and (Sadiq et al., 2006) are similar.

This paper has taken on the challenge of design-

ing a technique for translating a centralized orches-

tration speciﬁcation to a set of dynamically deploy-

able peer processes. The proposed approach aims

to allow orchestrated services to have P2P interac-

tions through the peer processes that they execute.

When coupled with an efﬁcient process transforma-

tion technique, we believe that the common process

representation brought forward by standards can deal

with architectural concerns of decentralized execution

settings without making unreasonable assumptions

about composed services. Our contribution stands

between Orchestration and Choreography initiatives

that govern the implementation of service oriented ap-

plications. We demonstrated how an orchestration de-

scription can be effective with a decentralized execu-

tion as analogous to choreography that requires much

more sophisticated design and run-time reasoning.

REFERENCES

Alonso, G., Kamath, M., Agrawal, D., Abbadi, A. E., Gun-

thor, R., and Mohan, C. (1995). Exotica/ fmqm: A

persistent messagebased architecture for distributed

workﬂow management. In IFIP Working Confer-

ence on Information System Development for Decen-

tralised Organisations, Trondheim.

Bauer, T., Reichert, M., and Dadam, P. (2003). Intra-subnet

load balancing in distributed workﬂow management

systems. Int. J. Cooperative Inf. Syst., 12(3):295–324.

Benatallah, B., Sheng, Q. Z., Ngu, A. H. H., and Dumas, M.

(2002). Declarative composition and peer-to-peer pro-

visioning of dynamic web services. In ICDE, pages

297–308.

Chen, Q. and Hsu, M. (2001). Inter-enterprise collaborative

business process management. In Proceedings of the

17th International Conference on Data Engineering,

ICDE, pages 253–260.

IBM, BEA Systems, Microsoft, SAP AG, and

Siebel Systems (2005). Business Process

Execution Language for Web Services, ver-

sion 1.1 (updated 01 feb 2005). http://www-

128.ibm.com/developerworks/library/speciﬁcation/ws-

bpel/.

Leymann, F. and Roller, D. (2000). Production Workﬂow -

Concepts and Techniques. PTR Prentice Hall.

Maurino, A. and Modafferi, S. (2005). Partitioning rules for

orchestrating mobile information systems. Personal

and Ubiquitous Computing, 9(5):291–300.

Nanda, M. G., Chandra, S., and Sarkar, V. (2004). De-

centralizing execution of composite web services. In

OOPSLA, pages 170–187.

Sadiq, W., Sadiq, S., and Schulz, K. (2006). Model driven

distribution of collaborative business processes. In

IEEE International Conference on Services Comput-

ing, SCC.

Schuler, C., Turker, C., Schek, H.-J., Weber, R., and

Schuldt, H. (2005). Peer-to-peer execution of (trans-

actional) processes. International Journal of Cooper-

ative Information Systems, 14(4):377–405.

van der Aalst, W. M. P., ter Hofstede, A. H. M., Kie-

puszewski, B., and Barros, A. P. (2003). Work-

ﬂow patterns. Distributed and Parallel Databases,

14(1):5–51.

Weerawarana, S., Curbera, P., Leymann, F., Storey, T., and

Ferguson:, D. (2005). Web Services Platform Archi-

tecture. Prentice Hall PTR.

Wodtke, D., Weißenfels, J., Weikum, G., Dittrich, A. K.,

and Muth, P. (1997). The mentor workbench for

enterprise-wide workﬂow management. In SIGMOD

Conference, pages 576–579.

DYNAMIC DECENTRALIZED SERVICE ORCHESTRATIONS