1

Service Outsourcing with Process ViewsRik Eshuis, Member, IEEE, Alex Norta, Oliver Kopp, Esa Pitkanen

Abstract—Service outsourcing is a business paradigm in whichan organization has a part of its business process performed bya service provider. Process views are pivotal to support this wayof working. A process view shields secret or irrelevant detailsfrom a private business process, thus allowing an organization toreveal only public, relevant parts of its private business processto partner organizations. This paper introduces a specificationframework to support service outsourcing using process views.To enable the construction of process views at various levelsof detail, the framework defines several projection relationsbetween process views and the underlying internal processes.To allow consumers and providers of process views to establishan outsourcing relation, the framework defines several matchingrelations between the respective views that are comprehensiveand flexible for service outsourcing. A proof-of-concept prototypetool implements the framework, which is applied in a case study.

Keywords: Inter-organizational processes; process trees;matching; B2B; process visibility

I. INTRODUCTION

The way companies collaborate with each other has changedsignificantly in recent years. With the emergence of service-oriented computing (SOC) [1], companies embrace the visionof using web services for engaging dynamically and flexibly inbusiness-to-business (B2B) collaboration. Web services [2] arean important vehicle for enabling organizations to cooperatewith each other. Cooperation based on web services results ininter-organizational business processes that span the boundariesof multiple organizations [3], [4].

Service outsourcing is a business paradigm in which aservice-provider organization performs or coordinates partsof a business process of a service-consumer organization;these parts were previously performed or coordinated by theservice-consumer organization itself. The main motivation forservice outsourcing is that a specialized provider can performthe outsourced process parts more efficiently and effectivelythan the consumer. For example, in retail, the transportationprocess can be outsourced to a third-party logistics provider thatcoordinates the actual transportation. However, the consumermay require status information of the outsourced servicesto coordinate its own in-house business processes. Henceproviders need to expose status details of outsourced servicesin public process views [5], [6], which abstract from privatedetails of the provider processes performed on behalf of the

Rik Eshuis is with the Eindhoven University of Technology, The Netherlands.Email: h.eshuis@tue.nl

Alex Norta is with the Tallinn University of Technology, Estonia. Email:alex.norta@gmail.com

Oliver Kopp is with the University of Stuttgart, Germany. Email:kopp@iaas.uni-stuttgart.de

Esa Pitkanen is with the University of Helsinki, Finland.Email:epitkane@cs.helsinki.fi

Fig. 1. A specification framework for service outsourcing.

consumer. Service consumers use process views to monitor andcontrol the progress of service executions [7] by the provider.

While the notion of process view is generally recognized aspivotal to support service outsourcing [6], [8], to the bestof our knowledge there has been no research on how aconsumer organization that wishes to outsource a businessprocess, finds and connects to a provider that can performthe process. Some approaches tackle the construction ofprocess views [5], [9] from internal processes, but this isjust one aspect of the problem and is not specific to serviceoutsourcing [10]. In particular, each approach supports onlyone way to construct a process view from an internal process,ruling out the construction of other process views that areviable. Other approaches consider the problem of matchingprocess descriptions of services [11]–[13], but do not relatethis to the problem of constructing process views.

To fill this detected gap, this paper proposes a novelspecification framework for service outsourcing, depicted inFig. 1. The framework supports service outsourcing by enablingthe flexible construction and matching of public, externalprocess views that are fueled by private, internal processes.The framework hosts a comprehensive set of projectionrelations that enable the construction of different process viewsfor the same internal process. Choosing between differentprojection relations allows collaborating parties to expose inflexible ways only those details of their internal processesthey deem necessary. Next, the framework defines efficientmatching relations that allow consumers and providers toquickly establish suitable collaborations. The framework alsoconsiders the interplay of projection and matching relations.To connect to industrial practice, we use BPEL [14] as basemodeling language.

The rest of this paper is organized as follows. Section IIintroduces the problem of service outsourcing by presentinga running example that is revisited in the remaining sections.Section III formalizes BPEL specifications as process trees.Section IV first defines projection rules on process trees forconstructing a process view from an internal process. Based onthe projection rules, we identify several useful projection rela-tions between a private process and a process view. Section Vdefines several matching relations between process views based

2

consum

er

pro

cess v

iew

consumer process view

SEQ1

c: getGSM

In

SEQ2

c: scheduleroute

IX

Ob

c: deliverexpress

c: deliverregular

Ob

Ob

c: handoverparcel

Ob

c: deliverspecial

ObEX

c: wrapenvelope

In

c: configureGSM

In

Ob Ob

Fig. 2. BPMN process view of consumer of telecom-sales process. Used annotations: In=invocable, Ob=observable, EX=EXOR, IX=IXOR.

on which consumers and providers find each other and establishan outsourcing relationship. Section VI relates the projectionand matching definitions by defining feasible combinations foran outsourcing collaboration. Section VII presents a prototypeimplementation of the framework. Section VIII applies theprojection and matching definitions in an industrial case study.Section IX presents related work. Finally, Section X concludesthis paper.

This paper revises and expands two conference papers [12],[15], which tackle projection [15] and matching [12] of processviews in isolation. This paper analyzes their interplay andpresents in addition a tool implementation.

II. RUNNING EXAMPLE

We introduce by means of an example adapted from Vonkand Grefen [16] the notion of service outsourcing usingprocess views. As explained in the introduction, we use BPELas specification language. However, BPEL does not have astandard graphical notation. We therefore use BPMN [17] tovisualize BPEL processes [18].

Fig. 2 presents a telecom-sales process view that starts withpicking a GSM and next, configuring it according to customerdemand. Next, a subprocess (compound node) is performed todeliver the GSM-package, containing the following activities.First, a route is scheduled. Next, the GSM-package is delivered,which can be done in three different ways. Finally, the GSM-package is handed over to the customer who signs the receipt.

Fig. 2 uses specific notation for outsourcing. First, the sameactivity can occur in different models in the framework ofFig. 1. For instance, an activity can occur in a process-viewrequest of a consumer and a process-view offer of a provider.We distinguish these activity occurrences by prefixing activitylabels with a namespace indicator, which is either c: (for aconsumer) or p:, px:, py: (for providers).

Next, we specify which party takes the initiative to start anactivity. If the service provider initiates an activity, the activityis called observable [19], [20] (labeled Ob in Fig. 2). If theservice consumer initiates an activity, the activity is calledinvocable [19], [20] (labeled In). All observable and invocableactivities are performed by the service provider, and monitoredby the service consumer. Observable activities are the defaultfor outsourcing: a service consumer can track the status ofthe execution at the provider side but cannot control it. Byusing invocable activities, a service consumer can exert controlover the execution at the provider side. Distinguishing between

observable and invocable activities thus allows fine-grainedservice outsourcing.

We annotate a choice construct to specify whether that choiceis made externally or internally. The annotation IX for IXORin Fig. 2 means that the service consumer expects the providerto decide for the branch of an exclusive-choice split duringenactment. Conversely, an EX-annotation for EXOR means theservice consumer determines which branch of an OR-choiceto take. Fig. 3 depicts an EXOR-construct with an event-basedgateway.

The BPMN models in Fig. 3 and Fig. 4 show two privateprocesses owned by service providers X and Y for matchingto the consumer process in Fig. 2. Both processes share someactivities and ordering constraints with the consumer process,for example get GSM. Still, both provider processes containunobservable and uninvocable activities that are not part ofany process view.

The private process of provider X in Fig. 3 differs fromthe consumer view in Fig. 2 since it contains an event-basedgateway where the service consumer decides what branch totake during enactment. The two message-flows in Fig. 3 fromthe service consumer’s in-house domain depict this decision.The provider process contains compared to the consumerview the additional activities px:wrap envelope, px:determinetransportation and px:determine route. Since these activitiesare neither observable nor invocable, these activities have tobecome opaque for the service consumer during enactment.Furthermore, the consumer activity labeled c: schedule routedoes not exist in the private process of provider X in Fig. 3.

The private process of provider Y in Fig. 4 contains extraactivities py:check GSM and py:deliver priority compared toFig. 2. The latter activity leads to an additional third branchafter the exclusive XOR-split. Again, both activities carry notextual annotation, i.e., they are opaque to the service consumerduring enactment time.

To determine whether these two private provider processescan actually realize the requested consumer process view, bothprivate processes need to be projected into public process viewsand these views have to be matched with the consumer view.Sections IV and V present projection and matching definitions.

III. PROCESS TREES

As explained in the introduction, we base the outsourcingframework on BPEL [14]. We formalize the syntax of BPELmodels as process trees (see Definition 1). Leaves specify

3

pro

vid

er

pro

cess X

provider process X

SEQ1

px:get GSM

EX

In

px:configure

GSM In

px: wrapenvelope

In

px: testGSM

SEQ2

px:deliverexpress

px:handover

parcel

Ob

Ob

IX

px:deliverregular

Ob

c: deliverspecial

Ob

SEQ3

px:determine

route

px: determinetransportation

Ob

Ob

in-h

ouse

pro

cess in-house process

enabling signal Benabling signal A

Fig. 3. BPMN process for service provider X .

pro

vid

er

pro

cess Y

provider process Y

SEQ1

py:get GSM

In

py:configure

GSM

In

py: checkGSM

SEQ2

py:schedule

route

py:deliverregular

py:deliverexpress

py:handover

parcel

Ob

ObOb

py:deliverpriority

IX

Ob

Ob Ob

Fig. 4. BPMN Process for service provider Y .

