Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions

doi:10.4236/jsea.2012.59084

Paper Menu >>

Journal Menu >>

Journal of Software Engineering and Applications, 2012, 5, 711-721

http://dx.doi.org/10.4236/jsea.2012.59084 Published Online September 2012 (http://www.SciRP.org/journal/jsea)

711

Towards an UML Profile for Web Service Composition

Based on Behavioral Descriptions

Ayoub Sabraoui1, Ahmed Ettalbi1, Mohammed El Koutbi1, Abdeslam En-Nouaary2

1Mobile Intelligent Systems Team (MIS), Ecole Nationale Supérieure d’Informatique et d’Nalyse des Systèmes (ENSIAS), Rabat,

Morocco; 2Electrical and Computer Engineering Department, Concordia University, Montreal, Canada.

Email: a.sabraoui@uca.ma, {ettalbi,elkoutbi}@ensias.ma, ennouaar@ece.concordia.ca

Received July 8th, 2012; revised August 11th, 2012; accepted August 23rd, 2012

ABSTRACT

Web service composition is one of the challenging issues that have been investigated over the past decade. It consists of

combining and reusing existing Web services to best suit new user requirements. This paper proposes an UML profile

to compose Web services based on their behavioral aspects. To do so, the web service WSDL files are first transformed

to UML models; then the profile is used to integrate them; finally the MDA approach is adopted to transform the ap-

plied profile into a BPEL process. As such, our method has the advantages of being independent of the Web service

composition language and the UML modeling tool. Finally, a case study is developed in order to show the benefits of

our method.

Keywords: Web Service Composition; UML Profile; MDA; BPEL

1. Introduction

Nowadays, distributed applications are increasingly be-

ing developed in the context of Service Oriented Archi-

tecture (SOA), where the basic unit of computation is

called a service. The Web service technology remains the

standard means for building enterprise applications be-

cause it provides mechanisms that facilitates the interop-

erability between different software applications, and

their executions regardless of the underlying platforms

and/or frameworks [1]. According to W3C [2], a Web

service is defined as a software system designed to sup-

port interoperable machine-to-machine interaction over a

network. The technology basically articulates around the

following three components:

 Simple Object Access Protocol (SOAP) provides the

definition of an XML document, which can be used

for exchanging structured and typed information be-

tween service peers in a decentralized distributed en-

vironment [3].

 Web Services Description Language (WSDL) is an

XML format for describing network services as a set

of endpoints operating on messages containing either

document-oriented or procedure-oriented information.

The operations and messages are described abstractly,

and then bound to concrete network protocols and

message formats to define an endpoint [4].

 Universal Description, Discovery and Integration

(UDDI) focuses on the definition of a set of services

supporting the description and discovery of the Web

services available for clients, and the technical inter-

faces, which may be used to access those services [5].

As such, the Web service technology proposes a high

level of abstraction, which replaces the current models of

applications by a more modular and flexible architecture,

thus allowing their composition and their integration. All

these features help the enterprises overcome the difficul-

ties related to the cost and flexibility of the offered solu-

tions for the electronic exchange of information. More-

over, Web services have functional, non-functional, be-

havioural, and semantic characteristics. The functionality

of Web services is described using interfaces with input

and output parameters. The quality of services like per-

formance is described by the non-functional specification

usually given as cost, response time, availability, security,

reliability, and reputation. The behaviour states, how to

interact with the Web services, in terms of sequences of

input/output interactions, for instance. Web service se-

mantics describe the meaning of the services generally

through the usage of ontology. The description of Web

services exposes the main aspects that enable them to be

published, found, and used by other Web services. They

are also the key elements in composing the Web services

into new ones [6].

The composition of Web services (WSC for short) is

one of the key features advanced by the technology. It

consists of combining existing services to provide a

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions

712

richer new composite service to meet some user require-

ments. Such composition requires methods and lan-

guages for basic Web services integration, such as: XML,

XLANG, BPML, WSFL, WSCL, WSCI, BPEL4WS and

WS-CDL. The composition techniques can be classified

into two categories, namely: static service composition and

dynamic service composition. Static composition allows

the requestor to create an abstract model that should be

respected during the execution of the composed Web

service. While the dynamic composition enables select-

ing the atomic Web services automatically and combines

them to create an unlimited number of new Web ser-

vices.

Another way to classify WSC is with regard to the de-

gree of automation (manual, semi-automatic and auto-

matic). Manual composition is completely performed by

a human, semi-automatic composition is carried out with

human assistance, and automatic composition takes place

without any human involvement [6].

There is yet a third classification, which is based on

how the composition is specified, either by orchestration

or by choreography [7]. Orchestration consists of com-

bining available services by adding a central coordinator

(the orchestrator) that is responsible for invoking and

combining the single sub-activities, as illustrated in Fig-

ure 1.

