A Model-Driven Approach to Service Composition in Virtual Enterprises

Khalid Belhajjame and Suzanne M. Embury School of Computer Science

University of Manchester Oxford Road, Manchester, UK

{Khalid.Belhaj j ame,Suzanne .Embury)@cs .man. ac.uk

Abstract

This paper proposes a model driven approach whereby a composite service specification is generated automatically from a simple declarative definition. I t i s based o n three concepts: services, virtual enterprises and business rules. Using a n e-travel application as a running example we explain in detail the steps of the generation process. Particularly, we show how business rules can be used for creating o n the jly the controlflow relating the services constituting the composite service.

1 Introduction

Model driven programming is gaining momentum as a new methodology for facilitating the development of Web information systems. It promises to relieve the developer from low level programming complexity, by providing high-level abstract constructs that enable him/her to focus on the design of the core functionality of the target application. In this direction, this work proposes a model-driven approach for mechanising ser- vice composition in the context of virtual enterprises.

Approach Overview According to our solution, services are grouped and managed using virtual en- terprise concept. A service provider willing to pro- vide access to its service contacts the virtual enterprise through its administrator. Services belonging to a vir- tual enterprise are not independent from each other and their dependencies are captured in the form of business rules. For example, a business rule may state that a service sl must not be executed together with another service sz. Business rules are specified among services belonging to the same virtual enterprise.

Unlike current proposals, in our approach composite service are not specified directly using a workflow-based language such as BPEL or WSFL [2]. Rather, they are generated automatically out of a declarative definition. The user defines the desired composite service by pro- viding the set of participating services that will take part in its execution. Using the business rules of the associated virtual enterprise, the list of participating services is expanded and the controlflow relating them is derived. The salient features of our approach are: - Declarative definition of composite services, a composite service is not specified procedurally, rather it is defined declaratively (6 la SQL). The developer does not hwc to specify the controlfiow nor the dataflow re- lating the component services. The composite service definition consists simply of the list of participating services. - Automatic generation, given a declarative defini- tion, the composite service specification is generated automatically. - The use of virtual enterprise concept, such an ab- straction is extremely important. It is used for aggre- gating services that provide (eventually) complemen- tary functionalities, thereby providing means for com- posing them to construct added value services (appli- cations). Most importantly, in our approach a virtual enterprise is enforced by the concept of business rule whereby the associations among the constituent ser- vices are specified. Such associations act as the guide- lines during the process of composition.

The remainder of this paper is organised as follows. Section 2 introduces the concepts that form the basis of our approach. Sections 3 and 4 present the mod- els for specifying virtual enterprises and composite ser- vices, respectively. Section 5 presents in details the al- gorithms we propose for generating composite services.

IEEE International Conference on Services Computing (SCC'OG) 0-7695-2670-5/06 $20.00 O 2006 IEEE

COMPUTER SOCIETY

Finally, Section 6 concludes the paper by analysing and composite service whose constituent services belong to comparing existing work with ours, and discussing our e-travel virtual enterprise, and that is used for organ- ongoing work. ising personal travels.

2 Basic Concepts Rent a car

Explore nlghir Bmk a tltght ) < Wtthdraw 0

This section introduces the concepts that are cen- B a k s man

tral to our solution, namely virtual enterprise, service, and business rule.

Virtual Enterprise It is a structure that is used for modelling the aggregation of service providers (com- panies) that share, federate and perform their services in a coordinated manner for building new added-value services. As a running example, we consider e-travel, a virtual enterprise that includes travel related com- panies (see Figure 1). It involves a flight server that manages and books flights, a cruise store for booking cruises, a travel insurance company that covers medical services, a bank for executing payment transactions, a hotel for booking accommodation, and a car rental ser- vice for booking a car on-line.

El.#ozz armhM,,7,@"5 Perform a p y m m l msmnom

__C_-- r"- Bank

Figure 1. Virtual enterprise