the execution of basic activities and internal nodes specifyordering constraints on their child nodes. A SEQ-node specifiessequential execution of children nodes. An AND-node specifiesconcurrent execution, corresponding to the BPEL flow construct.An XOR-node specifies the execution of one of its child nodes.There exist two kinds of XOR: an internal XOR depictedwith an In-annotation in Fig. 3, where the system chooses abranch to enact and an external XOR depicted with an EX-annotation in Fig. 3, where the environment of the systemchooses a branch to enact. An external choice corresponds to aBPEL if-then-else or switch construct while an internal choicecorresponds to a pick construct. Finally, a LOOP-node specifiesstructured repeat-until loops. To simplify the exposition wedo not consider synchronization links here, but they can beincluded too [12].

We present a formal definition for process trees [5], [12].

Definition 1 A process tree P is a tuple(N,A,C, parent, succ) where:• N is the set of nodes, partitioned into sets A and C;• A is the set of activities or tasks. As subsets of A, we

consider disjoint sets In, Ob, so In ∩ Ob = ∅, whereIn is the set of invocable activities, and Ob is the set ofobservable activities;

• C is the set of control nodes, partitioned into sets CSEQ ,CAND , CEXOR, CIXOR, and CLOOP . Each node inC has subnodes, which are either control nodes oractivities (see function parent below). If a node n isin Ct, we call n a node of type t or a t-node for short.A SEQ-node specifies a sequential behavior, an AND-

node parallel behavior, an IXOR- and an EXOR-nodeexclusive behavior, where the choice is made internally forIXOR and externally for EXOR-nodes, and a LOOP -node specifies iterative behavior;

• parent : A∪C → C is a partial function that specifiesfor a node n ∈ N its super node parent(n). An activitycannot be a parent node;

• succ : N → N is a partial function that specifiessequential ordering within SEQ-nodes. If n′ = succ(n)then n and n′ have the same SEQ parent and n is directlysucceeded by n′.

We require that the start activities under an EXOR-node areinvocable: the environment chooses a particular branch of theEXOR-node by invoking the start activity of that branch. Wefollow BPMN [17] by modeling invocations as enabling signalsthat are thrown by the consumer and caught by the providervia messages. For instance, the branches of the EXOR-node inFig. 3 have start activities wrap envelope and configure GSM,both of which can only be invoked by the consumer.

For a node n, let children(n) = {x|parent(x)=n}. Bychildren∗ and children+, we denote the reflexive-transitiveclosure and the irreflexive-transitive closure of children, re-spectively. If n ∈ children∗(n′), we say that n is a descendantof n′ and that n′ is an ancestor of n. In particular, each noden is ancestor and descendant of itself, so n ∈ children∗(n),but n 6∈ children+(n). We require that the parent functioninduces a tree, so each node has one parent, except one uniquenode r, which has no parent. Since r is unique, r is ancestorof every node in N . These constraints ensure that nodes form

4

SEQ1

py:gG

py:sR

SEQ2

IXOR

py:cG

py:hP

py:dP py:dR

gG.. get GSM

cG..configure GSM

sR..schedule Route

hP..hand over parcel

dR..deliver regular

dE..deliver express

wE..wrap up envelope

dT..determine transportation

dRo..determine route

(a)

(b) (c)

SEQ: sequence

EXOR: external exclusive choice

IXOR: internal exclusive choice

chG..check GSM

dP..deliver priority

py:chG

SEQ1

c:cG

c:gG SEQ2

IXORc:sR c:hP

c:dR c:dS c:dE

EXOR

p:wE

py:dE

SEQ1

EXORpx:gG

px:dT

SEQ2

px:cG px:wE

SEQ3

px:dRo

IXOR

px:dE

px:hP

px:dR

px:dS

px:tG

Internal Level Internal Level

dS..deliver Special

tG..test GSM

provider process X

consumer process view

External Level

provider process Y

Fig. 5. Consumer-process view and service provider processes.

a tree structure with root r. Leaves of the tree are activitieswhile the internal nodes are control nodes.

Next, we require that each SEQ-, AND-, EXOR-, or IXOR-node has more than one child, and that each LOOP -nodehas exactly one child. If while constructing a process view(projection), an internal node i that is not a LOOP -node getsone child only, we remove i and its child becomes a child ofthe parent of i.

To explain the relation with the BPMN models in Section II,we show in Fig. 5 the abstract tree representations of theBPMN models presented in Section II. Nodes with bold linesare invocable activities, e.g., the service consumer initiates theinvocation of activities gG (get GSM) and cG (configure GSM)in the service provider domain. All the other nodes in Fig. 5(a)are observable but not invocable by the service consumer. Asbefore, the namespace-prefix c: indicates that activities residein the service consumer domain. Nodes with dashed lines inFig. 5(b) and (c) are neither invocable nor observable.

IV. PROJECTION RELATIONS

When a party projects its internal business process to aprocess view at the external level, it reveals what a successfulcollaboration setup requires and conceals the remainder toprotect business secrets that offer a competitive advantage. Still,the process view must be consistent with the underlying internalprocess. We define three projection rules for constructing aprocess view from an internal business process. The rulesensure consistency while safeguarding private details from theinternal process and are useful for both provider and consumerside processes:• Hiding: a set of nodes executed at the internal level are

not shown in the process view at the external level.• Omitting: a set of nodes that do not need to be executed

at the internal level are not shown in the process view atthe external level, e.g., activities of an EXOR-branch.

• Aggregation: a set of nodes executed at the internal levelis shown as a single node in the process view at the

external level.First, we define and explain these three basic projection rules

in Section IV-A. Next, Section IV-B uses the rules to definedifferent projection relations between a process view and anunderlying internal process.

A. Definition of projection rules

Each rule takes as input a process tree P and a node n,and returns an abstracted process tree P ′ in which a set inputnodes induced by n are hidden, omitted, or aggregated intoa new activity. For the aggregation rule, the new aggregateactivity is an additional input. To construct a process view froman internal process, one or more of the rules can be appliedconsecutively.

Rule 1 (Hiding): Node n is hidden from process tree Pif node n and its descendants are not contained in the processview but still part of the internal process and executable at theinternal level.

However, a hidden node cannot be an invocable activity,since a consumer cannot invoke an invisible activity. Moreover,the parent of n must be a SEQ-, AND-, or LOOP -node. Byconstraint, each branch of an EXOR-node contains as initialnode an invocable activity, and invocable activities cannot behidden. If a branch of an IXOR-node would be hidden andis chosen during execution, the consumer observes that aninternal choice has to be made but observes that none of thevisible branches are chosen, while the provider does continuewith the sequel of the process, counter the expectation of theconsumer. Therefore, node n cannot be hidden if the parent ofn is an EXOR-, or IXOR-node.

Definition 2 (Hiding) Let P be a process tree(N,A,C, parent, succ). If n ∈ N is a node to be hiddenfrom process tree P , then we require that• none of the descendants of n are invocable, so

children∗(n) ∩ In = ∅; and• n is not a complete branch of an EXOR or IXOR-node,

so parent(n) 6∈ CEXOR ∪ CIXOR.The resulting process tree P ′ is defined as(N ′, A′, C ′, parent′, succ′) where:• N ′ = N \ children∗(n)• A′ = A ∩N ′

• C ′ = C ∩N ′

• parent′ = parent ∩ (N ′ ×N ′)• succ′ = (succ ∩ (N ′ × N ′)) ∪ { (x, y) | succ(x) =

n ∧ succ(n) = y }

The definition for succ′ states that if node n is child of a SEQ-node with predecessor x and successor y, then the successorof x becomes y instead of n.

Example 1 In Fig. 5(c), py:chG can be hidden, since it satisfiesthe precondition for hiding. However, node py:dP must not behidden, since the parent is an IXOR-node. This means theprovider decides internally whether to enact py:dP or one ofits sibling nodes: py:dR or py:dE. If py:dP is not visible inthe process view but executed at the internal level, none of its

5

sibling nodes is chosen in the process view, but still the processview continues with py:hP, so then the consumer observes agap in the execution of the process view.

Rule 2 (Omitting): Node n is omitted from process treeP if node n and its successors in the same branch are notcontained in the process view and not executed at the internallevel, though the internal process contains the omitted nodes.

Omitting is only allowed if n is invocable. Next, n mustbe part of an EXOR-branch, that is, either the parent of nor its grandparent is an EXOR-node. Node n must be thefirst activity in the branch, as the consumer chooses whichbranch of the EXOR-node it executes, but the provider limitsthe possible options. If n is not the first activity, the internalprocess deadlocks when executing the branch and arriving at n.

Note that if n is part of an IXOR-branch, the providerdecides to execute n and therefore, omitting is not allowed.For example, if from Fig. 5(b) node p:dR were omitted, thenthe provider-process view does not contain this node, but theprovider internal process does contain p:dR and therefore coulddecide to execute it, contradicting the definition of omitting. Ifn has an EXOR-parent, the consumer, not the provider process,decides which branch to choose, without being able to chooseomitted nodes.

Definition 3 (Omitting) Let P be a process tree(N,A,C, parent, succ). If n ∈ N is a node to be omittedfrom process tree P , then we require that• n is invocable, so n ∈ In;• n has an EXOR-parent or grandparent:

either type(parent(n)) = EXOR ortype(parent(parent(n))) = EXOR;

• n is the first activity in its branch, so there does not exista node n′ ∈ N such that succ(n′) = n.

The resulting process tree P ′ is defined as(N ′, A′, C ′, parent′, succ′) where:• N ′ = N \ ({ n′ | ∃n′′ ∈ succ∗(n) : n′ ∈

children∗(n′′) } ∪ { n′ | parent(n) = n′ ∧ type(n′) =SEQ})

• A′ = A ∩N ′

• C ′ = C ∩N ′

• parent′ = parent ∩ (N ′ ×N ′)• succ′ = succ ∩ (N ′ ×N ′)

Example 2 Omitting node px:wE in Fig. 5(a) results in aprocess tree in which node EXOR has one child only. Asexplained in Section III, internal node EXOR is thereforeeliminated and px:wP becomes child of SEQ1.