Choreography, however, defines complex tasks via the

definition of the conversation that should be undertaken

by each participant, as shown in Figure 2.

This paper proposes a new method for composing

Web services by defining a “WSComposition profile”

which is an extension of the UML2.2 sequence diagrams

metamodel. The proposed method applies the MDA [8]

to generate the code of the composite Web service in

Business Process Execution Language (BPEL) [9].

Therefore, this profile allows us to represent the behav-

ioral characteristics of Web services, and provides an

easy way to design and compose Web services based on

their behavioral aspect. Basically, our approach consists

of three main steps. In the first step, existing simple Web

services are discovered and located in the Web services

registry. The developer imports the WSDL files of the

Web service 1Web service 2

Coordinate web service

Figure 1. Web services orchestration.

Web service 3Web service 2

Web service 3

Figure 2. Web services choreography.

candidate services and translates them into UML dia-

grams (class diagram and use case diagram). In the sec-

ond step, the modeling of the composite Web services is

allowed by our WSComposition profile. In the third step,

the MDA approach is adopted to automatically transform

the applied profile into a BPEL process. The MDA

transformation rules are expressed in Atlas Transforma-

tion Language (ATL) [10].

Among the composition languages, we chose BPEL

(or BPEL4WS) because it is an XML-based language

and describes the business process interactions based on

Web services, within and between enterprises. A BPEL

process specifies the exact order in which participating

Web services should be invoked. This can be done se-

quentially or in parallel. With BPEL, we can express

conditional behavior; for example, a Web service invoca-

tion can depend on the value of a previous invocation.

We can also construct loops, declare variables, copy and

assign values, define fault handlers, and so on. By com-

bining all these constructs, we can define complex busi-

ness processes in an algorithmic manner [11].

Compared to existing WSC approaches, our method

has the advantages of being independent of both the

WSC language and the UML modeling tool; the user can

implement our WSComposition profile in any UML de-

sign tool, choose any language of composition and any

execution engine to compose services.

Our method offers also a semi-automatic way to com-

pose Web services by assisting the user in the design

stage. It allows the user to maintain some control over

the process with no need for programming knowledge. In

other words, the user can define the modeling and design

process in a graphical way through the WSComposition

profile in order to compose Web services.

The remainder of this paper is structured as follows:

Section 2 gives an overview of the fundamental aspects

on which our proposal is based. Section 3 describes the

WSComposition profile. Sections 4 and 5 present the key

ideas of our approach for WSC. Section 6 gives a case

study for the application of our method. Section 7 is de-

voted to related work. Finally, Section 8 concludes the

paper and presents future work.

2. Our UML Profile for Web Services

Composition

Our aim of designing an UML profile for WSC, is to

provide a standard means for expressing the semantics of

WSC using UML2.2 notation and thus to support ex-

pressing these semantics with UML tools. In addition,

the profile allows a mechanism to model a WSC inde-

pendently of the underlying platforms. Basically, our

UML profile relies on two main levels of abstraction: At

the higher level we have the metamodel of UML2.2 se-

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions

713

by two stereotypes: “Actor” and “WebService”. The lat-

ter stereotype is specialized by the “CordinateWS” one,

which represents the business process.

quence diagrams that defines the basic entities of the

model, whereas at the second level, we have the WS-

Composition UML profile which adapts the previous

metamodel for WSC. On the other hand and in order to manage the mes-

sages exchanged between client and services or those

invoked from other services, we extend the Message

class in three stereotypes: Receive, Reply and Invoke.

2.1. The Metamodel of UML2.2 Sequence

Diagrams

“Receive” element allows business process to wait for

a matching message to arrive. This stereotype has a filled

arrow head.

Here, we present the sequence diagrams metamodel

which constitutes a type of the interaction package of

UML2.2 metamodel. To define our profile we use the

Lifeline, Message and Combined Fragment classes as

defined in OMG UML2.2 [12]: A lifeline is a Named

Element that represents an individual participant in the

Interaction. While Parts and Structural Features may

have multiplicity greater than 1, Lifelines represent only

one interacting entity. Message, however, is a Named

Element that defines one specific kind of communication

between lifelines of an interaction. The message specifies

not only the kind of communication, but also the sender

and the receiver. Sender and receiver are normally two

occurrence specifications (points at the ends of mes-

sages). Finally, combined fragment is an interaction

fragment which defines a combination (expression) of

interaction fragments. A combined fragment is defined

by an interaction operator and corresponding interaction

operands. Through the use of combined fragments the

user will be able to describe a number of traces in a

compact and concise manner.

“Reply” element allows the business process to send a

message in reply to a message that was received by “re-

ceive” stereotype. It has a dashed line with open arrow

head.

“Invoke” element allows the business process to in-

voke a one-way or request-response operation on a port-

type offered by a partner. In the request-response case,