Basic Service and Composite Service A service abstracts an action that is undertaken by one or several service providers. We identify two types of services, basic and composite. A basic service is performed by an individual service provider. A composite service is the combination of multiple basic services. Different from a basic service, a composite service is used to ful- fil functionalities that cross the boundaries of a single company to involve the information systems of multiple companies. A composite service is commonly defined as a workflow in which the activities encompass calls to (basic) web services and the controlflow specifies their dependencies. We refer to the basic services that are involved within a composite service using the term con- stituent services. Figure 2 illustrates an example of a

IEEE International Conference on Services Computing (SCC'O6) 0-7695-2670-5106 $20.00 O 2006 IEEE

Figure 2. Composite service

Business Rule Services belonging to a given virtual enterprise are related to each other using business rules. Such rules define the policies/constraints to be consid- ered when modelling composite services. They can take a number of forms. For example, a business rule can be used to define a policy, e.g., software tests must be carried out by a service provider that is independent of the development group. Also, a business rule may be used to assign responsibilities and prescribe which service provider can do what, e.g., assigning a service execution to the provider ensuring the shortest execu- tion time among available providers.

Since in the present work we are particularly con- cerned with services composition, we limit ourselves to business rules that define controlflow constraints among services. Such rules are used to regulate and avoid incoherent synchronisation of the services belong- ing to a given virtual enterprise. Consider for example Explore flights and Book a flight services, the input data of Book a flight is the output data of Explore flights. An ex- ample of business rule that is used for expressing such a relationship is the Succession business rule, succession ('Explore flights'.'Book a flight'). It states that Book a flight must be called after executing Explore flights.

3 Modelling Virtual Enterprises

This section presents the model we propose for for- mally representing virtual enterprises.

Definition 3.1 (Virtual enterprise). A virtual enter- prise VE is a tuple VE = (nameVE, desc, services. BRs ), where: - nameVE is a String that identifies the virtual enterprise VE, - desc is a textual description that outline the purpose behind the virtual enterprise, - services is the set of basic services that are involved in VE, - BRs is the set of business rules that relates services.

0

SOCIETY

Definition 3.2 (Basic service). A basic service S is a tuple S = (names, desc, nameOp, input, output), where: - names is a String that identifies S,

- desc is a textual description of S,

- nameOp is a String that identifies the operation sup- plied by S,

- input is a set of typed data variables representing S

input, - output is a set of typed data variables representing S

output.

Business Rule A business rule defines a dependency between two services. We identify three types of busi- ness rule: succession, conjunction and exclusion.

Definition 3.3 (Business rule). A business rule BR is a tuple BR = (typeBR. desc, nameS1, names2), where: - typeBR is a type of business rule. - desc describes the rational behind the business rule. - names1 is a name of a service. - names2 is a name of a service.

In order to illustrate the semantics of business rules, let sl and sz be two services. - Succession, s1 r, sz: means that the execution of sl must be followed by the execution of sz. Such a business rule is primarily used to establish a dataflow dependency, i.e. when input data of sz comprises output data of sl.

Two services s and s' can be also linked indirectly using a sequence of succession business rules: s P sl . . . sk P

s', where sl . . .sk are services and k > 0. We say that s' belong to the closure of s, and we write s , s'. More precisely, we write (s bk+l s') to specify that starting from s, the succession business rule is applied k + 1 times to obtain s'.

- Conjunction, s l CB sz: means that s l and sz must be executed together. If s l is called then sz must be called too, and vice-versa. It also states that they must be executed simultaneously. Conjunction business rule is used to express that s l and sz are complementary with respect to the functionality they fulfil within the virtual enterprise. - Exclusion, sl @, 52: either sl or sz can be invoked but not both of them. Different from Conjunction, such a business rule is used to express that sl and s2 fulfil unrelated or even contradictory tasks within the virtual enterprise. The exclusion business rule is associated with a predicate C whereby the decision of whether to execute sl or s2 is taken. Specifically, sl is selected for execution when C holds, and 52 is chosen when it does not. Table 1 lists the business rules that are associated to the e-travel virtual enterprise.

