WEB SERVICE COMPOSITION USING THE WEB SERVICES

MANAGEMENT LAYER

Niels Joncheere, Bart Verheecke, Viviane Jonckers

System and Software Engineering Lab (SSEL), Vrije Universiteit Brussel, Belgium

Soﬁe Van Hoecke, Gregory Van Seghbroeck, Bart Dhoedt

INTEC Broadband Communication Networks (IBCN), Universiteit Gent, Belgium

Keywords:

Aspect-oriented programming, brokering, performance and scalability measurement, web services.

Abstract:

The Web Services Management Layer (WSML) is an academic middleware platform that is placed in between

clients and web services. It takes care of dynamic integration, selection, composition and client-side manage-

ment of web services, thus removing the need to take care of these concerns in clients. This paper describes

how the WSML can be used to express web service compositions, and presents the results of a number of

experiments which evaluate the performance and scalability of the current WSML implementation. These

results show that the WSML induces only a small overhead compared to systems in which the WSML has not

been deployed. The advanced features of the WSML therefore come a low cost in terms of performance and

scalability, which makes it a viable option in real-life web services applications.

1 INTRODUCTION

An important domain in web services research is the

design and development of languages that clearly and

naturally describe the logic of web service composi-

tions. This has given rise to a number of dedicated

web service composition languages, most of which

are based on earlier research on workﬂow languages

(Du and Elmagarmid, 1997). Currently, the most pop-

ular web service composition language is the Business

Process Execution Language (BPEL) (Andrews et al.,

2003). BPEL processes are platform- and transport-

independent, and are expressed using XML.

In current dynamic web services environments,

web services are offered by different service

providers. This poses a variety of challenges for the

clients of these services:

• Redirection. Services can become unavailable due

to service or network issues, services may be re-

placed by newer versions or taken out of business,

syntactical and semantical mismatches can occur,

etc. The clients need to be able to communicate

with services that were not known at development

or deployment time, and possibly compose ser-

vices together if necessary.

• Selection. Multiple services may offer the same or

similar functionality. In this case, a client must be

able to swap transparently to another service when

this service better suits the needs of the client.

The selection of the most optimal service can be

based on non-functional business requirements of

the client (e.g. preferring a cheaper service over

a faster one), or may be part of a load balancing

strategy such as round-robin, broker-side monitor-

ing, and server-side monitoring.

• Client-side management. Web services impose a

variety of requirements on clients such as com-

plying with an encryption protocol, performing

a pre-payment or following a speciﬁc authenti-

cation protocol. These concerns may vary from

service to service and from time to time. Fur-

thermore, clients may want to perform logging,

caching, pre-fetching, monitoring, etc. when they

engage in service communication.

This paper discusses web service composition in

the context of the Web Services Management Layer

(WSML). The WSML is an academic middleware

platform for dynamic integration, selection, composi-

tion and client-side management of web services, and

is based on aspect-oriented techniques. The WSML

109

Joncheere N., Verheecke B., Jonckers V., Van Hoecke S., Van Seghbroeck G. and Dhoedt B. (2008).

WEB SERVICE COMPOSITION USING THE WEB SERVICES MANAGEMENT LAYER.

In Proceedings of the Fourth International Conference on Web Information Systems and Technologies, pages 109-116

DOI: 10.5220/0001518201090116

 SciTePress

is already reported on in previous work (Verheecke

et al., 2003; Verheecke et al., 2004; Verheecke et al.,

2006). In this paper, we focus on how the WSML

can be used to express web service compositions, and

measure the performance and scalability of our ap-

proach, i.e. the time required to handle individual re-

quests to a composition (response time), and the num-

ber of requests to a composition that can be handled

concurrently (throughput).

The outline of the paper is as follows. Section 2

introduces the context of our work. Section 3 de-

scribes web service composition using the WSML.

Section 4 describes our tests and discusses their re-

sults. Section 5 gives an overview of related work,

and Section 6 states our conclusions and proposes

some directions for future work.

2 THE WEB SERVICES

MANAGEMENT LAYER

2.1 Introduction

The Web Services Management Layer (WSML) (Ver-

heecke et al., 2003; Verheecke et al., 2004; Verheecke

et al., 2006) is a mediation framework targeted at

dynamic service environments. As discussed in the

introduction, such environments are associated with

the problems of redirection, selection and client-side

management. In order to avoid that service clients