the invoke activity completes when the response is re-

ceived. This stereotype has an open arrow head.

Finally and for managing the workflow of the business

process, we extend the Combined Fragment class in the

“Control Flow” stereotype, which contains an enumera-

tion designating the different kinds of control flow ele-

ments, like sequential, parallel, alternative and iterative

activities.

Beside the aforementioned steretypes, our UML pro-

file uses the enumerated type Activity Element Kind de-

fines a set of available activity types. They are presented

as follows:

2.2. WSComposition UML Profile Sequential activity: defines a list of activities to be per-

formed sequentially in lexical order.

This section presents the WSComposition UML Profile

which is a group of extensions of UML2.2 sequence dia-

grams metamodel. We present some elements that we

extend and specialize to define our Profile, as shown in

Figure 3. On the one hand, we extend the Lifeline class

Parallel activity: specifies one or more activities to be

performed concurrently.

Alternative activity: is used to select one activity for

execution from a set of choices.

1..*

{required}

« stereotype »

WebService

« stereotype »

Coordinat eWS

« stereotype »

Actor

+ interaction 1

+ lifeline *

CombinedFragment

ActivityElement :ActivityElementKind

Sequential

Parallel

Alternative

Iterati ve

<<enumeration>>

ActivityElementKind

Interaction

InteractionOperand

Condition

0..1

« stereotype »

Receive

« stereotype »

Invoke

0..1

« stereotype »

ControlFlow

Message

Lifeline

<<profile>>

WSComposition profile

Figure 3. Excerpt of the WSComposition UML profile.

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions

714

Iterative activity: is used to define that the child activ-

ity is executed while the condition evaluates to true.

3. Our New Method for WSC

This section presents the key ideas of our method to

compose Web services. In our approach, interactions

with a services are modeled as scenarios, thus the com-

position of web services is none other than the composi-

tion of those scenarios. Knowing that the scenario de-

scribes the behavior of a system, our approach is based

on the behavioral characteristics of web services to

compose them. For this reason, we propose two graphical

ways:

3.1. Composing Scenarios Using Operators

In [13], we defined four operators, namely: the sequential,

the alternative, the iterative and the concurrent operators.

The idea consists of composing scenarios that models

partial behaviors using these operators, in order to obtain

one scenario that represents a global behavior of the sys-

tem. Figure 4 shows the graphical application that we

developed to compose scenarios [13].

In this example, we compose three scenarios S1, S2

and S3 as following:

par{S1;or{S2;S3;Price>1000}}

This means S2 and S3 are composed alternatively and

the result is executed concurrently with S1.

3.2. Composing Scenarios Using the

WSComposition UML Profile

Our WSComposition profile Figure 3 extends the UML

2.2 sequence diagrams metamodel and customizes it for

specific requirement of web services composition.

WSComposition profile presents a multiple operators to

model the order of execution of scenarios (interactions

with services). This is the method adopted in this paper

and which we explain in more details in the next sections.



Figure 4. Graphical interface for scenarios composition.

The resulting composite scenario from the application

of each of the two ways represents the composite Web

service which satisfies the client needs.

The interaction between the user and any requested

service can be clearly represented by sequence diagrams

(scenarios) in UML. Consequently, the services compo-

sition amounts composing these scenarios to meet the

client needs. Thus, the idea is to model the WSC by

WSComposition profile which is an extension of the

UML2.2 sequence diagram metamodel and to adopt the

MDA approach to automate the generation of BPEL

process execution code corresponding to the resulting

composite Web service. Our method is independent of

the WSC language and the UML modeling tool. Thus,

the user can choose the UML design tool, the language of

composition and the execution engine to make his/her

composition. In the current version, our method supports

the BPEL language and the EclipseUML tool for UML

design. Figure 5 presents the various steps of our com-

position method.

1) Searching for candidate Web services: the Web

services are searched and located in the Web service reg-

istry. The developer imports the service description rep-

resented in WSDL and translates it into UML diagrams:

classes diagram, use case diagram and sequence dia-

grams.

2) Composition of Web services: in this step the de-

signer use the WSComposition profile to manage the

workflow of the business process. The interaction be-

tween these services and their execution order are mod-

eled by the interaction operators defined in this profile.

3) Adopting the resulting scenario to the WSCompo-

sition UML Profile: the resulting scenario created in the

previous step is in XMI format. This file does not comply

with the WSComposition profile that we will use in the

next step to transform models (WSComposition2BPEL)

according to MDA approach.

Therefore, the purpose of this step is to transform this

XMI file to another one according to our profile. The

advantage of this first transformation is to allow the use

Presentation

of services in

UML

WSDL of composite

web service

Discover web

services

WSDL

Web services composition

Composition

operators

BPEL

processus

Transformation

tool

Adaptation of the

resulting scenario

WSComposition

Profile