Bookplight @ t r a v e l ~ y p e = f i i g h t Bookcruise BookRoom CB BookCar BookRoom P Withdraw

Table 1. etravel business rules

/ BusinessRule 1 Successron sl D s2 1 Con!undion sl CB s2 1 Exclusion sl m.52 I

Figure 3. Control patterns derived from busi- ness rules

Our choice for the above business rule types has been driven by the need to derive controlflows for mod- elling composite services. Indeed, the defined business rules enable the expression of the main controlflow pat- terns [9]. Figure 3 illustrates the control patterns de- rived from every business rule. Succession business rule is transformed into the sequence control pattern expressing that the service sz is called after the com- pletion of the service sl. Conjunction business rule is transformed into an and-split control pattern followed by an and-join control pattern. Such patterns are used to model the parallel execution of the services s l and sz.

Finally, the exclusion business rule is transformed into an or-split control pattern followed by an or-join control pattern. They are used to model the exclusive choice between executing sl or s2.

4 Modelling Composite Services

This section presents the model we propose for for- mally representing composite services.

Definition 4.1 (Composite Service). A composite ser- vice CS is a tuple CS = (nameCS, nameVE, activities, ops,

cf), where: - nameCS is a String that identifies the composite ser- vice CS, - nameVE is the name of the virtual enterprise. The component services of CS must belong to it. - activities is a set of activities composing CS.

- ops is a set of ordering operators. - cf (activities u ops) x (activities u ops) is a set of di- rected edges that relate activities and ops. They define the controlflow among the component activities of the composite service CS.