Rule 3 (Aggregation): A set of neighboring nodes X ⊆ Nis aggregated from process tree P , if a single new activitynagg in the process view condenses all nodes in X and theirdescendants. The aggregated nodes are still part of the internalprocess and executable at the internal level. Elsewhere [5], weexplain how to aggregate a set of non-neighboring nodes.

However, we only allow aggregation of observable nodes.Aggregating an invocable node means the consumer is notable to invoke the node at the external level and therefore, the

execution deadlocks. This implies that external choices cannotbe part of an aggregate.

Definition 4 (Aggregation) Let P be a process tree(N,A,C, parent, succ). If X ⊆ N is a set of nodes to beaggregated from process tree P , then we require that• none of the descendants of any node n ∈ X are invocable,

so children∗(n) ∩ In = ∅.• none of the descendants of any node n ∈ X are external

choices, so children∗(n) ∩ CEXOR = ∅.If agg is the new aggregate activity, the resulting process treeP ′ is defined as (N ′, A′, C ′, parent′, succ′) where:• N ′ = (N \

⋃n∈X children∗(n)) ∪ {agg}

• A′ = (A \ (N ′ ∩A))∪ {agg}, where Ob′ = (Ob∩A′)∪{agg}.

• C ′ = C \ (N ′ ∩ C)• parent′ = (parent ∩ (N ′ × N ′)) ∪{ (agg, l) | parent(n) = l }

• succ′ = (succ ∩ (N ′ × N ′)) ∪{ (n′, agg), (agg, n′′) | succ(n′) = n ∧ succ(n) = n′′ }

Example 3 Applying the aggregation rule to nodes px:dT andpx:dRo in Fig. 5(b) with new activity sR (schedule route)results in a process tree in which the subtree containing thelast four activities is isomorphic to the corresponding subtreein Fig. 5(a).

Having explained and illustrated the projection rules, werevisit the example processes in Fig. 5, where Fig. 5(a) containsthe consumer process view and Fig. 5(b) and (c) internalprocesses of two providers.

Example 4 Omitting px:wE and aggregating SEQ3 inFig. 5(b) yields a process view that is identical (modulo prefixes)to the process view in Fig. 5(a). So provider X and theconsumer can collaborate with each other.

However, the internal process of provider y contains activitydeliver priority (dP) which is part of an IXOR-branch. Hiding,omitting, and aggregation are not applicable to this node.Consequently, it is not possible to derive a process view fromFig. 5(c) that satisfies the process view in Fig. 5(a).

Finally, note that the projection rules are also useful forderiving an internal process from a process view. By insertingactivities and control-flow to the process view, we derive aninternal process. The implicitly applied projection rules relatethe resulting internal process to the process view. For example,Fig. 5(b) can be derived from Fig. 5(a) since omitting andaggregating the extensions of the process model in (b) resultsin the process view in (a).

Next, we analyze the role played by the projections in thesetup of an inter-organizational collaboration configuration.

B. Projection relations between process view and internalprocess

In the previous section, we define general rules for trans-forming an internal process to a process view and vice versa. In

6

TABLE IPROJECTION RELATIONS.

this section, we look at possible projection relations between aprocess view and an internal process. Each projection relationuses a combination of the projection rules and Table I lists theextreme projection relations we consider. Black box, glass box,and open box stem from a Web-service outsourcing exampleby Grefen et al. [7] while Norta [21] identifies gray-box andwhite-box projection in a Petri-net study. All other possibleprojection relations are hybrid forms of these extreme relations.In the remainder of this section, we explain the projectionrelations listed in Table I.

Black-box projection occurs if the process view contains onlya single observable activity. A process tree that results fromblack-box projection contains a single node that aggregates orhides a set of nodes from the internal process. It is not possibleto hide or aggregate invocable activities, so the internal processdoes not contain any invocable activities. Moreover, since theexternal process tree cannot contain any EXOR-node withinvocable activities as descendants, omitting is no abstractionoption. The service consumer has no options to monitor andcontrol the progress of the internal process.

Glass-box projection occurs if the process view only containsobservable activities; the consumer cannot invoke any of theprovider-activities. Hiding and aggregating activities from aninternal-level process results in a glass-box view. Since theprocess view does not contain any invocable activities, omittingis not used. Black-box projection is a special case of glass-boxprojection. The service consumer can monitor the progressof the internal process through the process view, but has nocontrol options.

Gray-box projection occurs if the process view comes intoexistence through hiding and omitting from the internal process.The process view optionally contains both observable andinvocable activities while there is no aggregation. The serviceconsumer can monitor the internal process using observableactivities in the process view. The service consumer can controlthe progress of the internal process at the provider side throughinvocable activities in the process view.

Open-box projection occurs by establishing the processview through hiding, omitting, and aggregation from theinternal process. The process view contains both observable andinvocable activities, allowing a service consumer to monitorand control the progress of the internal process. Thus, theservice consumer can partially influence the progress of theinternal process in the provider-domain.

Finally, with a white-box projection the process view isidentical to the internal process. There is no application ofabstraction rules and the service consumer has a direct viewon the internal process of the provider. Thus, a white-box is aspecial case of an open-box projection. The service consumerhas now full control over the internal process at the provider.

Example 5 The consumer-process view in Fig. 5(a) is white-box related to the internal-level consumer process if thatprocess is identical to Fig. 5(a). Next, Fig. 5(a) relates asan open-box projection to Fig. 5(b) by applying both omittingand aggregation rules. Both provider processes in Fig. 5(b)and (c) can not relate to Fig. 5(a) using black-box or glass-boxprojections, since both processes contain an invocable activity.

In summary, the projection relations support a collaborationscenario in which collaborating parties optionally expose inflexible ways only those details of their internal processes asthey deem necessary. However, as we show in Section VI,not every combination of projection relations for consumerand provider-side is suitable for achieving external-levelharmonization between consumer and provider.

V. MATCHING RELATIONS BETWEEN PROCESS VIEWS

In the previous sections, we assume that a consumer anda provider view are identical. In practice, however, they maydiffer, since both parties develop process views independently.For instance, a provider offers a commoditized view that canbe accessed by different consumers. If the provider view differsslightly from the consumer view and is cheap, the consumercan decide to adjust its intended way of working by changingits process view. In these cases, the consumer requires a processview that is similar but not necessarily identical.

In this section, we introduce various matching definitionsfor comparing a consumer and a provider process view. Thedefinitions guide providers and consumers to find process viewsthat are similar to a requested process view. Each matchingdefinition uses its own notion of similarity, which is useful fora specific purpose.

In the remainder, Section V-A introduces different typesof matching, motivated by real-world scenarios. Section V-Bintroduces the auxiliary notion of process type that Section V-Cuses to formalize different types of matching between processviews.

A. Matching scenarios

Based on our experience in projects on inter-organizationalprocess integration [22] and existing literature on matchingsemantic web services [23]–[26], we list sample scenarios thatmotivate requirements on matching definitions:• A manufacturing organization requires the just-in-time de-

livery of a high-precision system service for its integrationinto a custom made production unit. The complexity ofthe end-product demands strict compliance of the serviceprovider to the specified request of the service consumerto ensure a timely completion of production.

7

• An organization interacts with a service provider, forexample to arrange logistics. A need exists for cross-synchronization between the main process and the processview. To prevent a deadlock, the provider process mustbe able to replace the projected consumer-process view.However, there is no need for an exact match betweenprovider and consumer view. For example, the provideroffers an extra quality check that the consumer choosesto ignore.

• An organization outsources part of its business processto a supplier. The outsourcing organization does notrequire synchronization with the supplier, but wishesto monitor the progress at the provider side. Therefore,the outsourcing organization does not require an exactmatching provider process; a close match (in combinationwith a low price) is sufficient for a provider selection.The outsourcing organization aligns its process viewsubsequently to the provider view.

As illustrated by the scenarios, various types of matching areuseful.

Exact matching of the external process views means bothprocess views are identical, so the provider view strictlycomplies with the consumer view. Exact matching supportsthe first scenario.

Plug-in matching means the provider view is a substitute forthe consumer view. That is, the provider view inherits fromthe consumer view. Using plug-in matching instead of exactmatching increases the probability of finding a collaboratingcounter-party since plug-in matching is less restrictive. Plug-inmatching supports the second scenario.

Inexact matching means the consumer view only containsthe main features of the desired process view and the serviceconsumer accepts process views that are not equivalent but doresemble the query process view. Inexact matching is usefulfor the third scenario, when the service consumer is willingto adjust its own way of working. After obtaining an inexactmatch, the consumer creates an aligned process view that is anexact or plug-in match with the provider view. Alternatively,the provider decides to align its process view to the consumerview to obtain an exact or plug-in match.

Failure occurs when no inexact matching is possible, eventhough the two processes may share some activities. In thatcase, the process views do not match.

B. Process types

We define the matching relations in terms of process typesrather than process trees. The process type of a process treespecifies the behavioral relations between the interactions. Theadvantage of a process type over a process tree for matchingis that process types abstract from irrelevant syntacticaldetails [12].

To define process types, we use auxiliary functions on thesyntax of process trees. For a set X of nodes, the least commonancestor of X , denoted lca(X), is the node x such that x isancestor of each node in X , and every other node y, which isancestor of each node in X is ancestor of x:• X ⊆ children∗(x)

• For every y ∈ N such that X ⊆ children∗(x), we havethat x ∈ children∗(y).

Since nodes are arranged in a tree, every set of nodes has aunique least common ancestor. For example, in Fig. 5(a) thelca of c:gG and c:sR is SEQ1 whereas the lca of c:dR andc:dE is IXOR.