Figure 5. Steps of our WSC method.

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions 715

of other UML modeling tools than EclipseUML; and

than make the application independent of the used tool.

This transformation is done by the JDOM API [14].

4) Transforming the applied profile into a BPEL

process: in this stage, we adopt the MDA approach to

transform the applied profile into a BPEL process repre-

senting the composite Web service. This transformation

requires the source metamodel (WSComposition profile)

and the target metamodel (BPEL metamodel), the ap-

plied profile, and the transformation rules which can be

expressed by one of the following transformation lan-

guages: OCL [15], YATL [16,17], ATL [10], etc. In our

approach, we choose the ATL language because it is easy

to use, close to the standards and there is a rich set of

tools that have been built for ATL development under

Eclipse.

4. Model Transformation

Mapping specification and defining transformations in

MDA is not an easy task. Authors in [18], proposed a

taxonomy of model transformation, based on the discus-

sions of a working group on model transformation of the

Dagstuhl seminar on Language Engineering for Model-

Driven Software Development. This taxonomy can be

used, among others, to help developers in deciding which

model transformation language or tool is best suited to

carry out a particular model transformation activity.

In this section, we present our proposition for the

specified transformation in the context of MDA. Ac-

cording to this approach, the source and target metamod-

els are based on a common metamodel MOF or EMF

Ecore [19]. The source metamodel is the WSComposi-

tion profile, and the target one is the BPEL metamodel.

This mapping is implemented as a tool on EclipseUML

IDE and the rules of transformation are defined using the

ATL language.

In order to enhance automatic mapping, we define the

rules for transforming the WSComposition profile into

BPEL process as follow:

Rule1 (process and partners): the CordinateWS ele-

ment constitutes the process element in BPEL process.

Actor and WebService elements are mapped to partner-

Links elements which present the different parties that

interact with the business process.

WSComposition

Profile Element

BPEL Process

Element Transformation

“CordinateWS” <process>

<process name="..."

targetNamespace="..."xmlns="..."

...

</process>

“Actor” and

“WebService” <partnerlinks>

<partnerLink name="…"

partnerLinkType="…"

partnerRole=".."myRole=".."/>

</partnerLinks>

Rule 2 (variable): Variable element defines the data

used by the exchanged message. It is mapped into vari-

able element of BPEL process.

WSComposition

Profile Element

BPEL Process

Element Transformation

“Variable”

...

</variables>

<variable name="..."

element="..." </variable>

</variables>

Rule 3 (exchanged messages): messages exchanged

between client and services or those invoked from other

services are mapped into receive, reply, or invoke ele-

ments of BPEL process.

WSComposition

Profile Element

BPEL

Process

Element

Transformation

“Receive” <receive>

<receive partnerLink="…"

portType="QName" operation="…"

variable="…" …

</receive>

“Reply” <reply>

<reply …

</reply>

“Invoke” <invoke>

<invoke …

</invoke>

In addition to these basis elements, we have defined

another five rules to transform the control flow into

BPEL elements. The details of these rules are given in

the following:

Rule 4 (sequential activity): Sequential activity de-

fines a list of activities to be performed sequentially in

lexical order, this element is mapped into sequence ele-

ment of BPEL process.

WSComposition

Profile Element

BPEL Process

Element Transformation

“Sequential” <sequence>

…

</sequence>

Rule 5 (parallel activity): Parallel activity is used to

specify one or more activities to be performed concur-

rently, this element is mapped into flow element of

BPEL process.

WSComposition

Profile Element

BPEL Process

Element Transformation

“Parallel” <flow>

<flow>

…

</flow>

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions

716

Rule 6 (alternative activity): Alternative activity is

used to select one activity for execution from a set of

choices. This element is mapped into if element of BPEL

process.

WSComposition

Profile Element

BPEL Process

Element Transformation

“Alternative” <if>

activity

activity

…

</while>

Rule 7 (iterative activity): Iterative activity is used to

define that the child activity is executed while the condi-

tion evaluates to true. The Iterative element is mapped

into while element of BPEL process.

WSComposition

Profile Element

BPEL Process

Element Transformation

“Iterative” <while>

activity

…

</while>

These transformation rules permit the mapping be-

tween two metamodels, which are the WSComposition

profile and the BPEL metamodel. The code in ATL is

generated based on this model transformation can help

the designer to specify how the metamodels are in-

ter-related. This model transformation can also help us to

define a bidirectional mapping, which will be investi-

gated in more details in future papers.

5. Case Study

In this section, we are going to illustrate the application

of our method through a case study. Suppose that a travel

agency proposes to its customers organized trips adapted

to their needs by composing appropriate existing Web

services. The proposed tours contain the transport, the

hosting and the car rent. When the customer decides to

reserve for a tour, he/she can make several choices to get

one of them. To this end, the customer gets access to the