need to deal with these problems in an ad-hoc fash-

ion on a service-per-service basis, the WSML aims to

deal with each of these concerns in a client- and web

service-independent manner. The WSML is placed in

between the client and the world of web services, as

depicted in Figure 1. On the left-hand side, the client

requests service functionality without referencing the

concrete web services. The WSML is responsible for

intercepting the client requests and choosing the most

appropriate service available on the right-hand side or

combining a number of services together in a com-

position, invoking them in a manner that complies

with any management requirements imposed by ser-

vice providers and returning the results to the client.

Using the WSML for service-oriented applications

has the advantage that more robust and ﬂexible ap-

plications can be developed without having to rewrite

service-related code. Furthermore, replacing the web

service-speciﬁc invocations with generic service re-

quests and extracting all extra web service selection

and management code from the client applications fa-

cilitates future maintenance of the client application

code.

Web Service

Client

Web Service

WSML

Service

Integration

Service

Composition

Service

Selection

Service

Management

Figure 1: The Web Services Management Layer.

2.2 Aspect Oriented Programming

Traditional software engineering methodologies do

not allow modularizing the challenges of web service

redirection, selection and client-side management as

separate entities. Instead, the implementation of these

concerns will end up scattered across the different

modules of the system, and tangled with other con-

cerns. The code for different concerns becomes in-

termixed, possibly at multiple places in the system.

Because these crosscutting concerns are spread and

repeated over several modules in the system, it be-

comes very hard to add, edit, verify, test or remove

such concerns individually. Moreover, the scattered

and tangled code seriously hampers the evolution of

the concerns and the base application.

Aspect-Oriented Programming (AOP) (Kiczales

et al., 1997) is a software engineering paradigm that

aims to solve these problems by achieving better sep-

aration of concerns (Parnas, 1972). The goal of AOP

is to allow developers to cleanly modularize crosscut-

ting concerns. Therefore, AOP introduces an addi-

tional module construct, which is called an aspect,

to encapsulate the crosscutting concern. These as-

pects can then be added, edited, veriﬁed, tested or

removed without without impacting the base applica-

tion. The points in the program’s execution where an

aspect must be applied are called joinpoints and they

are described using a pointcut language.

2.3 AOP in the WSML

In the WSML, a variety of aspects are employed:

• Redirection aspects modularize the logic to com-

pose multiple services together in a service-

independent manner, contain the mapping for in-

dividual web services and deal with syntactical

or semantical mismatches between what the client

expects and what the service offers.

• Selection aspects enforce the selection of the most

optimal service based on quality-of-service (QoS)

properties.

WEBIST 2008 - International Conference on Web Information Systems and Technologies

110

• Management aspects enforce client-side manage-

ment concerns imposed by the service or the

client, such as logging, billing and caching.

Figure 2 depicts the architecture of the WSML,

based on AOP. The client makes service requests on

service types, i.e. invariable interfaces that are ex-

posed to the client. These requests are intercepted

by redirection aspects that invoke the appropriate web

service(s) and return the result(s) to the client. Which

particular redirection aspect is triggered is determined

by one or more selection aspects. Additionally, man-

agement concerns are enforced by management as-

pects. Each concern is nicely modularized in the sys-

tem by a different aspect and deployed by a speciﬁc

connector (indicated in the ﬁgure with “C”). Each

connector speciﬁes the deployment logic of an aspect.

As such, the aspect remains completely reusable as it

only contains “what” needs to be done to enforce the

concern. The connector speciﬁes how and where the

concern needs to be enforced in the system.

Web

Service A

Service

Type

Client

Web

Service B

Web

Service C

Service

Selection

Aspect

ch5

ch6 ch7

Service

Selection

Aspect

Service

Selection

Aspect

Service

Selection

Aspect

Service

Selection

Aspect

Management

Concern

Aspect

Administration

Service

WSML

Service

Redirection

Aspect A

Service

Redirection

Aspect B

Service

Redirection

Aspect C

Service

Repository

Figure 2: WSML Architecture.

With a static AOP approach, aspects are woven

into the base code at compilation time. This means

that adding or removing aspects requires recompiling

the system. Using a dynamic AOP approach it be-

comes possible to add and remove aspects at runtime

by providing traps at the possible joinpoints where

an aspect might be applied. A WSML prototype has

been implemented using JAsCo (Suv

ee and Vander-

perren, 2003), a dynamic AOP technology built on