Based on the notion of lca, we define behavioral relationson nodes. SEQ-nodes order their children and this way inducethe before < relation on their descendants. Given two nodesn, n′ ∈ N , we have n < n′ if and only if• node l = lca({n, n′}) is a SEQ-node, and• node l has children cn, cn′ such that cn is ancestor of

n, so n ∈ children∗(cn), cn′ is ancestor of n′, n′ ∈children∗(cn′), and cn′ is a successor of cn accordingto succ, so cn′ ∈ succ∗(cn).

Next, we define relations for choice and parallelism. Giventwo nodes n, n′ ∈ N , we have• n u n′ if and only if node l = lca({n, n′}) is an IXOR-

node.• nOn′ if and only if node l = lca({n, n′}) is an EXOR-

node.• n&n′ if and only if node l = lca({n, n′}) is an AND-

node.These three relations are symmetric, so if for instance n u n′

then by definition also n′ u n.The four defined relations abstract from loops, since they

do not take LOOP -nodes into account. To remedy this, wesuperscribe the four relations with multiplicity constraints asfollows. For instance, consider two nodes n, n′ of which theleast common ancestor is a SEQ-node. If the parent of theleast common ancestor of n and n′ is a LOOP -node, wewrite n <∗ n, and we write n <1 n′ otherwise. In a similarway, we superscribe the O-, u-, and &-relations. This way, wecan distinguish a process with a loop from the same processwith the loop removed. Unsubscripted relations can have anymultiplicity, so for example n < n′ means either n <1 n′ orn <∗ n′. We assume each LOOP -node has no LOOP -parent.

In the sequel, we restrict the relations <1, <∗, O1, O∗, u1,u∗, &1, and &∗, from nodes to activities, i.e. the leaves of theprocess tree. By definition of process trees, for any distincta, a′ ∈ A we have either a <1 a′, a <∗ a′, a&1a′, a&∗a′,aO1a′, or aO∗a′. Moreover, a op1 a

′ and a op2 a′ implies

op1 = op2. So for example a < a′ and aOa′ is impossible forthe same process tree.

The process type of a process P = (N,A,C, parent, succ),denoted PT (P ), is a tuple containing the different behavioralrelations:

PT (P ) = (<1, <∗,O1,O∗,u1,u∗,&1,&∗).

If L ⊆ A, then opL is op limited to L, so opL = op∩(L×L).Then PTL(P ) is obtained from PT (P ) by limiting each opof PT (P ) to L.

Example 6 The consumer process view in Fig. 2 hasamong others the following behavioral relations foractivity deliver regular: get GSM < deliver regular,configure GSM < deliver regular, schedule route <

8

deliver regular, deliver regularOdeliver express, anddeliver regular < handover parcel.

We define the union ∪ and intersection ∩ operator on twoprocess types PT (P ) and PT (Q) by applying these operatorsto the elements of the tuples. For instance, PT (P ) ∪ PT (Q)is the tuple t such that each element ti is the union ofthe corresponding elements in the individual tuples, so ti =PTi(P ) ∪ PTi(Q).

C. Matching definitionsWe formalize the different matching types in terms of process

trees. We use heuristics to define matching relations [12]: theyare efficiently computable but require additional semanticalanalysis in the case of exact and plug-in matching.

1) Exact matching: Two process trees P1, P2 match exactly,denoted P1 ≡ P2, if and only if• they have the same observable and invocable activities,

so In1 = In2 and Ob1 = Ob2.• they have the same process type, so PT (P1) = PT (P2),

and• the multiplicity of the activities is the same, so for each

a ∈ A1(= A2), the parent of a1 is a LOOP -node if andonly if the parent of a2 is a LOOP -node.

An exact match does not imply that the process-models are fullyequivalent, since the process tree abstracts from atomic actionssuch as assign and wait. However, if a user targets a fullyequivalent process, still exact matching is useful. For example,a matching engine uses exact matching to filter out relevantcandidate processes and then applies to these candidates the fullequivalence decision procedures, which are computationallymore expensive.

2) Plug-in matching: Process tree P1 is a plug-in for processtree P2, denoted P1BP2, if P1 contains all activities of P2 andhas the same process type as P1 for these shared activities.Still P1 might contain other activities that are not in P2. Thedefinition ensures that P1 successfully replaces P2 in everypossible context. In particular, the invocations made on P1

can be made in the same order on P2. However, P1 and P2

must agree on internal and external choices, to avoid thatP1 bypasses by means of a choice construct an obligatorypart of P2 (see Example 7). This relation resembles processinheritance, so P1 inherits from P2. Formally, P1BP2 if andonly if• P1 offers all activities of P2, so each activity of P2 is an

activity of P1: A2 ⊆ A1;• for the common activities, which are in A2, P1 and P2

agree on the process types and multiplicity: PTA2(P1) =

PT (P2) and for each a ∈ A2, parent2(a) is a LOOP -node if and only if parent1(a) is a LOOP -node.

• P1 and P2 agree on internal and external choices, i.e.,OP1

= OP2and uP1

= uP2.

Note that each exact match is also a plug-in match, but notvice versa. As in the previous case, plug-in matching requiresadditional heuristics to check at the semantic level and decidewhether a service replaces another one in all possible states.Plug-in matching is useful to filter out irrelevant processesbefore applying such a semantic check.

3) Inexact matching: We distinguish two types of inexactmatching. The first one is loop sensitive, taking multiplicitiesinto account. Since multiplicity 1 is a special case of *(executing a loop only once), business cases exist where it isuseful to ignore the difference between multiplicities. Therefore,we define a second variant of inexact matching that abstractsfrom multiplicities.

a) Loop-sensitive matching: For two process trees P1, P2

to match inexactly in the loop sensitive case, written P1 ul P2,P1 and P2 must have some overlap in process types, thusrespecting multiplicities:• P1 and P2 have activities in common, so A1 ∩A2 6= ∅.• For the overlapping activities, the process types have an

overlap as well. Let L = A1 ∩ A2. Then PTL(P1) ∩PTL(P2) 6= ∅.

• The multiplicities of the overlapping activities are thesame: for each a ∈ A1 ∩ A2, parent1(a) is a LOOP -node if and only if mult2(a) is a LOOP -node.

We rank inexactly matched process trees according to theirdegree of similarity. For this, we use the simple metric:

|PTL(P1) ∩ PTL(P2)|

|PT (P1) ∪ PT (P2)|.

Note that in the case of an exact match, the metric yields 1.Furthermore, if there is no match at all, the metric yields 0. Toensure that a plug-in match yields a number smaller than 1, thedenominator considers all possible relations, and not just thosein common between P1 and P2. For instance, if P1BP2 andP1 extends with P2 with one extra activity, then the commonactivities P1 and P2 have the same behavioral relations, andtherefore |PTL(P1) ∩ PTL(P2)| = |PTL(P1) ∪ PTL(P2)|.

b) Loop-insensitive matching: For inexact matching, itis useful to ignore the difference between multiplicities. Forexample, a <1 b matches a <? b, since there is only oneloop execution in the first case. Therefore, process types mustabstract from multiplicities. Given a process P , its abstractprocess type APT (P ) we define as the tuple (<,O,&).

For loop insensitive inexact matching, the abstract processignores multiplicities while types must overlap. Processes P1

and P2 match inexactly in the loop insensitive case, writtenP1 ui P2, if and only if• P1 and P2 have activities in common, so A1 ∩A2 6= ∅.• For the overlapping operations, the abstract process types

have an overlap as well. Let L = A1 ∩ A2. ThenAPTL(P1) ∩APTL(P2) 6= ∅.

A metric similar to the one defined for the loop-sensitivecase, ranks different candidate process trees.

Example 7 Consider the process view for provider Y obtainedfrom the internal process in Fig. 4 by hiding py:check GSM.Compared to the process view of the consumer in Fig. 2, theprocess view for provider Y contains one additional activity,py:deliver priority. Though the common activities have equalbehavioral relations in both process views, there is no plug-inmatch, since both process views have different u-relations dueto activity py:deliver priority. Thus, the process view for Y

9

allows that deliver regular and deliver express are not executed,which is not possible in the consumer view.

Comparing Fig. 2 and 4, we have an inexact match. Theconsumer view has 14 tuples in the <-relation and 2 in the u-relation; all other behavioral relations are empty. The processview for Y has 18 tuples in the <-relation and 6 in the u-relation. Since the consumer view has no additional behavioralrelations, <c⊂<y and uc ⊂ uy and |<c| = 14 while |uc| = 2.Therefore, the match is (14 + 2)/(18 + 6) which is 2/3.

VI. COLLABORATION CONFIGURATION FOR OUTSOURCING

After laying a foundation by identifying extreme projectionrelations between an internal process and an external processview, we now turn to establishing a collaboration-configurationbetween a service consumer and a service provider. The criticalissue is the detection of projection and matching constellationsso that the overall collaboration configuration is sound, i.e.,enacts in synchrony to the end as intended by the collaboratingcounter-parties. For this purpose, collapsing the consumer- andprovider processes is useful. Additionally, collapsing is usefulto show the actual outsourcing enactment.

First, Section VI-A analyzes the possible configurationoptions that define how the internal processes of the consumerand provider and their shared process views relate to eachother. Next, Section VI-B maps a collaboration configurationto a tree formalization and shows how a collapsing resultsin a deployment version that is suitable for verification andenactment.

A. Configuration options

The service consumer on the left and service provider onthe right of Fig. 6 relate their process views with one anotherusing the matching relations of Section V. They also relatetheir process views to their underlying internal processes usingthe projection relations of Section IV-B. Consequently, onlycertain combinations of projection and matching relations arepossible for process views at the external level.

The internal levels of Fig. 6 show on the left the consumerprocess and on the right the provider process. For both parties,the figure depicts the useful projection relations near theprojection arrow. In the middle of Fig. 6, the tuples withprojection combinations represent the meaningful options forestablishing process views on the external level. We now explainand motivate these combinations.