web site of the travel agency which proposes tickets of

plan and train, the rental of cars and the hotel reservation.

Figure 6 presents the business process behavior, which

gathers the various tasks to be achieved by the composi-

tion.

Each reservation is related to a Web service. Services

run in this order with respect to the following conditions:

Flight reservation (WS1), if not train reservation

(WS2).

Hotel reservation (WS3).

Flight reservationTrain reservation

Hotel reservation

Car rent

Figure 6. Business process of the tourist tour reservation.

Car rent (WS4).

1) The first step of our approach: It consists of the

manual selection of the candidate Web services involved

in this composition. These services are represented as

UML diagrams (class diagram, use case diagram and

sequence diagrams) based on their WSDL files. This

allows the requirements capture [20] and the description

of the different interactions.

Figure 7 shows these Web services in terms of class

diagrams. Each diagram represents the Web service with

the operation signature invoked in our example:

The use case diagram in Figure 8 describes the inter-

actions between the user and the various services.

The client expresses his choices through the agency

travel system. Then, the agency system sends them to the

airline company, railways company, car rent company

and hotel reservation systems. Then, it receives the dif-

ferent responses from its partners and sends them back to

the user. Afterwards, the user makes his choice and com-

pletes his reservation.

From the use case diagram above, we can instantiate

some scenarios that are useful for our study. The se-

quence diagram in Figure 9 illustrates the different in-

teractions to book airline ticket.

These interactions remain valid for the other bookings.

For the sake of simplicity, we suppose that the reserva-

tion is made as shown in Figure 10.

2) The second step of our approach: The sequence

diagrams from the previous step give us an overview to

compose them using WSComposition profile, in order to

obtain a single diagram which represents the desired

composite Web service.

We return to our example to define the different sce-

narios of book in the following order and condition:

Booking an airline ticket (S1), if not a train ticket (S2)

 “alt” operator.

Booking hotel (S3) and car rental (S4) in parallel 

“par” operator.

We merge these scenarios to produce the resulting se-

quence diagram (Sr) of this composition, which repre-

sents the global behavior of the business process.

Then: Sr = alt(S1,S2)+par(S3,S4)

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions 717

FlightService

+findFlight(req): FlyList

+getRes(ville,ville,date): Res

CarServ ice

+findAuto(req): CarList

+getRes(date): Res

HotelService

+findChambre(req): RoomList

+getRes(date): Res

TrainService

+findTrain(req): TrainList

+getRes(ville,ville,date): Res

Figure 7. Class diagram of the travel agency.

User

Reservation

Flight reservation

Train reservation

Hotel reservation

Car rent

Figure 8. Use case diagram of the travel agency.

WS1: Flight reservationTravel agency

Request

Ticket List

Selection

Choice

Confirmation

User

Figure 9. Sequence diagram to book airline ticket.

WS1: Flight reservation

Get_res(A-City, B-City, Date)

User

Res_Ok

Figure 10. Simplified sequence diagram.

which mean that we compose S1 and S2 alternately, S3

and S4 in parallel and the two results will be composed

sequentially.

Figure 11 shows the sequence diagram resulting from

this composition.

3) The third step of our approach: The UML model-

ing tool used is the EclipseUML IDE, which permits to

create the different diagrams. These diagrams are in XMI

format. These files does not comply with WSComposi-

tion profile that we will use in the next step to transform

models (WSComposition2BPEL) according to MDA app-

roach. Therefore, the purpose of this step is to transform

this XMI file to another one according to our profile. The

advantage of this first transformation is to allow the use

of other UML modeling tools than EclipseUML; and

then make the application independent of the used tool.

4) The fourth step of our approach: In this step, we

adopt the MDA approach for transforming the applied

profile into BPEL process, which represents the compos-

ite Web service. The transformation definition must be

based on the correspondence between the WSComposi-

tion profile and BPEL models. The rules of transforma-

tion are defined in the ATL language. The transformation

process is illustrated in Figure 12.

In MDA, a metamodel defines the language and proc-

ess from which to form a created model, and all meta-

models are based on a common metamodel MOF or EMF

Ecore.

In this transformation we use the source—WSCompo-

WS1

Flight.Res

Act or

Res_Ok

WS2

Train.Res

WS3

Hotel. Re s

WS4

Car.Rent

Get_res(A, B, Date)

Res_Ok

Alternative Transport choice

Get_res(Date)

Res_Ok

Get_res(Date)

Res_Ok

ParallelHotel& Car

Cordinate

Make_Res ()

Res_Ok

[Aircraft.Price > 1000]

[Aircraft.Price < 1000]

Get_res(A, B, Date)

Figure 11. The applied profile resulting from composition.

Ecore

transformation

Conform to

Transformation

rules in ATL

BPEL Process

Conform to

BPEL Metamodel

Applied profile

WSComposition