top of Java. By exploiting the dynamic capabilities

of JAsCo, the WSML can be reconﬁgured at runtime

and can deal with events and changes in a dynamic

service environment without having to stop, or worse,

rewrite the system.

3 SERVICE COMPOSITION IN

THE WSML

Service composition is the orchestration of a number

of existing services to provide a richer composite ser-

vice assembled to meet the requirements of the client.

As explained in (Chakraborty and Joshi, 2001), a dif-

ferentiation can be made between pro-active compo-

sitions and reactive compositions. Pro-active compo-

sitions are composed off-line for deployment in a sta-

ble, always-up, resource rich platform. Typically, the

composition is speciﬁed with a ﬁxed set of partners

in mind. Reactive compositions on the other hand are

composite services that are created on the ﬂy based

on more volatile partner agreements, often optimiz-

ing for real-time parameters such as available network

bandwidth. Reactive compositions reference partner

roles that are ﬁlled in at runtime.

Our dynamic service binding mechanism supports

both kinds of compositions, which makes it possi-

ble for compositions to be adaptable: for instance,

a non-responding service in the composition can be

replaced by a semantically equivalent one. Compo-

sitions in the WSML can also better deal with long-

term changes and evolution, as each composition is

modularized as a ﬁrst-class entity: a composition as-

pect can be changed and recompiled easily without

affecting the rest of the system. For pro-active com-

positions, a dedicated composition aspect is written.

The invocation of the web services is addressed in the

composition aspect’s advice. To create reactive com-

positions that do not reference concrete services, the

aspect is adjusted to reference service types again. In-

voking service types from within a service composi-

tion allows for the speciﬁcation of a composition in a

generic way without hardwiring concrete service in-

terfaces. It also avoids the explosion of the number

of service compositions that needs to be speciﬁed in

case multiple partners are available to fulﬁll a spe-

ciﬁc role in a composition. By specifying for each

individual service type which service(s) and compo-

sition(s) can be used to handle a request, a tempo-

ral composition is created that best ﬁts the criteria of

the client. The complete redirection mechanism, sup-

porting transparent mappings between service types,

web services and service compositions is illustrated

in Figure 3. A service type is either fulﬁlled by a sin-

gle concrete web service, or by a service composition.

A composition is composed out of concrete web ser-

vices and/or service types.

An important implication of reactive compositions

is that a temporal composition is “created” at the mo-

ment a client request comes in. Each service type the

composition refers to is a partner role which is be-

WEB SERVICE COMPOSITION USING THE WEB SERVICES MANAGEMENT LAYER

111

Web

Service

Composition

Web

Service

Type

Service

Type

Figure 3: WSML service composition.

ing ﬁlled in by a concrete service. The service types’

support for transparent hot-swapping introduces the

concept of dynamic partner roles: each partner in a

reactive composition can be replaced by another one.

4 EVALUATION OF THE WSML

In this section, we investigate the performance and

scalability of the WSML. The investigated perfor-

mance metric is the response time. To indicate the

scalability of the WSML, the maximum throughput

is measured. In the throughput investigation, an ex-

ception rate of 10% is allowed in order to discard the

possible exception ﬂuctuations caused by the test en-

vironment.

4.1 Test Environment

Figure 4 shows our client behavior using the BPMN

notation. It consists of a number of consecutive invo-

cations of a broker service. The broker service will

forward each of these invocations to a dummy web

service with a very small execution time. Thus, the

overhead incurred by the middleware plays a very im-

portant role in the overall execution times and is not

hidden by large server execution times.

Invoke broker

BrokerClient

nth test iteration =

n broker invocations

(loop)

Figure 4: Client behavior.

The dummy web service has two identical end-

points, each situated on different physical machines

Broker

Client

WSML

Server 1

Monitor

Service

Server 2

Monitor

Service

Figure 5: Test environment.

(see Figure 5: Server 1 and Server 2). These two end-

points can be used for load balancing and thus provide

a certain level of QoS for the composed process. Load

balancing is an example of the selection challenge

talked about in the introduction. The broker service

(see Figure 5: Broker), which also runs on a different

physical machine, will choose at runtime which web

service endpoint will be invoked. To make this deci-

sion, three different brokering solutions have been im-

plemented: round-robin, broker-side monitoring, and

service-side monitoring. Each of these is elaborated

below.