If the service consumer performs a black-box projection,the service provider only may use a black-box projection. All

(b,b)(gl,gl)

external level

internal level

b

gl

gr

o

w

project project

b

gl

w

internal level

SERVICE CONSUMER SERVICE PROVIDER

(w,gr/o/w)

Fig. 6. Valid collaboration configurations.

other projections result in processes having more than oneactivity, and thus, the resulting process view of the providerdoes not equal the consumer-process view. Likewise, if theservice consumer performs a glass-box projection, the serviceprovider can only use a glass-box projection, since that is theonly projection relation resulting in an external process viewwith only observable activities. If a service consumer performsa white-box projection, the service provider may respond witheither a gray-box, open-box, or white-box projection. Sincethe consumer-view may contain invocable activities, black-boxand glass-box projections do not apply.

Finally, a service consumer cannot use a gray-box or open-box projection. To see why, suppose the outsourced internalprocess of the service consumer contains an invocable node thatis omitted in the consumer-process view. Since the invocablenode is not in the process view, the provider process at theinternal level does not need to have a corresponding invocablenode. However, since the original node at the consumer-sideis invocable, that node can be invoked by another internalprocess of the consumer that interacts with the outsourcedprocess. Consequently, the provider process cannot replacethe outsourced consumer process. Therefore, only white-boxprojection is applicable if the internal process of the consumercontains an invocable node.

All projection options are only usable for exact matchingand plug-in matching. Inexact matching is useful to identifya consumer and provider view that are similar, followed bya process-view alignment to yield an exact or plug-in match.This may require a change of the underlying internal processes.An exact or plug-in match can be used with any of the possibleprojection combinations. In all cases, during actual execution ofthe provider view, its status gets mirrored in the consumer view.If the match is exact, the views of the consumer and provider areidentical. Otherwise, the provider contains additional activitiesthat are not monitored in the consumer view.

B. Tree-formalization mappingThe outsourced consumer view can interact with other

internal consumer processes that are not outsourced. To ensurethat the collaboration configuration is deadlock free, collapsingthe consumer and provider processes is useful. We show inFig. 7 the application of an existing collapsing method [21]with a process-tree formalization for which the collaborationconfiguration is white-box projection for the consumer andgray-box projection for the provider. The outsourced consumerprocess on the top left of Fig. 7 is part of a larger consumerprocess. The subtree below OSPROC is the outsourced con-sumer process at the internal level. Consumer activity cODinvokes outsourced activity p:gG and c:cN invokes p:cG.

The resulting collapsed configuration on the right side ofFig. 7 requires evaluation with tool support for correctnessissues, e.g., deadlocks or lack of synchronization. By represent-ing the resulting process tree in BPEL, it is possible to verifyproperties, e.g., by mapping to place/transition-nets [27].

Since the collapsing method requires disclosure of theinternal-level processes of all collaborating parties, an inde-pendent trusted third party must perform the replacement. Oth-erwise, leaking of business secrets is likely, which endangers

10

Collapsed Configuration

Colla

pse

SEQ3

sBgO

SEQ4

cOD

OSPPROC

FLOW

Service Consumer

Internal Level

SEQ1

EXORpx:gG

px:dT

Internal Level

SEQ1

c:cG

c:gG SEQ2

IXORc:sR c:hP

c:dR c:dS

SEQ2

px:cG px:wE

SEQ3

px:dRo

IXOR

px:dE

px:hP

px:dR

X

c:dE

Service Provider

sBgO

cOD

FLOW

SEQ1

EXORpx:gG

px:dT

SEQ2

px:cG px:wE

SEQ3

px:dRo

IXOR

px:dE

px:hP

px:dR

SEQ3

SEQ4

gO: get order

cOD: check order details

cN: configure network

sB: send bill

gG: get GSM

cG: configure GSM

sR: schedule route

dR: deliver regular

dS: deliver special

dE: deliver express

hP: hand over parcel

dT: determine transportation

px:dS

px:dS

EXOR

p:wE

px:tG

px:tG

wE: wrap envelope

tG: test GSMdRo: determine route

Fig. 7. A collapsed collaboration configuration.

competitive advantages. The collapsing is correct by followingthe projection options identified in Section VI-A; deadlocks donot occur because invocable activities of the process outsourcedby the consumer are preserved at the provider side.

Currently, BPEL [14] lacks the language constructs forspecifying the linking of respective processes for monitoringenactment progress and for allowing a service consumer totrigger the enactment of activities in the service-providerdomain. Potentially, the service provider, does not want tobe monitored extensively during enactment. In Fig. 7, linksstart and terminate the provider process. However, if thecollaborating parties agree, cross-platform linking constructsmust be available to observe the enactment progress of onlyspecific basic activities in a process view. More informationabout monitorability can be found elsewhere [21], [28] .

VII. TOOL IMPLEMENTATION

To validate the feasibility of the framework, we haveimplemented the projection and matching definitions in aprototype tool. First, we present an algorithm that takes as inputa process tree, together with projection rules defined on nodesof the process tree, and returns the projection of the processtree as output. Next, we present the actual implementation. Wehave applied the prototype tool to the case study discussed inthe next section.

A. Algorithm

We present a depth-first tree traversal algorithm that performsa projection of a given process tree, given a set of projectionrules as defined above. Input to the algorithm are a processtree P and a set M of projection specifications for the nodesin P . For each node n, its projection specification M(n) ∈{omit, hide, aggregate, none} specifies what projection ruleapplies to the node. We assume that given a node n, theprojection specification M(n) satisfies the preconditions forthe corresponding projection rule; an algorithm to check this is

omitted due to space limitations. A depth-first traversal of Mchecks the validity using a similar structure as for Algorithm 1.Next, we assume that the M -labeling is downward closed, so ifparent(n) = n′ and M(n′) = l’ then M(n) = l. Furthermore,if M(n) =“hide” and parent(n) is a SEQ-node, then forn′ = succ(n) also M(n′) =“hide”.

Given a process tree P and projection rules M for nodesof P , we next give Algorithm 1 that returns a process viewobtained via projection such that

1) Each node labeled with “omit” or “hide” is removed.2) For a node n that is labeled “aggregate” such that n is

the root of an aggregated subtree, we collapse the subtreeinto n and replace n with nagg .

3) A labeled node may not be the only child of any node.In such a case we delete the parent node and the parentof parent is connected to the child.

The algorithm assumes the parent function is implementedby a directed edge structure, such that if parent(n) = n′ thereis an edge (n′, n) from parent n′ to child n. This way, thealgorithm traverses starting from the root all the nodes of thetree in a depth-first search. Algorithm 1 takes O(m) time,where m is the number of nodes in P , and always terminates.

Algorithm 1 project(P,M)

1: {Steps 1) and 2)}2: for node n of P in DepthFirstSearchPostOrder do3: if M(n) = “omit” or M(n) = “hide” or (M(n) = “aggregate”

and n 6= root and M(parent(n)) = “aggregate”) then4: remove node n from P5: remove any link to/from n6: if n 6= root then7: remove edge (parent(n), n))8: else if M(n) = “aggregate” {subtree root} then9: replace node n with node nagg

10: {Step 3)}11: for node n of P in DepthFirstSearchPostOrder do12: if |children(n)| = 1 then13: let c be the child of n14: if n 6= root then15: add edge (parent(n), c)16: remove edge (parent(n), n)17: remove edge (n, c)18: remove node n19: return P

B. Implementation

An Eclipse-based prototype, available at https://github.com/koppor/outsourcing, implementsthe projection and matching definitions, including thealgorithms mentioned in Section VII-A. The prototypeuses the Eclipse BPEL model (http://www.eclipse.org/bpel/developers/model.php) and the JGraphTlibrary (http://jgrapht.org) to represent process trees.Input to the prototype are two BPEL files plus two textfiles specifying the projection rules that have to be applied.The projection rules use XPath expressions to identify theBPEL nodes that need to be projected. A projection rulefor aggregation in addition specifies the new activity. Fig. 8presents the main packages and classes of the Eclipse-based

11

matching

processtree

projections

org.eclipse.bpel.model org.jgrapht

Application

ProcessType ProcessTree

Node LCAProjections ActionList

Activity DirectedGraph DepthFirstIterator

Fig. 8. Main packages and classes of the prototype

prototype. The main application builds two process trees, onefor each BPEL file, by traversing the structure of the BPELprocess. An object of type ActionList contains the list ofprojections performed on a process tree. Class Projectionsperforms these projections on a process tree. Afterwards, theprocess type of the process tree is determined. Thereby, classLCA determines the least common ancestor, which is computedin polynomial time [29]. Class ProcessTree implements thecompare methods matchesExactly(ProcessTree),isPluginForProcessTree(ProcessTree), andgetDegreeOfInexactMatching(ProcessTree),which implement the matching definitions of Section V-A.

VIII. CASE STUDY

The case study stems from the domain of distributed,inter-organizational development processes in the automotiveindustry as studied in the CrossWork research project [22], [30].Observing the complexity of such B2B-collaborations from abusiness and a technical point of view reveals a scenario asdescribed in Fig. 9. An original equipment manufacturer (OEM)rests on top of the depicted B2B-pyramid and is responsiblefor engineering a product and setting up the machinery andplant construction for production. On the first tier, producersassemble systems and modules stemming from suppliers of thesecond tier. Finally, suppliers of raw materials and standardizedparts are at the bottom of the supply-chain pyramid.