profi le

Figure 12. Transformation process according the MDA

approach.

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions

718

sition profile- Figure 3 and the target—BPEL meta-

model-implemented in Ecore Figure 13.

isfy a single task, has received much attention recently.

Several approaches are proposed to compose Web ser-

vices. In this section, we discuss some of the existing

work that is most relevant to our approach.

The transformation rules from the applied profile to

BPEL process are illustrated in Figure 14.

The CordinateWS element represents the BPEL proc-

ess. Actor and the four Web services are transformed into

“partnerLink” elements.

Our work is most similar to the approaches presented

by [21,22], in which they describe a semi-automatic

process for WSC based on the behavioral aspect. They

propose a method that uses UML Activity models to de-

sign Web service, and MDA to generate executable

specifications in different composition languages. They

propose a metamodels for the target models, and present

case studies to prove the applicability of their methods to

compose Web services. Unlike our method which uses

UML sequence diagrams to design WSC assuming that is

close to the services concept. According to the behavioral

aspect, authors in [23], have formally defined the realis-

tic model for behavioral description, and studied the

computational complexity of four variations of WSC

problems: 1) solving the composition problem of deter-

ministic Web services for a restricted case (when the

coordinator Web service has complete information about

the states of all Web services) is PSPACE-complete; 2)

solving the composition problem of deterministic Web

services for a general case (when the coordinator Web

The Alternative and Parallel control flow elements of

profile are transformed into “if” and “flow” activities of

BPEL process respectively. Both activities are included

in the main activity process named “sequence”.

The Alternative element transformed into “if” activity

contains two blocks: the first is transformed into “if” and

its condition, the second into “else if” and his condition.

The Parallel element is also composed of two blocks

which are transformed into two “sequence” activities

included in the “flow” one.

Finally, the different messages exchanged between

CordinateWS, Actor and Web services are transformed

into “receive”, “relpy” and “invoke” activities depending

on the appropriate context.

6. Related Work

The problem of combining multiple web services to sat-

1..*

partnerLink

name

partner LinkT ype

variable

name

from

messageType

messageExchange

name

catch

faultName

faultVariable

catchAll

correlationSet

name

proprieties

onEvent

partnerLink

…

onAlarme

extension

nameSpace

mustU nd e rs ta nd

import

nameSpace

location

importType

name

targetNameSpace

partnerLinks

variable s

messageExchanges

faultHandlers

correlationSets

eventHandlers

extensions

Process

sequence

exit

1..*

0..*

0..1

1..*

0..*

1..*

0..1

1..1

wait

invoke

empty

repeatUntil

pick

forEach

compensateScope

assign

rethrow

validate

throw

scope

while

extensionActivity

ifflow

links

link

0..1

1..*

condition

elseif

else

1..1

0..*

0..1

compensate

receive

0..*

Figure 13. A metamodel of the BPEL 2.0 process.

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions 719

WS1

Flight.Res

Get_res(A, B, Date)

Actor

Res_Ok

WS2

Train.Res

WS3

Hotel.Res

WS4

Car.Rent

Get_res(A, B, Date)

Res_Ok

Alternative Transport choice

[Aircraft.Price < 1000]

[Aircraft.Price > 1000]

Get_res(Date)

Res_Ok

Get_res(Date)

Res_Ok

ParallelHotel & Car

Cord inateWS

Make_Res ()

Res_Ok

<?xml version="1.0" encoding="ISO-8859-1"?>

</partnerLinks>

</e ls e i f >

</if>

</sequen ce>

</sequen ce>

</flow>

</sequen ce>

</process>

WS1

Flight.Res

Get_res(A, B, Date)

Actor

Res_Ok

WS2

Train.Res

WS3

Hotel.Res

WS4

Car.Rent

Get_res(A, B, Date)

Res_Ok

Alternative Transport choice

[Aircraft.Price < 1000]

[Aircraft.Price > 1000]

Get_res(Date)

Res_Ok

Get_res(Date)

Res_Ok

ParallelHotel & Car

Cord inateWS

Make_Res ()

Res_Ok

<?xml version="1.0" encoding="ISO-8859-1"?>

</partnerLinks>

</e ls e i f >

</if>

</sequen ce>

</sequen ce>

</flow>

</sequen ce>

</process>

Figure 14. Transformation of the applied profile into BPEL process.

service has incomplete information about the states of

Web services) is EXPSPACE-complete; 3) solving the

composition problem of non-deterministic Web services

on complete information is EXP-complete and 4) solving

the composition problem of nondeterministic Web ser-

vices on incomplete information (which is the most gen-

eral case) is 2-EXP-complete.

There is another stream of work [24,25] which consid-

ers non-functional aspect like the quality-of-service (QoS)

and the optimization of the WSC problem. In this paper,

QoS parameters are not taken into account in the process