The WSML runs on top of a Systinet for Java 6.5

server. The client machine (see Figure 5: Client)

will ﬁre service invocations to the broker in a multi-

threaded fashion. Each thread simulates a client that

wishes to use the web service. During a certain pe-

riod of time every second a set of client threads will

be instantiated. The number of instantiated threads re-

sembles the throughput. Each individual client thread

is responsible for logging its own response time.

4.2 Brokering Solutions

Round-robin is a simple and easy to implement

brokering solution. It alternates in a deterministic

way between the different service endpoints. This

means that all the service endpoints will be invoked

an equal number of times. Round-robin is especially

suited for brokering when the different service

endpoints have (almost) the same QoS properties.

Broker-side Monitoring will allow the broker to

make a decision based on some monitored property.

For example, this monitored property can be the re-

sponse time of a service invocation or the network la-

tency between the broker server and the service end-

points. The broker is responsible for gathering the

data that deﬁnes the property; this can be handled by

a separate thread or even by a separate tool installed

on the broker. The data (or an aggregated version of

it) can be requested by the broker to decide which ser-

WEBIST 2008 - International Conference on Web Information Systems and Technologies

112

vice endpoint will be invoked. This will result in one

additional internal function or internal service call per

actual service invocation. The implementation used in

the test environment monitors the response times for

the service endpoints in a separate thread. These re-

sponse times are aggregated to represent the service

rate (the inverse of the average response times) per

endpoint.

Server-side Monitoring is almost the same as

broker-side monitoring, except the property is mon-

itored on the service endpoint itself. To retrieve the

data that deﬁnes the property, the broker has to in-

voke an external web service on the service’s end-

point. This will give per actual service invocation a

number of additional external service calls equal to

the amount of service endpoints. The advantage of

server-side monitoring is that server related properties

(e.g. total server load, service price) can be monitored

as well.

4.3 Test Results

The graphs in Figure 6 and Figure 7 illustrate the re-

sults of our tests with regard to response time and

throughput, respectively. Each graph shows a num-

ber of series, three of which concern the WSML:

• wsmlRR: WSML approach with round-robin. A

dedicated round-robin selection aspect makes sure

each new client request is redirected to the next

service through the appropriate redirection aspect.

• wsmlBM: WSML approach with broker-side

monitoring. A dedicated monitoring aspect in-

serts measuring points in the composition and

monitors the response times of the dummy ser-

vices. This monitoring data is used by a selec-

tion aspect to select the fastest service with a ﬁxed

probability.

• wsmlSM: WSML approach using server-side

monitoring. The monitoring aspect does not do

any internal monitoring but rather obtains the

monitoring data from external monitoring ser-

vices. In our tests, the monitoring data is simply a

random number.

Figure 6 shows the average response times (in mil-

liseconds) measured during 2 minutes of testing with

2 clients. We performed each test 10 times, with the

number of consecutive invocations executed by the

client composition ranging from 1 to 10.

In order to identify the performance overhead in-

duced by the WSML, we measured the response time

Series are combined when there is no signiﬁcant differ-

ence between them.

Figure 6: Detailed view of the response times for the test

cases.

Figure 7: Throughput for the test cases.

and throughput of the same client behavior, but with

a broker on which the WSML has not been deployed,

i.e. a broker that simply forwards each request to a

single web service. The results of this additional test

is shown in our graphs as the “direct” series. Because

this test reduces the amount of code that is executed

by the broker in response to each service invocation,

response times are lower than our previous tests. The

round-robin and broker-side monitoring tests induce

a constant overhead, while the server-side monitoring

test induces an overhead that increases with the num-

ber of consecutive invocations. However, all WSML

series exhibit a linear behavior, which gives a ﬁrst in-

dication that the WSML performs well.

Figure 7 shows the maximum number of invo-

cations that could be executed concurrently without

causing exceptions. We started a maximum number

of 20 simultaneous invocations, because this number

is sufﬁcient to show the differences between the in-

vestigated approaches. We performed each test 10

times, with the number of consecutive invocations ex-

ecuted by the client composition ranging from 1 to

10. The graph shows that the round-robin and broker-

side monitoring tests scaled perfectly, but the server-

side monitoring test started to have lower throughput

when the client composition executed more consecu-

tive invocations. In this scenario, the direct test scaled

WEB SERVICE COMPOSITION USING THE WEB SERVICES MANAGEMENT LAYER