In such supply chains, the OEM as a service consumerpushes the responsibility for accurate service provisioning downthe pyramid to first-tier suppliers as service providers whilethe first tries to concentrate tight control at the top tier. Thesuppliers must perform a mirroring of the particular outsourcedparts of the OEM’s internal process. In an extreme case, theservice consumer dictates the specified control-flow, data-flow,resources, and so on, in the services of a provider. However, inother industry domains, the opposite extreme is thinkable wherea service consumer does not impose any restrictions on stepsthat create the desired service provisioning. The remainderof this section addresses the mentioned problems inherent tosupply-chain hierarchies as depicted in Fig. 9. Based on thecollaboration framework of Fig. 1, we populate the internaland external levels with models of processes for the inter-organizational production of a water tank that is part of a truck.For brevity, we visualize the BPEL-based complex processesfrom the CrossWork case study in BPMN.

In the remainder below, Section VIII-A describes how theservice consumer outsources a business-process sphere from theinternal domain to a cluster of small and medium-sized service

Fig. 9. Supply-chain hierarchy in a B2B-collaboration.

providers. Section VIII-B details external-level collaborationspecifics of several clusters.

A. Consumer service

In the case study, a truck-producing OEM has severalsuppliers of services united in a regional automobile cluster ofservice providers. We assume the existence of internal processesin the domains of the service consumer and service provider.The service consumer proposes the creation of a service-outsourcing configuration. The negotiations about creating acommon external-level process follows an integration of thebusiness processes in the respective domains. Next followsa verification of the service-outsourcing configuration and anegotiation of the extent of monitoring. Finally, the enactmentof the completed service-outsourcing configuration commences.

B. External-Level Process View

Fig. 10 depicts the in-house process setup for the OEM. Ontop, the internal level shows the OEM’s business process thatorchestrates meaningful automation of human action. Fig. 10depicts the internal-level process for producing a truck inwhich unlabeled boxes represent activities of which we omitunnecessary details. Contained in the in-house process is asubprocess for producing a water tank that the OEM plans tooutsource to its suppliers. The OEM uses a process view toselect the right provider. The process view depicted in Fig. 11shows the external-level details for the subprocess in Fig. 10from the perspective of the OEM.

The OEM projects the outsourced sphere to the externallevel as a process view that is visible for all potential serviceproviders (see Fig. 11). Since a single service provider is notcapable of handling a request by itself, a group of providers

outsourcing

sphere

OSPHERE

in-house

process order

watertankprepare

specificationpreparepayment

start-sourcing end-sourcing

Fig. 10. OEM in-house process.

12

outs

ourc

ing

sphere

outsourcing sphere

consum

er

pro

cess v

iew

consumer process view

producegrommet

producesealing ring

producedispenser

producewatertank body

Ob

Ob

Ob

Ob

prepareorder

In

assemblewatertank

In

end-sourcingstart-sourcing

Fig. 11. Process view for producing watertanks.

outs

ourc

ing

sphere

outsourcing sphere

pro

vid

er

pro

cess

provider process

producesealing ring

producedispenser

producewatertank body

Ob

Ob

Ob

In

prepareorder

In

assemblewatertank

produce grommet

calibratemachine

Ob

outputgrommet

ObOb

end-sourcingstart-sourcing

Fig. 12. Internal process of a cluster that produces watertanks.

collaborate as a team in a cluster to fulfill the request. Clustersin the case study are formed ad-hoc, based on a specificrequest by the OEM. Fig. 12 shows the internal process ofone cluster. Different activities in the process are performedby different providers in the cluster, but this is not shown here.By aggregating the grommet-related activities of the internalprocess, an open-box process view can be constructed thatmatches exactly with the requested consumer view.

Several clusters may engage in bidding for servicing aparticular outsourced sphere from the external level, whichallows the service consumer to pick the “best deal”. Fig. 13and Fig. 14 show two process view bids of two alternativeclusters A and B. If the exactly matching offer of the clusterin Fig. 12 is not available, the OEM can choose for one ofthese two alternative clusters. The process view of cluster Ain Fig. 13 does not match exactly, since it contains oneextra compound activity, assemble watertank body.The inexact match with the process view in Fig. 11 is(9+12)/(9+3+12+6)=21/30=7/10 since Fig. 11 has 9 tuplesin the <-relation and 12 tuples in the &-relation, while Fig. 13has 3 additional tuples in the <-relation and 6 extra tuples inthe &-relation.

The process view of cluster B in Fig. 14 does not match

exactly since the ordering between produce watertankbody and produce dispenser is different from the onein Fig. 11. There is also no plug-in match, since the orderingis different. The inexact match we compute as follows. Theprocess views have 9 shared tuples in their <-relations and 10shared tuples in their &-relations. The process view in Fig. 11contains two additional tuples in its &-relation while Fig. 14contains one additional tuple in its <-relation. The inexactmatch is therefore (9+10)/(9+1+10+2)=19/22.

Whichever process view is selected, further alignment isneeded to establish a valid collaboration configuration (cf.Section VI), so either the consumer process or the providerprocess needs to be changed such that an exact or plug-inmatch can be made for their process views. Since the bidcluster B matches best with the requested view, alignment forthat process view is probably easiest. However, it might bethat the bid of cluster A is that cheap or the quality of thecluster that high that the OEM decides for A.

C. BPEL example

We show in Fig. 15 the BPEL model for theservice consumer process view in Fig. 11. We omitthe other BPEL models due to space limitations

13

pro

vid

er

pro

cess v

iew

A

provider process view A

prepareorder

producegrommet

producesealing ring

producedispenser

producewatertank body

assemblewatertank

assemblewatertank body

InOb

Ob

Ob

Ob Ob

In

Fig. 13. Process view of cluster A.

pro

vid

er

pro

cess v

iew

B

provider process view B

prepareorder

producegrommet

producewatertank body

producesealing ring

producedispenser

assemblewatertank

Ob

ObOb

Ob

In

In

Fig. 14. Process view of cluster B.

01: <process name="serviceConsumer"

02: xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/abstract"

03: xmlns:esrc="http://www.cs.helsinki.fi/u/anorta/research/eSourcing/">

04: <extensions>

05: <extension

06 namespace="http://www.cs.helsinki.fi/u/anorta/research/eSourcing/"

07: mustUnderstand="yes"/>

08: </extensions>

09: <sequence>

10: <invoke name="prepareOrder" esrc:status="invocable"/>

11: <flow>

12: <invoke name="produceSealingRing" esrc:status="observable"/>

13: <invoke name="produceGrommet" esrc:status="observable"/>

14: <invoke name="produceDispenser" esrc:status="observable"/>

15: <invoke name="produceWatertankBody" esrc:status="observable"/>

16: </flow>

17: <invoke name="assembleWatertank" esrc:status="invocable"/>

18: </sequence>

19: </process>

Fig. 15. BPEL model of the service consumer’s process view in Fig. 11.

but all BPEL models are available for download athttps://github.com/koppor/outsourcing/tree/master/processes/CrossWorkCaseStudy.The complete process is an abstract BPEL process (line 2)that is not executable by an engine, since it represents aprocess view. BPEL does not support the outsourcing featuresconsidered in this paper, but can be easily extended [31]. Lines4 to 8 declare the BPEL extension supporting the outsourcingframework presented in this paper. The process starts with asequence (line 9) of activities. First, the preparation of thewatertank specification (line 10) is executed. Next, a flowconstruct (line 11) comprises four parallel branches invokingthe production services (lines 12 to 15). Finally, the watertank is assembled (line 17). We use the esrc:statusattribute to specify that a node is invocable or observable(line 10, lines 12 to 15, and line 17). The BPEL model doesnot contain the message flows expressed in Fig. 11. These

flows can be expressed in BPEL4Chor [32], which supportsthe specification of interacting BPEL processes.

D. DiscussionThe case study shows the feasibility of the service outsourc-

ing framework. We have applied the prototype tool discussed inSection VII to the BPEL models presented in this section; theconstruction and matching of process views completes withina few seconds. The framework uses polynomial algorithmsand therefore scales well. The framework is therefore usefulin scenarios in which speed is important, for example in thecase of dynamic business networks [30]. As we discuss inSection IX, there is no comparable framework that coversboth the construction and matching of process views. Relatedmatching approaches only support inexact matching. Theframework supports the specification of fine-grained monitoringand control properties, which significantly extends current stateof the art.

The framework focuses on process aspects of businesscollaborations, captured in process views. It assumes the partiesalready agree on the structure and meaning of exchanged mes-sages [33]. Non-functional aspects of business collaborationssuch as service-level agreements and security agreements needto be covered separately.

IX. RELATED WORK

The service outsourcing framework supports inter-organizational business-process collaboration. Related workin this area is too extensive to discuss here. We focus on thetwo most related subareas: process views and matching.

A. Process viewsEarlier research [7], [34], [35] recognizes the importance of

public process views for service outsourcing. However, these

14

approaches focus on how to support a process view at run-timeand do not address how to construct a process view. Chebbi etal. [36] consider the construction of process views, but use onlyone projection relation. The framework in this paper is mostclosely related to the work of Grefen et al. [7], which definesseveral of the projection options identified in Section IV-B.But the framework can be combined with these other papers.

Schumm et al. [37] present a categorization of process-viewing patterns. Other papers study process views [5], [6],[9], [10], [38]. Van der Aalst and Weske [38] define how toderive private local processes from a global public processview. The projection relations they identify correspond tohiding and omitting. Bobrik et al. [10] study the constructionof personalized role-based public process views. Eshuis andGrefen [5] and Liu and Shen [9] focus on how to derive aprocess view from an internal process. Aggregation is a keyabstraction principle in both approaches, while Eshuis andGrefen also use a form of hiding. None of these process-viewapproaches focus on service outsourcing, and consequentlynone identify projection options and meaningful configurationsfor partners in an outsourcing collaboration.

