A FRAMEWORK FOR THE MANAGEMENT OF CONTEXT-AWARE

WORKFLOW SYSTEMS

Liliana Ardissono, Roberto Furnari, Anna Goy, Giovanna Petrone and Marino Segnan

Dipartimento di Informatica - Universit`a di Torino, Corso Svizzera 185, 10149 Torino, Italy

Keywords:

Web Services and Web Engineering, Personalized Web Sites and Services.

Abstract:

This paper presents the CAWE framework for the context-aware management of applications based on the

composition of Web Services in complex workﬂows. We introduce a representation of context-dependent

activities based on an abstraction hierarchy which supports the speciﬁcation of synthetic and clear workﬂows.

Moreover, we propose a framework architecture which enriches the capabilities of a workﬂow engine in order

to support the execution of possibly complex adaptation rules. We have exploited the CAWE framework to

develop a prototype application handling a medical guideline which speciﬁes the activities to be performed

in order to monitor patients treated with blood thinners from their home. The application coordinates actors

playing different roles (e.g., patient, doctor, etc.) and can be accessed by using diverse client devices.

1 INTRODUCTION

Up to now, the introduction of context awareness in

workﬂow systems has been mainly focused on Qual-

ity of Service management and on the adaptation to

the user’s device; e.g., see (Benlismane et al., 2005)

and (Keidl and Kemper, 2004), respectively. In con-

trast, little effort has been devoted to support context-

awareness in composed applications whose business

logic imposes the management of complex and long-

term interactions with the service suppliers. Web Ser-

vices having complex interaction protocols have been

integrated in standard workﬂows by utilizing Web

Service composition languages, such as WS-BPEL

(OASIS, 2005). However, the context-aware activity

executions have been speciﬁed by directly modeling

all the decision points and the alternative execution

paths in ﬂat workﬂows, which turn out to be hardly

readable for the workﬂow designer and are little ex-

tensible (e.g., to handle a new contextual condition

and the associated course of action).

In order to enhance the ﬂexibility of workﬂow and

Web Service composition systems, context informa-

tion and context-adaptation rules should be explicitly

represented in the application logic. As a ﬁrst step in

this direction, we propose the CAWE (Context Aware

Workﬂow Execution) framework for the management

of context-aware applications whose business logic is

implemented as a context-sensitive workﬂow. CAWE

is based on the following features:

• A hierarchical representation of the workﬂow,

which can include abstract activities hiding the

context-dependent details.

• The association of each abstract activity with its

implementations. These are a set of alternative,

context-dependent parts of the workﬂow which

can be performed in different context states.

• The declarative speciﬁcation of the context condi-

tions determining the selection of the appropriate

context-dependent part of the workﬂow at execu-

tion time.

These features support the execution of alternative

courses of action and the context-aware invocation of

Web Service suppliers.

In order to test the functionality offered by our

framework, we have developed a proof-of-concept

prototype and we have instantiated it on the execu-

tion of a medical guideline for the home assistance

of patients affected by heart diseases and treated with

blood thinners. The application, which coordinates

the activities to be performed by the patient, by the

Ardissono L., Furnari R., Goy A., Petrone G. and Segnan M. (2007).

A FRAMEWORK FOR THE MANAGEMENT OF CONTEXT-AWARE WORKFLOW SYSTEMS.

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

DOI: 10.5220/0001279800800087

 SciTePress

CA-WF-Mgr

Workflow Specification

Knowledge Base

CtxMgr WS

WS supplier WS supplier

Workflow

Engine

Personalization

Module

Figure 1: Architecture of the CAWE framework. Web Service interfaces are depicted as thick lines.

doctor and by other personnel, may be accessed from

the internet, by using a PC or a Smart Phone client.

In the rest of this paper, we describe the architec-

ture of the CAWE framework and the proposed hierar-

chical representation of context-sensitive workﬂows.

Moreover, we describe in which way a standard work-

ﬂow engine can be exploited to execute this kind of

workﬂow.

2 THE CAWE FRAMEWORK

The CAWE framework supports the development of

context-aware applications adapting the user interface

and the workﬂow execution to the context. In this pa-

per, we focus on the second aspect, which is based on

the introduction of a Personalization Module select-

ing, at each stage of execution, the most appropriate

activity path to be performed by the workﬂow engine.

2.1 Architecture

Figure 1 shows the framework architecture.

A Context Manager service (CtxMgr WS) pro-

vides the contextual information during the execution

of the application. In line with current approaches

to context-aware workﬂow management, we have de-

signed the Context Manager as a Web Service which

might exploit multiple information sources to synthe-

size the required information.

The Context-Aware Workﬂow Manager (CA-WF-

Mgr) runs a workﬂowengine on the process speciﬁca-

tion which deﬁnes the business logic of the composed

application. The engine executes an abstract work-

ﬂow (deﬁned later on) as if it were a standard work-

ﬂow. However, each time it encounters an abstract

activity, the engine invokes the Personalization Mod-

ule to retrieve the appropriate context-dependent part

of the workﬂow and executes it. The Personalization

Module wraps the adaptation logic, which is repre-

sented by the applicability conditions of the context-

sensitive parts of the workﬂow. The CA-WF-Mgr in-

vokes the CtxMgr WS for retrieving the contextual

information.

A device-dependent User Interface (UI) enables

the user to interact with the application while carrying

out the tasks assigned to her/him. The UI component

retrieves the context information needed to adapt the

UI pages from the CtxMgr WS.

The CA-WF-Mgr and the CtxMgr WS may in-

voke some Web Service suppliers to receive external

services. E.g., in our sample scenario we consider a

Nurcery Service, a Clinical Record Manager WS stor-

ing the clinical records of the patients, and the WS

interface of the lab which performs the medical tests.

2.2 Representation of the

Context-Sensitive Workﬂow

In order to represent the context-dependent parts of

the workﬂow in a declarative and synthetic way, we

introduce an abstraction hierarchy whose higher-level

elements describe the activities to be performed in

generic way. Speciﬁcally:

• We introduce the concept of abstract activity to

denote an activity schema which does not directly

specify a piece of business logic of the applica-

tion (e.g., starting a task to be performed by a hu-

man actor, sending or waiting to receive a mes-

sage from a Web Service, or carrying out some

internal computation). In fact, the actions to be

executed in order to complete the activity are se-

lected at runtime, depending on the context state.

An abstract activity is characterized by the follow-

ing features:

– Abstract activity name.

– Input and Output arguments. The input argu-

ments must have been set before invoking the

abstract activity. The output arguments are set

as a result of the completion of the activity, i.e.,

A FRAMEWORK FOR THE MANAGEMENT OF CONTEXT-AWARE WORKFLOW SYSTEMS

start

evaluateResults

(patient,date,bloodResults, )

SendToHospital(patient)end

no yes

eval=OK?

onMessage:

bleeding or

fainting

onAlarm (interval)

pick

setUrgency(patient, "high")

emailPatient(date, therapy)

EVAL

ManageBloodCollection

(patient, date, time, appCode, ) BLOODRESULTS

storeTherapy(patient,date, )THERAPY

eval(date, time, )INTERVAL

BookBloodTest(patient, date, )TIME, APPCODE

setFirstBloodTest(patient, )DATE

Figure 2: Abstract workﬂow of our medical application.

after one of its implementations has success-

fully terminated.

– Input variables of the applicability conditions.

This is a list of variables occurring in the ap-

plicability conditions associated to the imple-

mentations of the abstract activity. The vari-

ables are a subset of the input arguments of the

activity.

• We deﬁne abstract workﬂow a workﬂow schema

including at least one abstract activity: the work-

ﬂow abstracts from the details of execution of at

least one (context-dependent) activity. If a work-

ﬂow does not contain any abstract activity, it rep-

resents a concrete workﬂow and it can be executed

by the workﬂow engine in straightforward way.

Each abstract activity has an associated a set of

context-dependent implementations representing the

alternative courses of action which the workﬂow en-

gine should actuate, depending on the context. Each

context-dependentimplementation is characterized by

the following features:

• Identiﬁer of the implementation.

In some work about workﬂow systems, the terms

abstract and concrete workﬂow denote, respectively, the

schema of a workﬂow and its instances. Notice that in this

paper we adopt a different meaning.

• Implements ﬁeld. This feature speciﬁes the name

of the implemented abstract activity.

• Workﬂow speciﬁcation. Each context-dependent

implementation consists of a workﬂow and rep-

resents a subprocess to be completed in order to

achieve the results of the abstract activity.

The

workﬂow may be elementary, i.e., composed of a

single activity.

• Input and output arguments. The input and output

arguments are set according to the values of the

corresponding input/output arguments of the ab-

stract activity; the correspondence is by name. If

the workﬂow is elementary, the input and output

arguments are the input and output arguments of

its included activity.

• Context-dependent variables. This is a list of

process variables whose value has to be set ac-

cording to the context, when the implementation

is selected for execution. We introduced this

feature in order to support a reactive adaptation

to context parameters whose value can change

abruptly during the execution of the application.

In fact, although such parameters might have al-

ready been evaluated during the execution of the

The implementation of an abstract activity might itself

be an abstract workﬂow.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

start

requestLabApp

(patient, date)

emailPatient

(appCode,date, time, address)

end

start

requestNurseAvailability(patient,

appCode1,date,time1,address)

end

avail?

requestAmbulance

(patient, appCode1, date, time1)

requestLabApp

(patient, date)

emailPatient

(appCode3,date, time3)

emailPatient

(appCode2,date, time2)

receiveLabAppNotification

(patient, , date, )APPCODE TIME, ADDRESS

receiveLabAppNotification

(patient, , date, )APPCODE1 TIME1, ADDRESS1

receiveNurseAvailNotification(

,date, )APPCODE2 TIME2

receiveAmbulanceNotification

(patient, , date, )APPCODE3 TIME3

Identifier of implementation: MovBBT

Implements: BookBloodTest

...

Applicability condition: movable = true

Identifier of implementation: Not-MovBBT

Implements: BookBloodTest

...

Applicability condition: movable = false

avail

Figure 3: Context-dependent implementations of abstract activity BookBloodTest. (for movable and not movable pa-

tients).

application, they need to be refreshed in order to

suitably inﬂuence the system behavior.

• Applicability condition. A boolean condition

which is true if the context-dependent implemen-

tation can be applied in the current context, false

otherwise. The applicability conditions are char-

acterized by input variables (bound to the val-

ues of the corresponding input arguments of the

abstract activity) and context-dependent variables

(bound according to the context).

Figure 2 depicts the abstract workﬂow of our proto-

type application. Abstract activity names start with

uppercase letter and concrete activity names start with

lowercase letters. Moreover, the output arguments of

the activities are uppercased. We describe only the

ﬁrst part of the abstract workﬂow for space reasons:

1. A doctor starts the workﬂow by set-

ting the ﬁrst blood test to be performed

(setFirstBloodTest(patient, DATE)).

2. The application reserves a blood test with a lab at

the speciﬁed date and evaluates the time interval

before the test (BookBloodTest(patient,

date, TIME, APPCODE), eval(date,

time, INTERVAL)).

3. If the patient’s health state is good, she waits un-

til the date of the test (onAlarm(interval)).

However, if any warning symptoms occur be-

fore that date (onMessage ...), the service sets

the urgency of the case (setUrgency(patient,

‘‘high’’)). The pick scope includes the com-

peting courses of action.

4. At the speciﬁed date, or after a warning symp-

tom, a blood sample is taken from the patient

(ManageBloodCollection(patient, date,

time, appCode, BLOODRESULTS)). The lab

analyzes the sample and returns the results,

which are evaluated by a doctor. If the results

are good, the next blood test and the therapy

A FRAMEWORK FOR THE MANAGEMENT OF CONTEXT-AWARE WORKFLOW SYSTEMS

are set; then, the application notiﬁes the patient

(emailPatient(date, therapy)) and the

ﬂow restarts from item 2. Otherwise, the patient

is advised to go to the hospital.

Figure 3 depicts the context-dependent implementa-

tions associated to the BookBloodTest abstract ac-

tivity. Both implementations are concrete workﬂows:

• The ﬁrst one may be performed if the patient can

be transported by car (movable(patient) ap-

plicability condition). The workﬂow speciﬁes that

the application must obtain an appointment with

the lab (requestLabApp(patient, date),

receiveLabAppNotification(patient,

APPCODE, date, TIME, ADDRESS) and notify

the patient (emailPatient(appCode, date,

time, address)).

• The second one is suitable to handle pa-

tients which cannot be transported by car (not

movable(patient)) and speciﬁes the activities

to be performed in order to request a nurse who

collects the patient’s blood at her home, or an am-

bulance to take the patient to the lab.

It should be noticed that our abstraction mechanism

enables the context-dependent invocation of alterna-

tive Web Service suppliers offering similar services,

and the management of different invocations on the

same Web Service. Speciﬁcally:

• An abstract activity A(arg

, ..., arg

) might

be implemented as alternative elementary sub-

processes, each one including one of the fol-

lowing concrete activities: C

(arg

, ..., arg

), ...

(arg

, ..., arg

). Suppose that the activities

invokedifferentWeb Service suppliers, e.g., offer-

ing the same service at different QoS levels. Then,

the application can select the one to be invoked on

the basis of the applicability conditions associated

to the alternative implementations.

• The abstract activity A(arg

, ..., arg

) might be

implemented as a single concrete activity C(arg

..., arg

), which can be invoked by setting its

context-dependent variables according to the con-

text. For instance, the same supplier might offer a

service at different QoS levels and the application

might choose the most appropriate one by setting

the arguments of the invocation.

It should be noticed that, although the context

variables are particularly signiﬁcant in the last case

above, they may occur in any implementation of

an abstract activity. In our sample scenario, the

In this case, the applicability condition of the concrete

activity is always true, because it is not necessary to dis-

criminate between a set of alternatives.

context-aware invocation of a Web Service supplier

is exempliﬁed by the ManageBloodCollection

abstract activity. In fact, its implementations include

a notifyUrgency(patient, date, urgency)

concrete activity, which the application executes in

order to inform the lab about the degree of urgency of

the patient (if the urgency is high, the results should

be produced in few hours). The urgency variable is

stored in the patient’s context and can be retrieved by

interacting with the CtxMgr WS.

2.3 Context-aware Workﬂow Execution

The workﬂow engine wrapped by the Context-Aware

Workﬂow Manager creates an instance of the abstract

workﬂow each time a user performs the starting activ-

ity of the workﬂow (in our application, when the doc-

tor sets the ﬁrst blood test for a given patient). The

abstract workﬂow is executed as if it were a standard

one; however, when the engine encounters an abstract

activity, it works as follows:

1. First, it invokes the Personalization Module on the

abstract activity.

2. When the Personalization Module returns the ap-

propriate context-dependent implementation, the

workﬂow engine performs it as a subprocess of

the main process instance.

3. At subprocess completion, the control returns to

the abstract workﬂow, in order to perform the next

(concrete or abstract) activity.

The Personalization Module, invoked on an abstract

activity, works as follows:

1. First, it retrieves the context-dependent imple-

mentation(s) of the abstract activity from the

Workﬂow Speciﬁcation Knowledge Base. If the

abstract activity is associated to more than one im-

plementation, the module evaluates the applicabil-

ity conditions of the alternatives and selects one

of the applicable implementations. The module

retrieves from the CtxMgr WS the values of the

context-dependent variables of the applicability

conditions.

2. The module binds the context-dependent vari-

ables of the selected implementation to their cur-

rent values and returns the implementation to-

gether with the bindings.

In the following section, we explain how the standard

behavior of a workﬂow engine can be extended to per-

form the steps described above. Before entering such

technical details, we want to point out that this ex-

tension does not require any changes to the workﬂow

engine: in fact, it can be implemented by embedding

WEBIST 2007 - International Conference on Web Information Systems and Technologies

Figure 4: Management of abstract activity.

some executable code in the deﬁnition of the abstract

activities.

In this way, the workﬂow engine can per-

form each abstract activity as if it were a concrete one;

however, the execution results in the invocation of the

Personalization Module and the enactment of the ap-

propriate implementation.

2.4 Details About the Cawe Prototype

We have developed an initial prototype of the CAWE

frameworkon top of jBPM (Koenig, 2004), a business

process managementsystem based on Petri Net model

(Jensen, 1976) implemented in Java. jBPM is based

on Graph Oriented Programming model, which com-

plements object-oriented programming with a run-

time model for executing long lasting workﬂows ac-

tivities, represented as graphs.

In the jBPM language, standard workﬂow activi-

ties are represented as Actions, i.e., they are pieces

of Java code that implement the business logic and

In turn, this can be achieved at workﬂow design time,

by translating the abstract workﬂow to a very similar one,

where the abstract activities have been modiﬁed.

are executed upon events in the process. The direct

association of Actions to pieces of executable code

makes the invocation of special purpose operations

rather straightforward. jBPM also separates the nav-

igation of the underlying graph (workﬂow) from the

maintenance of the workﬂow state, which is stored

in an object token, similar to the Petri Net model.

Furthermore, jBPM offers process-state nodes

to represent the subprocesses to be performed.

In the CAWE prototype, we have implemented

the abstract activity as a process-state node repre-

senting the subprocess which has to be performed.

It should be noticed that, in a standard jBPM work-

ﬂow, a process-state node stores the name of the

workﬂow deﬁnition to be executed when the token

(workﬂow state) reaches the node. However, in our

framework, the name of such a workﬂow is known

only after the invocation of the Personalization Mod-

ule. Therefore, we manage the node as follows (see

Figure 4, which shows the management of an abstract

activity on BookBloodTest):

In our framework, we assume that the workﬂow is rep-

resented as a Petri Net.

A FRAMEWORK FOR THE MANAGEMENT OF CONTEXT-AWARE WORKFLOW SYSTEMS

• The node is set to the same name as the abstract

activity; e.g., BookBloodTest.

• We use the Action (delegation) tool provided

by jBPM and we deﬁne a java class han-

dler, the AbstractManager, that the jBPM en-

gine invokes as soon as the token of execu-

tion enters the node (event:enter-node). The

AbstractManager invokes the Personalization

Module to get the context-dependent process im-

plementation that has to be performed. Moreover,

the handler sets the subprocess deﬁnition obtained

from the Personalization Module into the process-

state node associated to the abstract activity be-

fore starting its execution.

The Personalization Module invokes the CtxMgr

WS in order to evaluate the context-dependent vari-

ables used by the subprocess implementation and

passes the context-dependent variables input list to

the AbstractManager. In turn, the handler sets

these variables in the new subprocess instance in or-

der to make them available at execution time.

In the followingwe provide some details about the

execution of the AbstractManager.

• At invocation time, the handler gets the name of

the abstract activity and retrieves from the main

process instance the values of the variables in-

volved in the evaluation of the applicability con-

dition.

• Then, it invokes the Personalization Module pass-

ing the name of the abstract activity and the in-

put variables list of the applicability condition

(getImplementation arrow in the ﬁgure).

• The AbstractManager receives the following

data items from the Personalization Module:

– The context-dependent implementation to be

performed; e.g., MovBBT.

– A list of evaluated input context-dependent

variables. Notice that the list of input argu-

ments used in the selected context-dependent

implementation is by deﬁnition a subset of the

input arguments declared at the abstract activity

level and is made available to the implementa-

tion process by the workﬂow engine.

• The AbstractManager sets the implementation

deﬁnition as the subprocess deﬁnition for this

process-node (setSubProcess arrow in the ﬁg-

ure).

• Moreover, the AbstractManager starts the exe-

cution of the subprocess (Signal arrow).

Similar to the input arguments, output arguments are

copied to the parent process by the workﬂow engine.

3 RELATED WORK

The introduction of hierarchical workﬂows is not

new; for instance, several workﬂow languages en-

able the designer to deﬁne complex activities which

expand in workﬂows forming a composition hierar-

chy; e.g., see WS-BPEL (OASIS, 2005) and process

languages such as Petri Nets (Jensen, 1976; van der

Aalst, 2002). Our proposal differs from such ap-

proaches because it introduces a specialization hierar-

chy supporting the actuation of the same abstract ac-

tivity in different ways. Indeed, our framework brings

to the research in workﬂow systems some concepts

that have been traditionally developed in the research

about autonomous agents and reactive planners; e.g.,

see (Firby, 1987; Georgeff and Lansky, 1987).

In the Semantic Web research, planning technol-

ogy has been applied to enhance the ﬂexibility in Web

Service composition. However, only simple compo-

sition plans have been considered up to now. Typi-

cally, the interaction with the composed service has a

very short duration, so that persistence management

is not needed; moreover, the invocation of Web Ser-

vice suppliers is elementary because their interaction

protocols consist of exchanging very few request and

response messages; e.g., see (McIlraith et al., 2001;

Balke and Wagner, 2003; Keidl and Kemper, 2004).

Indeed, (Laures and Jank, 2005) deals with persis-

tent workﬂow composition and dynamic selection of

service providers. However, only a reference imple-

mentation is provided, which does not specify details

about the execution model.

As a matter of fact, relying on a standard workﬂow

engine for the management of the business logic of an

application has scalability and robustness advantages,

which are not guaranteed by other technologies, such

as planners. In fact, several proposals for the adoption

of planners in Web Service composition have turned

out to exploit workﬂow engines for the service execu-

tion; e.g., (Mandell and McIlraith, 2003; Laures and

Jank, 2005).

4 CONCLUSIONS

We have presented the CAWE framework for the

development of applications composing Web Ser-

vice suppliers in context-sensitive workﬂows. The

context-aware workﬂow execution is based on the in-

troduction of abstract activities hiding the context-

dependent details; abstract activities can be per-

formed by following different courses of action, de-

pending on the context state.

In order to test the functionality of the CAWE

WEBIST 2007 - International Conference on Web Information Systems and Technologies

framework and its applicability in realistic domains,

we have developed a proof-of-concept prototype sys-

tem and we have instantiated it on a medical domain.

The approach proposed in this paper has the fol-

lowing advantages:

• First of all, the introduction of abstraction en-

hances the readability of the context-sensitive

workﬂow, which could be very hard to under-

stand, if represented as a ﬂat graph including all

the alternative courses of action.

• Second, the organization of context-sensitive

workﬂows as a hierarchy of simpler workﬂows

with applicability conditions supports a seamless

extension of the business logic of an application to

take new contextual conditions and new courses

of action into account. In fact, a context-sensitive

workﬂow can be extended by replacing any con-

crete activity with an abstract activity and its im-

plementations. Moreover, given an abstract activ-

ity, a new context-dependent implementation can

be added by revising the applicability conditions

of the existing implementations and introducing

the new one in the workﬂow speciﬁcation.

• Finally, the introduction of abstraction enables the

designer to deﬁne the workﬂowtop-down,starting

from a general view of the activities to be man-

aged, and specifying the low-level details later on.

In our medical domain, this separation helped us

to focus ﬁrst on the most relevant aspects of the

medical guideline (provided by a physician), and

to postpone the speciﬁcation of details such as re-

serving an ambulance or requesting a nurse.

It should be noticed that the hierarchical workﬂows

we propose can be executed by a standard workﬂow

engine without the Personalization Module. In fact,

although abstract activities and contextual conditions

extend the syntax of standard workﬂow languages, a

hierarchical workﬂow could always be translated to

a ﬂat one by replacing abstract activities with deci-

sion points and by including the alternative courses

of action directly into a ﬂat workﬂow. However, this

translation would generate workﬂows which are very

difﬁcult to read and debug. For this reason, we pre-

ferred to extend the capabilities of the workﬂow en-

gine by making it invoke the Personalization Module,

specialized in the execution of adaptation strategies.

As discussed in the paper, even this extension can

be performed by a standard workﬂow engine without

modifying its core, if the context-sensitive workﬂow

is translated to an intermediate representation which

maintains its hierarchical structure but expands the

code of the abstract activities. We believe that our ap-

proach is strategic because the Personalization Mod-

ule, which now evaluates boolean conditions, might

be extended to handle complex adaptation rules, with-

out modifying the rest of the system.

ACKNOWLEDGEMENTS

This work is supported by the EU (project WS-

Diamond, grant IST-516933) and by MIUR (project

QuaDRAnTIS).

REFERENCES

Balke, W. and Wagner, M. (2003). Towards personalized

selection of Web Services. In Proc. of 12th Int. World

Wide Web Conference (WWW’2003), Budapest.

Benlismane, D., Maamar, Z., and Ghedira, C. (2005). A

view-based approach for tracking composite Web Ser-

vices. In Proc. of European Conference on Web Ser-

vices (ECOWS-05), pages 170–179, V¨axj¨o, Sweden.

Firby, R. (1987). An investigation into reactive planning in

complex domains. In Proc. 6th Conf. AAAI, Seattle

(WA).

Georgeff, M. and Lansky, A. (1987). Reactive reasoning

and planning. In Proc. 6th Conf. AAAI, pages 677–

682, Seattle.

Jensen, K. (1976). Coloured Petri nets: basic concepts,

analysis methods and practical use. Springer-Verlag,

Berlin.

Keidl, M. and Kemper, A. (2004). Towards context-aware

adaptable Web Services. In Proc. of 13th Int. World

Wide Web Conference (WWW’2004), pages 55–65,

New York.

Koenig, J. (2004). JBoss jBPM white paper.

http://www.jboss.com/pdf/jbpm

whitepaper.pdf.

Laures, G. and Jank, K. (2005). Adaptive Ser-

vices Grid Deliverable D6.V-1. Reference archi-

tecture: requirements, current efforts and de-

sign. Technical report, http://asg-platform.org/cgi-

bin/twiki/view/Public/ReferenceArchitecture.

Mandell, D. J. and McIlraith, S. A. (2003). Adapting

BPEL4WS for the Semantic Web: The bottom-up ap-

proach to Web Service interoperation. In LNCS 2870,

Proc. 2nd International Semantic Web Conf. (ISWC

2003), pages 227–241. Springer-Verlag, Sanibel Is-

land, Florida.

McIlraith, S., Son, T., and Zeng, H. (2001). Semantic Web

Services. IEEE Intelligent Systems, 16(2):46–53.

OASIS (2005). OASIS Web Services Business

Process Execution Language. http://www.oasis-

open.org/committees/

documents.php?wg

abbrev=wsbpel.

van der Aalst, W. (2002). Making work ﬂow: on the appli-

cation of Petri Nets to Business Process Management.

In Proc. of 23rd Int. Conf. on Applications and Theory

of Petri Nets, pages 1–22, Adelaide, South Australia.

A FRAMEWORK FOR THE MANAGEMENT OF CONTEXT-AWARE WORKFLOW SYSTEMS