lEEE International Conference on Services Computing (SCC'OG) 0-7695-2670-5106 $20.00 O 2006 IEEE COMPUTER

SOCIETY

Activity An activity represents a basic unit of work constituting a composite service.

Definition 4.2 (Activity). An activity A is a tuple A = (nameA, narneOp, input, output), where: - nameA is a name of the activity A. It corresponds to the name of the associated service. - nameOp is the name of the operation encompassed by A, it corresponds to the name of a service operation. A is identified by the couple (nameA,narneOp). - input is a set of data variables that represent A input. - output is a set of data variables that represent A out- put.

Controlflow The controlflow specifies the way the execution of a set of services is synchronised in time. It is defined used ordering operators.

Definition 4.3 (Ordering operator). An ordering op- erator OP is a couple OP = (typeOp, condition), where: - typeOp is a type of ordering operator. Five types of ordering operators are possible: sequence, and-split, and- join, or-split and or-join. - condition is used for conditional routing controlflows. As such it is only associated to ordering operators of type or-split and or-join. In the case of or-split, the con- dition is defined as a decision table in which an entry is composed of a predicate and an activity. In the case of or-join, it is defined as a predicate.

0

In order to specify the semantic of ordering operators, consider the activities (Al, Az,. . . , A,), the following controlflow expressions can be defined.

A1 seq Az: the execution of A1 causes the execution of A2. We say that A1 triggers A2.

A1 and-split (Az, . . ., A,): the execution of A1 triggers the activities Az, . . .,A,.

A1 or-split (Az, . . ., A,): the execution of A1 triggers a subset of the set {Az, . . ., A,]. Such a subset is determined by using the associated decision table. Specifically, they correspond to the table entries in which the predicates are evaluated to true.

(AI, . . ., A,-1) and-join A,: the execution of A1, . . ., and A,-1 triggers A,.

(A l , . . ., A,-1) or-join A,: the execution of a subset of A l . . . ., A,-I triggers A,. The corresponding subset contains activities A, (1 5 i 5 n - 1) that satisfy the or-join con- dition.

5 Generating Composite Services

This section presents the definition language we de- signed for declaratively defining composite services. It then details the process whereby a composite service is generated.

The structure of a composite service definition is as follows:

Create <composite service name> From <virtual enterprise> Using <service+> -

composite service name is a String that identifies the com- posite service. virtual enterprise is a String that identifies a virtual enterprise. services+ is a list of basic services. They represents the constituent services and belong to virtual enterprise. As an example, below is the definition - . of myTravel composite service. It involves five services that belong to the e-travel virtual enterprise: Explo- reAvailableFlights, BookCruise, lnsureMedicalServices, Book- Room and BookFlight.

Create rnyTravel From e-travel Using {ExploreAvailableFlights, BookCruise.

lnsureMedicalServices, BookRoom, BookFlight) Figure 4 illustrates the process whereby composite

services are generated. The first step consists in ex- panding its constituent services. Indeed, the definition provided by the user is not meant to specify all the services that are involved within the targeted compos- ite service. Rather it is used to specify a subset that is then augmented by using succession and conjunction business rules. Once the constituent services are iden- tified, they are organised into sequences that form the main branches of the composite service controlflow (De- fine branches). The third and fourth steps of the pro- cess establish the controlflows that connect the defined branches. Specifically, step 3 is used for connecting ex- clusive branches. Such branches are executed within the composite service only when certain conditions are met. Step 4 is used to link the rest of branches. Fi- nally, step 5 defines the activities encompassing calls to the constituent services.

Enlend constiluenl Define S ~ N ~ E C I sel lhe branches

Figure 4. Generation process

5.1 Expanding Constituent Services Set

Figure 5 presents the algorithm used for expanding the set of constituent services. Every service of the vir- tual enterprise that is associated with some elements of

IEEE International Conference on Services Computing (SCC'O6) 0-7695-2670-5106 $20.00 O 2006 IEEE SOCIETY

Algorithm Expand input: Services = Service[], VE = Virtual enterprise output: services = Service[] local: loop = boolean

begin 1 Loop = true 2 do { 3 if (3 s' E VE.Services/Services, 4 3 s E Services, (s 63 s') V (s D s')) 5 then Services := Services U {s'} 6 else loop := false ) 7 while (loop = true) end.

Figure 5. Expanding the set of constituent services

the composite service using either Succession or conjunc- tion business rules, (lines 3,4), becomes an element of the composite service, (line 5). For example, applying such such an algorithm to myTravel, added two services to its constituent services:

- BookCar, as BookRoom @ BookCar and Book- Car is a constituent service of myTravel.

-Withdraw, as BookFlight @Withdraw and Book- Flight is a constituent service of myTravel.

5.2 Defining the Branches

The constituent services are organised into se- quences that form the main branches of the composite service controlflow.

Definition 5.1 (Branch). A Branch B is defined as a sequence B = (SI,. . .,S,), n 2 1 such that:

1. \d i c {I,. . . ,n), Si represents a set of services,

2. S1 is a either a, singleton, or V s, s' E S1, s @ s',

3. If (n>l ) then (V k~ (1,. . .,n-l), V s E Sk+l, 3 S'E

Sk I S' D s),

Condition 2 states that the first element of the branch is either a set containing exactly one service, or, it is composed of more than one service. On the latter case, the constituent services are related to each other by conjunction business rules. Given two consecutive ele- ments Sk and Sk+l, condition 3 states that every ele- ment of Sk+l is associated to at least an element of Sk

using a succession business rule1. A branch cannot be extended in the sense that S1 and S, are the first and the last element that can be obtained using succession blisiness rule (conditions 4 and 5). myTravel compos- ite service is composed of three branches. Figure 6 represents them graphically. For example, Branchl is composed of four sets of services. It starts with the sin- gleton (ExploreAvailableFlights} and terminates with the singleton {Withdraw}. The elements of such a branch $re associated using succession business rule. Specif- ically, ExploreAvailableFlights D BookFlight, BookFlight D

BookCar, BookFlight D BookRoom, BookRoom P Withdraw, and BookCar P Withdraw.

Figure 6. Largest branches of myTravel com- posite service

Let B be a branch and s a service, if there exists S E B such that s E S, we say that s is a constituent service of B and write this as: s e 6. For example, in myTravel composite service, BookCar c Branchl.

5.3 Linking Exclusive Branches

This step defines controlflows that connect the branches to be executed in an exclusive manner within the composite service. Such branches are associated with a decision table composed of a set of predicates. Based on the evaluation of such predicates, one or sev- eral branches are chosen for execution. The following presents the functions that are used for identifying and linking exclusive branches.

ExclusiveBranches Given a branch B and a set of Branches Bs, ~ x c l u s i v e ~ r a n c h e s ~ is a function that se- lects and returns the list of Branches Bs' C Bs.

ExclusiveBranches: Branches x P(Branches) -+

?(Branches).

B ' E ExclusiveBranches(B, Bs) if B' E Bs and there exists an exclusion business rule relating one of its constituent services to a service belonging to B. Specificaly:

'/ stands for subtraction and I for such that 2?(E) denotes the power set of the set E

IEEE International Conference on Services Computing (SCC'O6) 0-7695-2670-5106 $20.00 O 2006 IEEE

COMPUTER SOCIETY

BranchesIntersection It is a partial function that given a set of Branches returns, if any exist, their first common element.

BranchesIntersection: m ranch^ - ?(Services).

Let B and B' be two branches, such that B = (51,. . .,S,) and B' = (S ' l , . . .,S',). Brancheslntersection (B.B') returns the first element S that belongs to both B and B',S E

(B n B'). Specifically:

Given a set of branches Branches={B~.. . .,B,) that have been produced by the Branches definition step (see sec- tion 5.2), The ExclusiveBranches function is used to identify for each of them the corresponding exclusive branches. Specifically:

For (i=l;i<n;i++) EB[i] = ExclusiveBranche (B,,Branches/Uj,l ... i {Bj})

Exclusive branches are linked by using conditional routing controlflows, using particularly or-split and or- join ordering operators. Such a process is iterative, and the number of iterations is equal to number of branches - 1. For example, in the case of mynavel composite service one iteration is required as the branches Branchl and Branch2 are exclusive: Book Flight @ Book cruise. Applying an iteration to such a branches results in the controlflow depicted in Figure 7. Note that the two branches have in common the activity Withdraw, as a result the or-join operator is shifted.

to the Branchl and Branch2 using an and-split and and-join operators as shown in Figure 8. Note that the and-join is shifted to the first common element Withdraw.

Figure 8. Linking independent branches of myTravel composite service

5.5 Creating Activities

In this step, the activities of the composite service are defined and associated to its constituent services. Defined activities encompass service calls. The ele- ments of every branch of the composite service are visited. If the branch element contains exactly one service, then an activity is created along with two se- quence operators. Such operators are defined as the activity input and output, respectively. In case the branch element contains more than one service then an activity is created and associated to every service. Then two ordering operators and-split and and-join are created and defined as the input and output of such activities, respectively. For example, Figure 9 depicts mynavel composite service. It is obtained by defining and assigning activities to the branches in Figure 8.

Branch I a Branch 2 I

Figure 7. Linking exclusive branches in my- Travel composite service Figure 9. myTravel composite service

5.4 Linking Independent Branches 5.6 Deriving Conditional Routing Decisions

In this steps, independent branches that are not This section describes the process of generating deci- connected to any conditional routing configuration are sions for conditional routing controlflows, particularly linked to the controlflow of the composite service. They or-split decision table and or-join condition. We consider are attached to such a flow by using a parallel routing B a Branch and EB its associated exclusive branches configuration. In the case of myTravel composite ser- connected using a conditional routing controlflow as vice, Branch3 is an independent branch. It is attached depicted in Figure 10.

IEEE International Conference on Services Computing (SCC'OG) 0-7695-2670-5106 $20.00 o 2006 IEEE SOCIETY

: . / I . ,

1 EBm . . - - . . . - .

Figure 10. Conditional routing controlflow

Or-Split Decision Table The or-split decision is made based on the evaluation of a routing predicate RP. The following illustrates how such a predicate is formulated. Let Cs be a set of predicates which are as- sociated to the exclusive business rules relating B con- stituent services to EB constituent services. Specifically

c E Cs If (3 s e B) A (3 B' E EB A s' 4 B') 1 s @, s'.

Let Cs = {cl . . .cl), the routing predicate RP is defined as RP = cl A . . . A cl. Table 2 represents the or-split de- cision table. It contains two entries. The first specifies that the branch B is triggered when the predicate RP holds. The second entry specifies that the branches EB are triggered when RP does not hold.

Table 2. Decision routing table

Predicate

R.P 1RP

Or-Join Condition The or-join condition is a de- fined as: Termination(B) V (V B' E EB, Termination(B1)) Meaning that or-join triggers its subsequent activities upon the termination of the execution of either the branch B or all its associated exclusive branches EB.

It is worth mentioning that the composite services generated using the proposed approach are well struc- tured [8]: they are deadlock free and their execution terminates once. For space sake we do not present the poof, however interested readers are referred to 141.

Triggered branches B

EB

5.7 Customisation

As mentioned before, the presented generation algo- rithm covers the essential controlflow patterns. Still, there are some aspects that require the intervention of the designer to adapt the obtained composite service to the design needs. For example, iterative loops are not supported by the generation algorithm, which is a

IEEE International Conference on Services Computing (SCC'O6) 0-7695-2670-5106 $20.00 O 2006 IEEE

well-suited mechanism for modelling repetitive enact- ment of the same branch within the workflow. Once a composite service is generated, the designer needs to manually specify the iterative loops as needed.

Also, in the generation process, it is assumed that every basic service is used once within the composite service. However, there are some applications that re- quire the instantiation of the same basic service mul- tiple times a t different execution points. This is not supported by our generation algorithm and as such the designer needs to manually modify the composite ser- vice.

Finally, the generated compositc service can in some cases be used for starting modelling the target com- posite service. Rather than starting from scratch, the user may prefer to begin with a generated compos- ite service specification which she then customises to meet her own needs. The customisation actions consist of adding/removing activities from the composite ser- vices, as well as specifying new dependencies between the activities and removing existing ones.

6 Related Work and Concluding Re- marks

The model driven approach is gaining considerable momentum as a paradigm for facilitating the develop- ment of web information systems. This section analy- ses and compares proposals that adopt such a paradigm for automating services composition with our work.

The Meteors framework [I] includes a tool whereby executable composite services are generated out of ab- stract processes. The abstract process is defined us- ing BPEL, the executable process is then generated by using a collection of constraints. For example, a constraint may state that a specific service supplier is preferred among a set of service providers. ESC [5] is a tool for service composition. A user specifies the com- posite service in terms of a state transition diagram in which the nodes represent the states of the compos- ite service and the arcs the actions performed during its execution. ESC is then used to associate the ac- tions (transitions) to Web services in charge of their execution. Though such works aims a t facilitating ser- vice composition task, they are different from our work in that they focus more on the problem of selecting web services responsible for executing the actions of the composite service and synthesising the composite service, rather than on automating the generation of the controlflow relating them. Indeed, in both ESC and meteors, the composite service specification is not declarative as the user must specify himself/herself the corresponding state diagram.

COMPUTER SOCIETY

[7] proposes an approach that assists the developers during the process of service definition and composi- tion. Using business rules, it assists the user in select- ing the required basic services and the way they can be composed. However, to our knowledge, the business rules are only used as guidelines and the generation process is not automated.

[6] and [lo] are perhaps the closest to our work in that they aim at automatically generating composite services from a declarative specification. [6] proposes an ontology-based framework for the automatic com- position of services. The developer provides a high level specification of the desired composite service. Us- ing compatibility rules, the composite service is gener- ated. [lo] adopts the same approach. Our work differs from these works in two respects. In our approach, the business rules express three kinds of relationships among services succession, conjunction and exclusion, used for expressing (explicitly using ordering opera- tors) the main existing controlflow patterns, namely the sequence, parallel execution and choice (exclusion). In both [GI and [10], the controlflow is derived only us- ing the succession relationship among services. Hence they do not support the (explicit) specification of the parallel and choice controlflow patterns. Instead, these are defined implicitly by associating preconditions and postconditions to every activity of the composite ser- vice. Regarding composite service soundness, although [6] provides means for defining templates by which gen- erated composite services can he verified, such tem- plates are not meant to check the structure of the generated composite service, but rather its business added-value. This means that structural conflicts such as deadlocks and multiple terminations still may take place.

In summary, this paper presented a model driven approach to services composition. It is based on three key concepts that are service, virtual enterprise and business rule. Generated composite services are well structured. It is possible that the generated service does not meet the specific requirements of the designer. In some cases, instead of building a new composite ser- vice from scratch, the designer might prefer to cus- tomize the already generated composite service, e.g., by addinglremoving some constituent services and their dependencies.

Service composition entails many issues other than the automatic composition. Service selection is partic- ularly among the most crucial aspects, in our proposals we assumed that the services tacking part within the composite services are known, however in practice such services still need to be discovered and selected. An- other related issue is that of service interoperability. In

our ongoing work we are investigating such a subject, particularly we are interested in identifying and resolv- ing the mismatches between connected service inter- faces (i.e. inputs and outputs) that a composite service may suffer from [3].

References

[I] Rohit Aggarwal, Kunal Verma, John A. Miller, and William Milnor. Constraint driven web service composition in meteor-s. In IEEE SCC, pages 23- 30, 2004.

[2] G. Alonso, F. Casati, H. Kuno, and V. Machi- raju. Web Services: Concepts, Architectures and Applications. Springer-Verlag, ISBN 3-540-44008- 9, 2004.

[3] K. Belhajjame, S. M. Embury, and N. W. Paton. On characterising and addressing mismatches in scientific workflows. In International Workshop on Data Integration in the Life Sciences (DILS 06). Springer, 2006.

[4] Khalid Belhajjame, Genoveva Vargas-Solar, and Christine Collet. Defining and coor- dinating open-services using workflows. In CoopIS,'DOA/ODBASE, pages 110-128, 2003.

[5] Daniela Berardi, Diego Calvanese, Giuseppe De Giacomo, Maurizio Lenzerini, and Massimo Me- cella. Esc: A tool for automatic composition of- services based on logics of programs. In TES, 2004.

(61 Brahim Medjahed, Athman Bouguettaya, and Ahmed K. Elmagarmid. Composing web services on the semantic web. VLDB J., 12(4):333-351, 2003.

[7] Bart Orriens, Jian Yang, and Mike P. Papazoglou. Model driven service composition. In ICSOC, pages 75-90, 2003.

[8] W. Sadiq and M. Orlowska. Analyzing process models using graph reduction techniques. Infor- mation Systems, 25(6):117-134, April 2000.

[9] Wil M. P. van der Aalst, Arthur H. M. ter Hof- stede, Bartek Kiepuszewski, and Alistair P. Bar- ros. Workflow patterns. Distributed and Parallel Databases, 14(1):5-51, 2003.

[lo] Liangzhao Zeng, David Flaxer, Henry Chang, and Jun-Jang Jeng. Plm flow-dynamic business pro- cess composition and execution by rule inference. In TES, pages 141-150, 2002.

IEEE International Conference on Services Computing (SCC'O6) 0-7695-2670-5106 $20.00 O 2006 IEEE

COMPUTER SOCIETY