Preuner and Schrefl [20] define an approach for combiningseveral process-based services into a compound process. Theydefine two consistency relations between the composed processview and the underlying processes: observability consistencyand invocability consistency. Observability consistency re-sembles hiding, whereas invocability consistency resemblesomitting. They do not consider aggregation, different projectionoptions or collaboration configurations.

Next, the BPEL standard [14] distinguishes between abstractand executable processes, where abstract processes correspondto process views. However, there are no concrete guidelines forrelating abstract and executable processes. Khalaf et al. [39]discuss patterns for relating an abstract process to an executableprocess. The patterns related to the framework in our paperare export (creating an abstract process from executableprocess) and import (creating an executable process from anabstract process). The three projection rules in Section IV areinstrumental in combination with the export and import pattern.Martens [40] proposes a Petri net-based approach to check theconsistency of an abstract and an executable BPEL process.Konig et al. [41] and Zhao et al. [42] define several syntacticguidelines for transforming an abstract BPEL process into anexecutable one with hiding and omitting. None of these papersdistinguishes between different projection relations and noneconsider aggregation.

Theoretical work exists on the problem of compatibilitychecking of Petri-net based services [27]. In principle, thiswork serves to check the compatibility of a consumer anda provider process. However, any combination of servicesthat does not deadlock is correct, which is not suitable foroutsourcing. The requirements for outsourcing are stricter sincea process view must mirror the provider process. Thus, eventhough a consumer process and provider process are compatible,they may not be in an outsourcing relation, for example, ifthe provider removes an observable activity that the consumerneeds to monitor.

Contractual-visibility patterns for inter-organizational

business-process [21], [28] also assume the projection ofa partitioned internal-level process to an external level,leading to different levels of visibility that resemble theprojection relations presented in Section IV-B. The maindifference between contractual-visibility patterns and projectionrelations is that the latter also incorporate the accessibility ofprojected nodes i.e., invocable or observable. Whereas thecontractual-visibility patterns only focus on the relationshipbetween the sets of nodes in the processes of the internaland external level and address the accessibility with separateso-called monitorability patterns [21]. By combining thecontractual-visibilities with monitorability patterns allprojection relations can be realized. Another difference is thatthe contractual-visibility patterns are expressed in Petri-nets,whereas the framework uses BPEL.

In sum, the service outsourcing framework contributes acomprehensive set of projection relations between internalprocesses and process views that allow a service consumer tomonitor and control the outsourced process view. Related workon process views focuses mostly on one projection relationand does not support monitoring and control of process views.Another novel aspect of the framework compared to relatedwork is that it considers the interplay with matching processviews by analyzing meaningful collaboration configurations.

B. Process matching

There are a few papers that address the problem of matchingand retrieving BPEL processes [11], [13], [43]. Corrales etal. [13], [43] describe an approach for inexact matching ofBPEL processes based on the theory of graph matching. EachBPEL process translates into a graph. Two BPEL graphs arecompared using the notion of edit distance, expressed in termsof the number of edit operations needed to transform one graphinto the other. Matching is done entirely on the syntax level,ignoring behavioral aspects like choice and parallelism whichare considered by the inexact matching definitions proposed inSection V. Moreover, Corrales et al. [13], [43] do not considerother matching definitions, so they cannot support all scenarioslisted in Section V.

Beeri et al. [11] define a language for querying BPELprocesses. In addition, they define an abstract syntax for BPEL,which consists of a set of process graphs and an implementationrelation that specifies for each compound node of a processgraph which other process graph implements the node. Eachquery is expressed as a structural pattern that is evaluatedon this abstract syntax. The query language allows navigationalong two dimensions: the path-dimension inside process graphsand the aggregation-dimension between process graphs. Again,matching of a query pattern with a BPEL process structureignores behavioral aspects as it is done on the syntax level,and only one kind of matching is defined, so not all scenariooutlined in Section V can be supported.

Next, there are matching approaches that use sequentialautomata [44]–[47] or Petri nets [48] to formalize behavioralaspects of web services. However, in the context of BPEL andOWL-S, the translation of constructs exhibiting parallelismleads to a state explosion, because the cartesian product of all

15

parallel branches has to be constructed. Thus, such a translationis not scalable, and leads to an inefficient matching approach.The matching approach of this paper is scalable, since processtrees can be derived in linear time from BPEL models and thematching algorithms in Section VII are polynomial.

In sum, the service outsourcing framework contributes aset of matching definitions for BPEL processes that supportmultiple scenarios, capture multiple behavioral aspects likesequence, choice, and parallelism, and can be efficientlychecked. Approaches in related work support only one typeof matching and focus either on syntactic similarity of BPELprocesses [11], [13], or are not efficient in the context ofBPEL [45]–[48]. Another contribution of this paper is ananalysis of the interplay between the construction and matchingof process views.

X. CONCLUSION

Key contribution of this paper is a collaboration frameworkthat supports outsourcing of business processes between partiesbased on process views. The separation of public processviews from private internal processes is vital to supportB2B-collaboration while maintaining privacy. The distinctionbetween observable and invocable activities allows a serviceconsumer to exert different levels of control over an outsourcedactivity. The framework considers both the construction ofpublic process views by projection of internal processes, andthe matching of consumer and provider views to measure theirsimilarity.

The projection rules of the framework use the abstractionprinciples of hiding, omitting and aggregation, which allowfor a flexible relationship between process views and internalprocesses. Based on the abstraction rules, the frameworkdefines several extreme projection relations that can existbetween a process view and an internal process We showedthat existing approaches for process views from literaturemostly focus only on one of these projection relations, whilethe business-collaboration framework of this paper is morecomprehensive. Also, existing process view approaches do notconsider matching of process views

The matching relations defined by the framework indicate thelevel of similarity between a consumer and provider processview, which is useful to find a similar process view or toestablish a collaboration between consumer and provider. Thematching relations employ heuristics, which allow for anefficient implementation. Due to its efficiency, the approach isuseful in scenarios in which speed is important, for examplefor dynamic business networks [30].

We analyzed the interplay between projection and matchingrelations by identifying valid collaboration configurations for aservice consumer and service provider. In particular, we showthat not every combination of projection and matching relationsfor provider and consumer-side processes is meaningful. Theprojection relation used by a party to construct a process view,limits the matching definitions that the party can use to findrelated process views.

Open issues for future research focus on supporting appli-cations to set up and enact collaboration configurations. As

process description language, we consider BPEL. However,BPEL requires extensions with additional language constructsthat allow a service consumer to start and stop the enactmentof provider processes and to remotely observe the enactmentprogress of the provider process. For a distributed setup andenactment of a collaboration configuration, it is necessary todevelop a reference architecture for supporting applicationsystems. We are currently evaluating the BPEL4Chor ecosys-tem [32] as runtime infrastructure. Another topic for futureresearch is applying process matching to ontology languageslike OWL-S.

Acknowledgments: This work was partially funded bythe BMWi project CloudCycle (01MD11023) and the TIVITproject Cloud Software.

REFERENCES

[1] M. P. Papazoglou and D. Georgakopoulos, “Service-oriented computing,”Communications of the ACM, vol. 46, no. 10, pp. 24–28, 2003.

[2] G. Alonso, F. Casati, H. Kuno, and V. Machiraju., Web Services: Concepts,Architectures and Applications. Springer, 2004.

[3] R. Khalaf, “From RosettaNet PIPs to BPEL processes: A three levelapproach for business protocols,” Data & Knowl. Eng., vol. 61, no. 1,pp. 23–38, 2007.

[4] J. Jung, H. Kim, and S. Kang, “Standards-based approaches to B2Bworkflow integration,” Comp. Ind. Eng., vol. 51, no. 2, pp. 321–334,2006.

[5] R. Eshuis and P. Grefen, “Constructing customized process views,” Data& Knowl. Eng., vol. 64, no. 2, pp. 419–438, 2008.

[6] P. Grefen, H. Ludwig, and S. Angelov, “A three-level framework forprocess and data management of complex e-services,” Int. Journal ofCooperative Information Systems, vol. 12, no. 4, pp. 487–531, 2003.

[7] P. Grefen, H. Ludwig, A. Dan, and S. Angelov, “An analysis of webservices support for dynamic business process outsourcing,” Informationand Software Technology, vol. 48, no. 11, pp. 1115–1134, 2006.

[8] C. Bussler, “The application of workflow technology in semantic B2Bintegration,” Distr. and Par. Databases, vol. 12, pp. 163–191, 2002.

[9] D.-R. Liu and M. Shen, “Workflow modeling for virtual processes: anorder-preserving process-view approach,” Inf. Syst, vol. 28, no. 6, pp.505–532, 2003.

[10] R. Bobrik, M. Reichert, and T. Bauer, “View-based process visualization,”in Proc. Business Process Management (BPM) 2007, ser. Lecture Notesin Computer Science, vol. 4714. Springer, 2007, pp. 88–95.

[11] C. Beeri, A. Eyal, S. Kamenkovich, and T. Milo, “Querying businessprocesses,” in Proc. International Conference on Very Large Databases(VLDB) 2006. ACM, 2006, pp. 343–354.

[12] R. Eshuis and P. Grefen, “Structural matching of BPEL processes,” inProc. European Conference on Web Services (ECOWS) ’07. IEEEComputer Society, 2007, pp. 171–180.

[13] D. Grigori, J. C. Corrales, M. Bouzeghoub, and A. Gater, “RankingBPEL processes for service discovery,” IEEE T. Services Computing,vol. 3, no. 3, pp. 178–192, 2010.

[14] A. Alves, A. Arkin, S. Askary, C. Barreto, B. Bloch, F. Curbera, M. Ford,Y. Goland, A. Guzar, N. Kartha, C. K. Liu, R. Khalaf, D. Koenig,M. Marin, V. Mehta, S. Thatte, D. Rijn, P. Yendluri, and A. Yiu,“Web services business process execution language version 2.0 (OASISstandard),” 2007.