113

perfectly as well, but because it does not perform any

load balancing, its throughput would be lower if more

invocations were to be started simultaneously.

The previously mentioned tests give some initial

indications on the performance and scalability of our

approach. The direct test acts as a reference point

for our measurements: our broker can never perform

better than a broker that does nothing. In order to

obtain an additional reference point and get an ap-

preciation of our performance and scalability in rela-

tion to other state-of-the-art composition approaches,

we re-implemented our three brokering solutions as

BPEL processes and measured their performance and

scalability on a modern BPEL engine, more speciﬁ-

cally the ActiveBPEL 3.0 engine. We do not expect

our results to be representative of all BPEL engines:

we merely selected the ActiveBPEL engine because

it is the most commonly used open-source BPEL en-

gine. Although commercial offerings may have dif-

ferent behavior, the ActiveBPEL engine does put our

approach into perspective. Therefore, Figure 7 and

Figure 8 each contain three additional graphs:

• aeRR: ActiveBPEL approach with round-robin.

The different versions of the service endpoints

need to be known at design time. This round-

robin implementation just cycles over the list of

service endpoints.

• aeBM: ActiveBPEL approach using broker-side

monitoring. A SOAP handler intercepts all out-

bound service calls. When a synchronous web

service is invoked, the response time is logged.

An internal function, which is used inside the

workﬂow, will calculate the service rate upon

which the BPEL script will make a decision.

• aeSM: ActiveBPEL approach with server-side

monitoring. The invoked external monitoring ser-

vice randomly generates a value, which will be

used to make the load balancing decision.

The WSML outperforms ActiveBPEL in each of

the test scenarios. The round-robin and broker-side

monitoring series are still linear, but have a much

greater slope than the corresponding WSML scenar-

ios. The server-side monitoring service seems to ex-

hibit exponential behavior. Based on our comparison

of the WSML with a direct approach and a state-of-

the-art composition approach, we can safely conclude

that the performance and scalability of the WSML is

good.

The WSML and direct series of Figure 8 are the same

as those of Figure 6, but the scale of the Y axis is different

in order to allow including the ActiveBPEL series.

Figure 8: Response times for the test cases.

5 RELATED WORK

5.1 QoS Brokering of Web Services

Related work in this area focuses mostly on web ser-

vice brokers limited to service lifecycle management.

There is however a need for service brokers taking

into account QoS in order to ensure total response

time of composed services, prioritize time-critical ser-

vices or ensure bandwidth or robustness. In (Nahrst-

edt and Smith, 1995) a QoS broker model is described

for general distributed systems. Contrary to general

distributed systems, web services have a dynamic na-

ture in terms of service availability and the clients

invoking them. Brokers must support more ﬂexible

service selection and be able to adapt to the dynamic

server load. In (Yu and Lin, 2004) a web service

architecture supporting QoS is presented. However,

once the services are selected and the link is estab-

lished, the client communicates with the server di-

rectly without any broker intervention during the ac-

tual service process. Due to the dynamic nature of

web services, this introduces QoS shortcomings since

abrupt failure or unavailability of services needs dy-

namic selection of another equivalent service. This

broker also leaves composition as the client’s respon-

sibility. In (Benatallah et al., 2003), a middleware in-

frastructure for web service composition named Self-

Serv is proposed. Like the WSML, it facilitates dy-

namic web service selection and composition. Self-

serv introduces two concepts: composite services and

service containers. Composite services can be com-

pared to the WSML’s service compositions, while ser-

vice containers can be compared to the WSML’s ser-

vice types.

5.2 AOP for Web Services

In (Singh et al., 2005), a software architecture called

Aspect-Oriented Web Services (AOWS) is presented.

WEBIST 2008 - International Conference on Web Information Systems and Technologies

114

It is targeted at describing crosscutting concerns be-

tween web services in order to give a more complete

description of the web services, supporting richer dy-

namic discovery and seamless integration. An im-

plementation is made on the .NET platform and all

AOWS subsystems and their relationships have been

formally modeled. While aiming to achieve similar

goals as the WSML, AOWS does not support third-

party independent services as services need to be

modeled in an AOWSDL language, and registered in

a dedicated AOUDDI registry. Clients communicate

with AOConnectors, which address the web services

through adaptors; if necessary multiple services are

bundled in an AOComposite. The aspectual features

of the AOWS framework are used to provide more