for composing Web services. In another study, we can

take into consideration the user needs in terms of QoS at

the design stage, by extending our WSComposition pro-

file.

The approach in [26] is different from the other exist-

ing work and this paper. It proposes a natural language

interface to Web services, which can be used even by a

novice user who does not know Web service technolo-

gies. Given a user’s natural language request to a com-

posite service, the method generates an abstract work-

flow, which describes the constituent tasks and their

transitions in a composite service. In the design step, our

method gives two graphical ways based on the sequence

diagrams which make it simple and understandable by

even non experienced users.

The semantic approach [27-29] describes the meaning

of the services based on the ontology. It gives a defini-

tion of an automated services composition and discusses

their limitations. In our proposal, the semantic aspect is

not taken into account. Consequently, semantic descrip-

tion presents a good way to increase the automation de-

gree of our method.

Compared to the aforementioned composition methods,

which mainly take into consideration either the semantic

aspect using ontology, the functional aspect which is

described using interfaces with input and output parame-

ters or the non-functional aspect such as QoS, our ap-

proach is essentially based on the behavioral aspect using

WSComposition profile in a graphical way to compose

Web services.

Table 1 shows a brief comparison of some approaches

cited in this paper and our approach.

7. Conclusion and Future Work

This paper introduced a new method for WSC. The pro-

posed approach is based on MDA, and consists of using a

WSComposition profile to model WSC and to generate

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions

720

Table 1. Comparison between WSC approaches.

Approaches Degree of automation Design type Aspect Based modeling Output format language

Our approach Semi-automatic Graphical Behavioral Sequence diagram BPEL

Skogan approach Semi-automatic Graphical Functional Activity diagram BPEL and WorkSCo

Bordbar approach Semi-automatic Graphical Behavioral Activity diagram BPEL

Ko approach Automatic Interactive Non-functional and

semantic client-friendly manner OWL-S

Lim approach Automatic Natural languageSemantic Workflow OWL-S

Yue approach Automatic Graphical Semantic and

non-functional OWL-S Colored Petri Nets

an executable model (BPEL process) through transfor-

mation rules, expressed in ATL. The case study pre-

sented here proves the applicability of our method for

WSC.

The existing simple Web services are discovered and

located in the Web service registry. The developer im-

ports the WSDL files of the candidate services and

translates them into UML diagrams (class diagram, use

case diagram and sequence diagrams). A WSComposi-

tion profile extending the UML2.2 sequence diagrams

metamodel is defined; it allows the developer to model

the composition of the Web services basing on the be-

havioral aspects. The MDA approach is adopted to

transform the applied profile into a BPEL process. The

transformation and rules are expressed in ATL to achieve

a mapping from WSComposition profile to BPEL.

Our method has several advantages. It is graphical,

which allows the developer to import descriptions of

exiting Web services (WSDL) and represent them clearly

in class diagrams. Furthermore, our approach is based on

UML but it is independent of the UML modeling tools

and the WSC language used. Another advantage is that

our method gives a semi-automatic way to generate a

BPEL process by adopting the MDA approach. These

features are the keys that make our method simple and

understandable by even non experienced users.

For future improvements, we will study the possibility

to extend our WSComposition profile to take into con-

sideration the user needs in terms of QoS. We will look

into the possibility of using semantic Web services to

automate Web services finder and to offer a better preci-

sion on existing services. Our mapping method is unidi-

rectional, we study the possibility to make it bidirectional

in order to enhance the automation degree.

REFERENCES

[1] W3C Working Group, “Web Services Architecture,”

2004. http://www.w3.org/TR/ws-arch/

[2] W3C Working Draft, “Soap Version 1.2 Part0: Primer,”

2001.

http://w3.org/TR/2001/WD-soap12-part0-20011217

[3] W3C Note, “Web Services Description Language (WSDL)

1.1,” 2001. http://www.w3.org/TR/wsdl

[4] UDDI Spec Technical Committee Draft, “UDDI Version

3.0.2,” 2004.

http://www.oasis-open.org/committees/uddi-spec/doc/spe

c/v3/uddi-v3.0.2-20041019.htm

[5] R. Karunamurthy, “Web Service Composition: Architec-

ture, Frameworks, and Techniques,” Ph.D. Thesis, Con-

cordia University, Montreal, 2009.

[6] C. Pahl and Y. Zhu, “A Semantical Framework for the

Orchestration and Choreography of Web Services,” Elec-

tronic Notes in Theoretical Computer Science, Vol. 151,

No. 2, 2006, pp. 3-18. doi:10.1016/j.entcs.2005.07.033

[7] Object Management Group, “MDA Guide Version 1.0.1,”

2003.

[8] OASIS Standard, “Web Services Business Process Exe-

cution Language Version 2.0,” 2007.

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-O

S.html