[15] R. Eshuis and A. Norta, “A framework for service outsourcing usingprocess views,” in Enterprise Distributed Object Computing Conference(EDOC), 2010. IEEE Computer Society, 2010, pp. 99–108.

[16] J. Vonk and P. Grefen, “Cross-organizational transaction support fore-services in virtual enterprises.” Distributed and Parallel Databases,vol. 14, no. 2, pp. 137–172, 2003.

[17] Business Process Modeling Notation (BPMN), Ver-sion 2.0. Object Management Group, 2011,http://www.bpmn.org/spec/BPMN/2.0/.

[18] D. Schumm, D. Karastoyanova, F. Leymann, and J. Nitzsche, “Onvisualizing and modelling BPEL with BPMN,” in Proc. 2009 Workshopsat Grid and Pervasive Computing Conference. IEEE Computer Society,2009, pp. 80–87.

16

[19] J. Ebert and G. Engels, “Observable or invocable behaviour – you haveto choose!” Leiden University, Technical report 94-38, 1994.

[20] G. Preuner and M. Schrefl, “Requester-centered composition of businessprocesses from internal and external services,” Data & Knowl. Eng,vol. 52, no. 1, pp. 121–155, 2005.

[21] A. Norta, “Exploring Dynamic Inter-Organizational Business ProcessCollaboration,” Ph.D. dissertation, Eindhoven University of Technology,2007, trade edition published in 2008 with VDM Verlag.

[22] P. Grefen, R. Eshuis, N. Mehandjiev, G. Kouvas, and G. Weichhart,“Internet-based support for process-oriented instant virtual enterprises,”IEEE Internet Computing, vol. 13, no. 6, pp. 65–73, 2009.

[23] F. Kaufer and M. Klusch, “WSMO-MX: A logic programming basedhybrid service matchmaker.” in Proc. European Conference on WebServices (ECOWS), 2006. IEEE Computer Society, 2006, pp. 161–170.

[24] F. Lecue and A. Delteil, “Making the difference in semantic web servicecomposition,” in Proc. AAAI Conference on Artificial Intelligence, 2007,pp. 1383–1388.

[25] L. Li and I. Horrocks, “A software framework for matchmaking basedon semantic web technology,” in Proc. International World Wide WebConference (WWW) 2003. ACM, 2003, pp. 331–339.

[26] M. Paolucci, T. Kawamura, T. Payne, and K. Sycara, “Semantic matchingof web services capabilities,” in Proc. International Semantic WebConference (ISWC’02), ser. Lecture Notes in Computer Science, vol.2342. Springer, 2002, pp. 333–347.

[27] N. Lohmann, P. Massuthe, C. Stahl, and D. Weinberg, “Analyzinginteracting WS-BPEL processes using flexible model generation,” Data& Knowl. Eng., vol. 64, no. 1, pp. 38–54, 2008.

[28] A. Norta and P. Grefen, “Discovering patterns for inter-organizationalbusiness collaboration,” Int. Journal of Cooperative Information Systems,vol. 16, no. 3/4, pp. 507–544, 2007.

[29] H. N. Gabow and R. E. Tarjan, “A linear-time algorithm for a specialcase of disjoint set union,” J. Comput. Syst. Sci., vol. 30, no. 2, pp.209–221, 1985.

[30] N. Mehandjiev and P. Grefen, Eds., Dynamic Business Process Formationfor Instant Virtual Enterprises. Springer, 2010.

[31] O. Kopp, K. Gorlach, D. Karastoyanova, F. Leymann, M. Reiter,D. Schumm, M. Sonntag, S. Strauch, T. Unger, M. Wieland, andR. Khalaf, “A classification of BPEL extensions,” Journal of SystemsIntegration, vol. 2, no. 4, pp. 2–28, November 2011.

[32] G. Decker, O. Kopp, F. Leymann, and M. Weske, “Interacting services:From specification to execution,” Data Knowl. Eng., vol. 68, no. 10, pp.946–972, 2009.

[33] M. Nagarajan, K. Verma, A. P. Sheth, J. A. Miller, and J. Lathem,“Semantic interoperability of web services – challenges and experiences,”in Proc. International Conference on Web Services (ICWS) 2006. IEEEComputer Society, 2006, pp. 373–382.

[34] D. Chiu, S. Cheung, S. Till, K. Karlapalem, Q. Li, and E. Kafeza,“Workflow view driven cross-organizational interoperability in a webservice environment,” Inf. Tech. and Management, vol. 5, no. 3-4, pp.221–250, 2004.

[35] K. Schulz and M. Orlowska, “Facilitating cross-organisational workflowswith a workflow view approach.” Data Knowl. Eng., vol. 51, no. 1, pp.109–147, 2004.

[36] I. Chebbi, S. Dustdar, and S. Tata, “The view-based approach to dynamicinter-organizational workflow cooperation.” Data & Knowl. Eng., vol. 56,no. 2, pp. 139–173, 2006.

[37] D. Schumm, F. Leymann, and A. Streule, “Process viewing patterns,”in Enterprise Distributed Object Computing Conference (EDOC), 2010.IEEE Computer Society, 2010.

[38] W. van der Aalst and M. Weske, “The P2P approach to interorganizationalworkflows,” in Proc. of the 13th International Conference on AdvancedInformation Systems Engineering (CAiSE’01), ser. Lecture Notes inComputer Science 2068. Springer, 2001, pp. 140–156.

[39] R. Khalaf, A. Keller, and F. Leymann, “Business processes for webservices: Principles and applications,” IBM Systems Journal, vol. 45,no. 2, pp. 425–446, 2006.

[40] A. Martens, “Consistency between executable and abstract processes,”in Proc. International Conference on e-Technology, e-Commerce, ande-Services (EEE) 2005. IEEE Computer Society Press, 2005.

[41] D. Konig, N. Lohmann, S. Moser, C. Stahl, and K. Wolf, “Extendingthe compatibility notion for abstract WS-BPEL processes,” in Proc. Int.Conference on World Wide Web (WWW). ACM, 2008, pp. 785–794.

[42] X. Zhao, C. Liu, W. Sadiq, M. Kowalkiewicz, and S. Yongchareon,“WS-BPEL business process abstraction and concretisation,” in Proc.Database Systems for Adv. Applications (DASFAA) 2009, ser. LectureNotes in Computer Science, vol. 5463. Springer, 2009, pp. 555–569.

[43] J. Corrales, D. Grigori, and M. Bouzeghoub, “BPEL processes matchmak-ing for service discovery.” in Proc. CoopIS 2006, ser. Lecture Notes inComputer Science, R. Meersman and Z. Tari, Eds., vol. 4275. Springer,2006, pp. 237–254.

[44] B. Benatallah, F. Casati, and F. Toumani, “Representing, analysing andmanaging web service protocols,” Data & Knowledge Engineering.,vol. 58, no. 3, pp. 327–357, 2006.

[45] L. Lei and Z. Duan, “Transforming OWL-S process model into EDFAfor service discovery,” in Proc. International Conference on Web Services(ICWS) 2006. IEEE Computer Society, 2006, pp. 137–144.

[46] Z. Shen and J. Su, “Web service discovery based on behavior signatures,”in Proc. International Conference on Services Computing (SCC) 2005.IEEE Computer Society, 2005, pp. 279–286.

[47] A. Wombacher, P. Fankhauser, and E. Neuhold, “Transforming BPELinto annotated deterministic finite state automata for service discovery.”in Proc. ICWS’04. IEEE Computer Society, 2004, pp. 316–323.

[48] A. Brogi and S. Corfini, “Behaviour-aware discovery of web servicecompositions,” Int. J. Web Service Res., vol. 4, no. 3, pp. 1–25, 2007.

Rik Eshuis is an assistant professor at Eindhoven University of Technology,The Netherlands. He received an MSc degree (1998) and a PhD degree (2002) inComputer Science from the University of Twente. He has been visiting scholarat IBM T.J. Watson Research Center and at CRP Henri Tudor in Luxembourg.He was involved in the IST project CrossWork, which focused on developingadvanced process support for the automotive industry. He is on the editorialboard of the Open Software Engineering Journal. His main research interest isin process-oriented information systems and service-oriented computing. Thisincludes areas like process composition, process views, process integration,process modeling, process analysis, service composition, and service adaptation.He is member of ACM, IEEE, and IEEE Computer Society.

Alex Norta is a post-doctoral researchers at the Tallinn University ofTechnology, Estonia. Before that he was a post-doctoral researcher at theUniversity of Oulu and University of Helsinki, Finland. He received his MScdegree (2001) from the Johannes Kepler University of Linz, Austria andhis PhD degree (2007) from the Eindhoven University of Technology, TheNetherlands. His PhD thesis was partly financed by the IST project CrossWork,in which he focused on developing the eSourcing concept for dynamic inter-organizational business process collaboration. His research interests includebusiness process collaboration, e-business transactions, service-oriented cloudcomputing, software architectures.

Oliver Kopp is a research assistant and PhD student at the Universityof Stuttgart, where he got his Diploma degree (2005). In his PhD thesis,Oliver focuses on distributed transactions and global fault handling in servicechoreographies. His past projects include the Tools4BPEL project, whereanalysis tools for BPEL processes have been developed and the EU-projectCOMPAS, where compliance-driven models, languages, and architectures forservices have been researched. Currently, he is part of the CloudCycle project,where the focus is on provisioning and management of portable cloud-serviceswith guaranteed security and compliance throughout their complete lifecycle.

Esa Pitkanen is a postdoctoral researcher at the University of Helsinki inAaltonen lab, Genome-Scale Biology Program. He received a PhD degree inComputer Science in 2010 from the University of Helsinki.