efﬁcient and effective dynamic description, discovery

and integration. Similar to the WSML, service related

code is extracted from the client, and the client only

needs to communicate with the AOConnectors.

Contextual Aspect-Sensitive Services (CASS)

(Cottenier and Elrad, 2005) is a distributed aspect

platform that targets the encapsulation of coordina-

tion, activity life cycle and context propagation con-

cerns in service environments. CASS advocates the

decomposition of applications into a set of collabo-

ration layers, next to the well-known class, compo-

nent or service-based decomposition. In a CASS-

enabled service oriented architecture, a collaboration

layer captures the protocols all services should imple-

ment to fulﬁll an interaction. CASS aspects factor out

the crosscutting concerns that arise when services are

combined into distinct collaboration layers.

The WSML employs aspect-oriented principles in

order to better modularize the different concerns that

make up a service composition. Several approaches

have been proposed which apply aspect-oriented prin-

ciples to BPEL:

AO4BPEL (Charﬁ and Mezini, 2004) allows spec-

ifying crosscutting concerns in separate aspects. As-

pects contain an advice written BPEL code, and point-

cuts expressed using XPath, which allows expressing

queries on the structure of XML documents. This

may cause pointcuts to break when the structure of

the base BPEL process changes. AO4BPEL does not

have a separate aspect deployment construct, which

makes it impossible to reuse aspects in other pro-

cesses without duplicating code. AO4BPEL uses a

runtime weaver, which is implemented by extending

the BPWS4J engine.

Courbis and Finkelstein (Courbis and Finkelstein,

2005) have proposed an aspect-oriented approach

similar to AO4BPEL. They also use XPath as a point-

cut language, and propose extending a BPEL engine

for supporting dynamic aspect addition and removal.

Advices are expressed using Java instead of BPEL.

There is no publicly available implementation.

Padus (Braem et al., 2006) is an aspect-oriented

approach for BPEL that aims to improve on the two

former approaches by providing a declarative, logic-

based pointcut language which is more robust when

the structure of the BPEL process changes. Aspects

are reusable entities which are bound to a concrete

process using separate aspect deployments. Padus is

implemented as a static weaver which produces stan-

dard BPEL processes which can be executed on any

standard BPEL engine.

5.3 Relation between BPEL and the

WSML

BPEL and the WSML are complementary ap-

proaches: BPEL offers dedicated support for mod-

eling business logic involving multiple web services

and allows for the centralized deployment of these

service compositions on a dedicated engine. The

WSML on the other hand is speciﬁcally targeted at

dealing with dynamic service environments. In the

WSML approach, the actual business process is part

of the client, although it is possible to express more

complicated business process constructs in the as-

pects, including more advanced control ﬂow such

as conditional executions, loops and parallel branch-

ing. Other features such as logging, exception han-

dling, compensation, monitoring and stateful context

are supported through additional aspects. The result

will be a collection of aspects working together to re-

alize a composition. This more modularized approach

differs from dedicated composition languages such as

BPEL where all concerns are scattered and tangled in

one monolithic composition speciﬁcation.

6 CONCLUSIONS AND FUTURE

WORK

This paper describes how the Web Services Manage-

ment Layer (WSML) can be used to express both pro-

active and reactive web service compositions through

its dynamic service binding mechanism. We present

the results of a number of experiments which evaluate

the performance and scalability of the WSML imple-

mentation with regard to three brokering strategies:

round-robin, broker-side monitoring and server-side

monitoring. Although the WSML induces a small

performance overhead, this overhead is small enough

to be compensated by the various ways in which the

WSML relieves web service clients of complex tasks

WEB SERVICE COMPOSITION USING THE WEB SERVICES MANAGEMENT LAYER

115

such as redirection, selection and client-side manage-

ment. This makes the WSML a viable option in real-

life web services applications.

Although this paper evaluates the performance

and scalability of our approach, future work should be

directed at evaluating the expressiveness of its com-

position mechanism. Existing evaluations of work-

ﬂow languages (Wohed et al., 2003) are often based

on a number of frequently used and required work-

ﬂow patterns (van der Aalst et al., 2000), and a simi-

lar evaluation of our composition mechanism will be

investigated. Based on this evaluation, changes to the

WSML could be required in order to solve possible

shortcomings.

ACKNOWLEDGEMENTS

The research presented in this paper is funded by