[9] ATLAS group LINA & INRIA, “ATL: Atlas Transfor-

mation Language,” Version 0.2, 2005.

http://www.uio.no/studier/emner/matnat/ifi/INF5120/v05/

undervisningsmateriale/

[10] M. Juric, “Business Process Execution Language for Web

Services,” Packt Publishing Ltd., Birmingham, 2004.

[11] Object Management Group, “OMG Unified Modeling

Language (OMG UML) Superstructure, Version 2.2,”

2009.

http://www.omg.org/spec/UML/2.2/Superstructure/PDF

[12] A. Jakimi, A. Sabraoui, M. Elkoutbi and A. Idri, “A New

Approach for Composing UML Scenarios and Code

Generation,” Proceedings of the IEEE 4th International

Conference on Sciences of Electronics, Technologies of

Information and Telecommunication, Hammamet, Tuni-

sia, 25-29 March 2007.

[13] “JDOM, Version 2.0.0,” 2012. http://www.jdom.org/

[14] Object Management Group, “Object Constraint Language,

OMG Available Specification, Version 2.0,” 2006.

http://www.omg.org/spec/OCL/2.0

[15] O. Patrascoiu, “YATL: Yet Another Transformation Lan-

guage,” Proceedings of the 1st European MDA Workshop,

Towards an UML Profile for Web Service Composition Based on Behavioral Descriptions 721

MDA-IA, University of Twente, Enschede-Noord, 2004,

pp. 83-90.

[16] O. Patrascoiu, “Model Transformations in YATL. Studies

and Experiments,” Technical Report No. 3-04, University

of Kent, Kent, 2004.

[17] T. Mens, P. Van Gorp, D. Varró and G. Karsai, “A Tax-

onomy of Model Transformation,” Electronic Notes in

Theoretical Computer Science, Vol. 152, 2006, pp. 143-

159. doi:10.1016/j.entcs.2005.10.022

[18] D. Steinberg, F. Budinsky, M. Paternostro and E. Merks,

“EMF: Eclipse Modeling Framework,” 2nd Edition, Ad-

dison-Wesley Professional, New York, 2008.

[19] I. Jacobson, M. Christerson, P. Jonsson and G. Overgaard,

“Object-Oriented Softaware Engineering: A Use Case

Driven Approach,” Addison-Wesley, New York, 1992.

[20] D. Skogan, R. Grønmo and I. Solheim, “Web Service

Composition in UML,” 8th IEEE International Enterprise

Distributed Object Computing Conference, Monterey,

20-24 September 2004, pp. 47-57.

[21] B. Bordbar and A. Staikopoulos, “Modelling and Trans-

formation of Behavioural Aspects of Web Services,” 3rd

Workshop in Software Model Engineering (WiSME), Inc

Conjunction with UML, 2004.

[22] W. Nam, H. Kil and D. Lee, “On the Computational

Complexity of Behavioral Description-Based Web Ser-

vice Composition,” Theoretical Computer Science, Vol.

412, No. 48, 2011, pp. 6736-6749.

doi:10.1016/j.tcs.2011.04.020

[23] J. M. Ko, C. O. Kim and I. H. Kwon, “Quality-of-Service

Oriented Web Service Composition Algorithm and Plan-

ning Architecture,” The Journal of Systems and Software,

Vol. 81, No. 11, 2008, pp. 2079-2090.

doi:10.1016/j.jss.2008.04.044

[24] B. Zibanezhad, K. Zamanifar, R. Sadjady and Y. Ras-

tegari, “Applying Gravitational Search Algorithm in the

QoS-Based Web Service Selection Problem,” Journal of

Zhejiang University, Vol. 12, No. 9, 2011, pp. 730-742.

[25] J. Lim and K. Lee, “Constructing Composite Web Ser-

vices from Natural Language Requests,” Web Semantics:

Science, Services and Agents on the World Wide Web,

Vol. 8, No. 1, 2010, pp. 1-13.

doi:10.1016/j.websem.2009.09.007

[26] Y. Ni and Y. S. Fan, “Model Transformation and Formal

Verification for Semantic Web Services Composition,”

Advances in Engineering Software, Vol. 41, No. 6, 2010,

pp. 879-885. doi:10.1016/j.advengsoft.2010.01.005

[27] H.-N. Talantikite, D. Aissani and N. Boudjlida, “Seman-

tic Annotations for Web Services Discovery and Compo-

sition,” Computer Standards & Interfaces, Vol. 31, No. 6,

2009, pp. 1108-1117. doi:10.1016/j.csi.2008.09.041

[28] S.-H. Yeganeh, J. Habibi, H. Rostami and H. Abolhassani,

“Semantic dweb Service Composition Testbe,” Com-

puters & Electrical Engineering, Vol. 36, No. 5, 2010, pp.

805-817. doi:10.1016/j.compeleceng.2008.04.007