the Research Foundation — Flanders (Fonds Weten-

schappelijk Onderzoek — Vlaanderen) in the context

of the DyBroWS project.

REFERENCES

Andrews, T. et al. (2003). Business Process Execution Lan-

guage for Web Services version 1.1.

Benatallah, B., Sheng, Q. Z., and Dumas, M. (2003). The

Self-Serv environment for web services composition.

IEEE Internet Computing, 7(1):40–48.

Braem, M., Verlaenen, K., Joncheere, N., Vanderperren,

W., Van Der Straeten, R., Truyen, E., Joosen, W.,

and Jonckers, V. (2006). Isolating process-level con-

cerns using Padus. Lecture Notes in Computer Sci-

ence, 4102:113–128.

Chakraborty, D. and Joshi, A. (2001). Dynamic service

composition: State of the art and research directions.

Technical Report TR-CS-01-19, Department of Com-

puter Science and Electrical Engineering, University

of Maryland, Baltimore, MD, USA.

Charﬁ, A. and Mezini, M. (2004). Aspect-oriented web ser-

vice composition with AO4BPEL. Lecture Notes in

Computer Science, 3250:168–182.

Cottenier, T. and Elrad, T. (2005). Dynamic and decen-

tralized service composition with contextual aspect-

sensitive services. In Proceedings of the 1st Inter-

national Conference on Web Information Systems and

Technologies (WEBIST 2005), Miami, FL, USA.

Courbis, C. and Finkelstein, A. (2005). Towards aspect

weaving applications. In Proceedings of the 27th

International Conference on Software Engineering

(ICSE 2005), St. Louis, MO, USA. ACM Press.

Du, W. and Elmagarmid, A. (1997). Workﬂow manage-

ment: State of the art vs. state of the products. Tech-

nical Report HPL-97-90, Hewlett-Packard Labs, Palo

Alto, CA, USA.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C.,

Lopes, C., Loingtier, J.-M., and Irwing, J. (1997).

Aspect-oriented programming. Technical Report

SPL97-008 P9710042, Xerox PARC, Palo Alto, CA,

USA.

Nahrstedt, K. and Smith, J. M. (1995). The QoS broker.

IEEE MultiMedia, 2(1):53–67.

Parnas, D. L. (1972). On the criteria to be used in decom-

posing systems into modules. Communications of the

ACM, 15(12):1053–1058.

Singh, S., Grundy, J., Hosking, J., and Sun, J. (2005). An

architecture for developing aspect-oriented web ser-

vices. In Proceedings of the 3rd IEEE European Con-

ference on Web Services (ECOWS 2005), V

axj

o, Swe-

den. IEEE Computer Society.

Suv

ee, D. and Vanderperren, W. (2003). JAsCo: An aspect-

oriented approach tailored for component based soft-

ware development. In Proceedings of the 2nd Interna-

tional Conference on Aspect-Oriented Software De-

velopment (AOSD 2003), Boston, MA, USA. ACM

Press.

van der Aalst, W. M. P., Barros, A. P., ter Hofstede, A.

H. M., and Kiepuszewski, B. (2000). Advanced work-

ﬂow patterns. Lecture Notes in Computer Science,

1901:18–29.

Verheecke, B., Cibr

an, M. A., and Jonckers, V. (2003).

AOP for dynamic conﬁguration and management of

web services. Lecture Notes in Computer Science,

2853:55–85.

Verheecke, B., Cibr

an, M. A., and Jonckers, V. (2004).

Aspect-oriented programming for dynamic web ser-

vice monitoring and selection. Lecture Notes in Com-

puter Science, 3250:15–29.

Verheecke, B., Vanderperren, W., and Jonckers, V. (2006).

Unraveling crosscutting concerns in web services

middleware. IEEE Software, 23(1):42–50.

Wohed, P., van der Aalst, W. M. P., Dumas, M., and ter

Hofstede, A. H. M. (2003). Analysis of web services

composition languages: The case of BPEL4WS. Lec-

ture Notes in Computer Science, 2813:200–215.

Yu, T. and Lin, K.-J. (2004). The design of QoS broker al-

gorithms for QoS-capable web services. In Proceed-

ings of the 2004 IEEE International Conference on e-

Technology, e-Commerce, and e-Services (EEE 2004),

Taipei, Taiwan. IEEE Computer Society.

WEBIST 2008 - International Conference on Web Information Systems and Technologies

116