Sensors and Guards in a Context-aware Workﬂow

Environment

Nico Kerschbaumer and Johann Eder

Department of Informatics-Systems, University of Klagenfurt, A-9020 Klagenfurt, Austria

Abstract. We propose a system for integrating context awareness in workﬂow

management systems. The context is captured via simple or complex sensors.

The workﬂow management systems interacts with these sensors and can use data

about the environment in making decisions about the control ﬂow. Since the en-

vironment - and thus the context of workﬂow execution - may change, we in-

troduce sensor guards which monitor the sensors during speciﬁed critical parts

of the workﬂow execution and raise an exception when the data transmitted by

sensors leave their expected ranges.

1 Introduction

Context-aware Workﬂows allow the use of context information to steer the control ﬂow.

There are several deﬁnitions of context in the literature. [1] deﬁnes context as ”Context

is any information that can be used to characterize the situation of an entity. An entity

is a person, place, or object that is considered relevant to the interaction between a

user and an application, including the user and applications themselves.” and context-

aware applications as ”A system is context-aware if it uses context to provide relevant

information and/or services to the user, where relevancy depends on the user’s task.”

These context data is usually received through sensors and then processed in the

workﬂow. A difference between context data and ’normal’ data is that context data can

only be read, but not updated by the WfMS. Both types of data are crucial for the correct

execution of a workﬂow, because the control ﬂow decisions depend on them. Normal

data can be updated at any point within or outside of an active workﬂow instance. As a

solution to this problem Workﬂow Data Guards[2] have been proposed which monitor

the data in all guarded activities in a workﬂow and can detect violation of a predeﬁned

set of constraints. Data Guards do not prevent changes of data performed outside of the

workﬂow, however they detect those changes and allow the WfMS to react accordingly.

Currently data guards are limited to monitor data that are retrieved from a database

and used in a workﬂow. We extend that concept to generic sensors, which would al-

low the development of a context-aware workﬂow system. To illustrate how sensors

and guards can be utilized imagine a simpliﬁed claim handling workﬂow of an Aus-

tralian insurance company. The company handles claims according to a certain process,

however when the storm season arrives claims are handled in a different way. If the

company would use a context aware workﬂow system that utilizes sensors and guards,

Kerschbaumer N. and Eder J.

Sensors and Guards in a Context-aware Workﬂow Environment.

DOI: 10.5220/0003020900550064

In Proceedings of the International Joint Workshop on Technologies for Context-Aware Business Process Management, Advanced Enterprise Architecture and Repositories and Recent

Trends in SOA Based Information Systems (ICEIS 2010), page

ISBN: 978-989-8425-09-6

it would be possible for the company to be informed by the system when a good time to

switch to a special storm season claim handling process arises. To detect the beginning

of the storm season, the workﬂow system could use data measured by different sensor

and calculate key values. The computation of key values to detect, e.g., lighting storms,

is probably quite complex and needs to incorporate data measured over a period of time

to deliver somewhat accurate results - thus we need sensors that have the capability to

store their measurements. Basically the sensor guards will allow us to react to excep-

tions that occur in the environment. The environment is monitored with sensors and

guards can detect exceptional situation based on measured sensor data. For example

if the temperature and smoke concentration rises rapidly in a room, the system could

detect a ﬁre and and activate water sprinklers.

We represent workﬂows as full-blocked workﬂow graphs and explore the concept of

sensor guards in detail for this workﬂow model. Full-blocked workﬂow graphs are di-

rected acyclic graphs(DAG) with two kinds of nodes: activities and control nodes. The

edges determine the execution sequence of nodes. Control nodes describe basic work-

ﬂow control structures: conditional(conditional-split and conditional-join nodes sym-

bolized by a circle with CS or CJ) and parallel execution (par-split and par-join nodes

symbolized by a circle with PS or PJ ). In a full-blocked workﬂow graph, with each split

node is associated exactly one join node of the same type and each join node has exactly

one corresponding split node of the same type. The choice of full blocked workﬂows

might be seen as a restriction, however full-blocked workﬂows are less problematic

than non-blocked workﬂows, as it is does not allow process deﬁnitions that suffer from

problems like deadlocks during execution and [3] shows that non-blocked workﬂows

can get problematic as soon as data-ﬂow comes into play. The approach we present in

this paper is an extension of data guards[2] to include generic sensors that will help to

overcome the stated problems.

The remainder of this paper is structured as follows: Section 2 gives an overview of

related work about context-aware workﬂow systems and the data guard concept. In sec-

tion 3 we introduce the concept of sensors, sensor guards, sensor broker and our meta

model followed by section 4, which summarizes the paper and draws some conclusion.

2 Related Work

An early work in the area of context-awareness was the Context Toolkit [4] which in-

troduced software components to query sensor data. In contrast to workﬂows, context

data was used in pervasive and interactive computing for quite some time. In the recent

years the research in context-aware workﬂows got a lot of momentum. [5] uses context

information for the management of Webservice composed applications. In [6, 7] the au-

thors present how context is managed in the Nexus project and introduce their vision of

a smart factory which uses sensor technology to create a context-aware production pro-

cess. [8] propose a methodology for context-sensitive business process development.

Their approach supports modeling of context sensitive workﬂow regions which behave

differently depending on the context information. Furthermore they introduced context

change patterns that allow one to identify context changes that may inﬂuence the behav-

ior of the process. The authors of [9] introduce a language called Ubiquitious Workﬂow

Deﬁnition Language(uWDL) that supports the speciﬁcation of context information in

workﬂow and evaluated it’s feasibility in a workﬂow system called uFlow. [10] intro-

duced complex event processing(CEP) which they deﬁne as a set of techniques and

tools to understand and control event driven information systems. Complex events are

events that only happen if a set of other events occur and can be related in various ways,

by cause or by timing. CEP can be utilized in a broad spectrum of information systems

like e.g. for business process automation, scheduling and control, network monitoring

and performance prediction etc. The authors of [2] introduced workﬂow data guards

which are constraints deﬁned over speciﬁed parts of a workﬂow. The guard is spec-

iﬁed in a workﬂow deﬁnition, consists of a condition, a set of activities that activate

the guard for the ﬁrst time in a workﬂow instance and a set of guarded activities. The

condition is a boolean expression which is deﬁned on the data used in the workﬂow and

checked during the execution of a guarded activity. The sensor guards are an extension

to workﬂow data guards by [2] and use methods and basics how to build context aware

workﬂow systems as in [6, 7, 5, 8]. Furthermore for the realization of complex sensors

techniques developed in the ﬁeld of complex event processing [10] will be utilized. We

also want to support switching to different process variants based on sensor and thus

want to refer to a quite recent work by [11] who introduced criteria for guaranteeing

soundness in conﬁgurable process variants. Lastly another important part is the support

of exception handling and migration mechanisms with our sensor guards [12, 13].

3 Workﬂow Sensor Guards

A workﬂow sensor guard is a constraint deﬁned over a speciﬁed part of a workﬂow like

the ordinary data guard[2], however the constraints are not limited to the monitoring of

some local variables, but can include data from sensors, services or events. Before we

present the details of the sensor guard concept in Section 3.3 we introduce at ﬁrst data

guards in Section 3.1, our sensor concept and the different types in Section 3.2. In Sec-

tion 3.4 and Section 3.5 we propose our sensor- and sensor guard broker, followed by

a discussion of our metamodel in Section 3.6 and lastly we close with a brief overview

how sensor guards can be utilized for exception handling in Section 3.7.

3.1 Preliminaries

The grounding of the sensor guard is the data guard [2] thus we give at ﬁrst a quick

overview of the original guard concept and then follow up with the extension that come

with sensor guards. A data guard instance is in one of three states during runtime: inac-

tive, active and deactivated. A guard is inactive when the workﬂow instance is started,

the ﬁrst guarded activity sets a guard to the state active. During the execution of an in-

stance the guard can be deactivated and reactivated again, so that it is only active during

execution of guarded activities. For details of the activation policy of a guard refer to

[2].

The activation mechanism allows designers to choose activities and paths where

guard constraints are checked, thus minimizing performance problems. The deactiva-

tion of data guards is not straight forward, because parallel splits and conditional splits

add the following problems that have to be solved at runtime:

– Tracking several guarded paths that run in parallel and provide communication

between them.

– Detecting that a given guarded path has completed.

– It is not always possible to decide using only the workﬂow deﬁnition which suc-

cessor will actually be started, i.e. after a conditional split node there exist different

execution paths that can be taken. That leads to the problem that a guarded activity

instance may have a guarded direct activity successor in one instance graph and

none in another instance graph. For example refer to ﬁgure 1(c), considering only

the workﬂow deﬁnition it is not possible to tell if the successor of B will be C or

D, and thus it is not possible to determine if the guard can be deactivated after the

completion of B.

A guarded path may begin before or after a parallel split and continue after the parallel

join as shown in ﬁgure 1(a) and ﬁgure 1(b) respectively. Figure 1(a) shows two parallel

guarded paths, the guard G1 is started when an instance of activity B is started and stays

active until both guarded paths, i.e. the path (B,PS,C) and the path (B,E,F).

A B

Guard G: Var<150

(a) Workﬂow graph with parallel guarded paths

A B

Guard G: Var<150

(b) Workﬂow graph with parallel

guarded paths

A B

Guard G: Var<150

instance of B will have a guarded direct activity

successor at runtime

Fig. 1. Example workﬂows with data guards cf.[2].

3.2 Sensors and Sensor Types

In general, a sensor is any device that measures a (physical) quantity and converts it

into a signal which can be read by an observer, an instrument or even a computer that

could offer the signal via a Webservice. Nowadays sensors are used in a wide variety

of ﬁelds, from simple sensors that measure temperature or humidity to touch sensitive

buttons on lamps that control the light intensity. Software sensors can monitor any data

e.g. from websites, news feeds, or databases. In our model a sensor is composed of a

unique id, an update interval, a query method and two methods to activate or deactivate

the sensor. The value returned by the query method is the current measurement of a

sensor. We symbolize sensor nodes as ”S” surrounded by two circles. Sensors can be

queried from an activity, a decision node which can use sensor data in its condition

or any other application that is capable of invoking a Webservice. Figure 3 shows an

example workﬂow were the outcome of the conditional split nodes CS depends on the

value returned by the sensor Simple. Any activities like in our example B are also able

to receive sensor data as a input. Based on this general sensor we derive four subtypes:

Simple Sensor. A simple sensor has a query function which allows one to read the data

that the sensor currently measures. The update interval says how often the sensor

updates its data.

Complex Sensor. A complex sensor is capable of hooking simple sensors, that means

it can read and store the data of multiple simple sensors. Hooked sensors are stored

in an array and the sensor data can be stored in a log. An entry in the data log con-

tains a date-time stamp, the measured data and the sensors id. The stored measure-

ments allow calculation of important coefﬁcient or data aggregates which produce

results that are a lot more accurate than a single sensor measurement. For a recent

work on concerning data quality in context-aware workﬂow systems we would like

to refer the reader to [14].

Active Sensor. An active sensor is a subtype of a complex sensor which features an

event subscription mechanism. The conditions and constraints of a passive sensor

guard are checked whenever a guarded node instance is activated. In contrast, an

active sensor offers a set of events that a sensor guard can subscribe to and if the

constraint fails to hold at any time, all sensor guard instances that subscribed to the

active sensors event will be notiﬁed. The offered events use sensor data received

from hooked simple sensors as a basis to perform calculations and checks that are

then exposed as subscribable events.

Passive Sensor. This sensor type does not offer a single query function like the simple

sensors, however it maintains a set of Webservices that can be called by sensor

guards. The stored data in the log allows the passive sensor to offer services that

for example calculate aggregates over past data or check if a condition was present

during a certain date-time interval. A published service has a URL, a name and a

query function that returns a value calculated by the service.

3.3 Sensor Guards

A sensor guard is speciﬁed in the workﬂow deﬁnition and consists of a boolean condi-

tion deﬁned with data used in the workﬂow, measurements received from sensors, re-

sults from service calls that are offered by passive sensors or the occurrence of an event

offered by an active sensor. The use of sensors allows the creation of context-aware

workﬂows which can detect constraint violations via the predeﬁned sensor guards. We

extend our workﬂow model with the functionality to query sensors and utilize the mea-

sured data in activity steps or conditionals, similar to [6]. When sensors are queried,

their result is stored in a local workﬂow variable which can then be evaluated at a con-

ditional node or further processed in a workﬂow step that receives the data as an input.

It is also possible to query sensors from a conditional node and evaluate the values di-

rectly. However, this approach is limited to simple constraints that will only evaluate a

single data measurement of a sensor and is not capable of handling complex constraints

that include for example aggregates of stored sensor data or precalculated values. To

overcome the limits we introduced different types of sensors that provide functions ex-

posed as Webservices which can be used in a guards constraint and events to which

a guard can subscribe. Sensors and sensor guards are managed by brokers which are

described in detail in Section 3.4 and Section 3.5. Due to space limitations we are not

able to present details how to incorporate and implement the sensor and guard con-

cepts, however we want to sketch shortly how an sensor can be used in conjunction

with WS-BPEL. Since simple and complex sensors are web services, they can be eas-

ily integrated and used in a for example a case condition which is evaluated from the

BPEL engine and the result is depending on the return value of the sensor. Based on

the outcome of the condition an exception handling routine can be started with fault

handlers and throw activities. An active sensor could be implemented with a parallel

branch in the BPEL process that listens for messages of the sensor guard broker and

sets for example a boolean variable which will indicate if an event monitored by the

external active sensor occurred.

3.4 Sensor Guard Broker

A workﬂow designer can create sensor guards at the sensor guard broker. The broker

manages all guards, that means it activates and deactivates them depending on their

activation set. The sensor guard broker provides the following methods:

– CreateGuard(gid, constraint, activation set, subscription set): Creates a new sensor

guard with a constraint an optional activation and/or subscription sets. The activa-

tion set denotes the set of activities in which the guard instance will be activated.

The subscription set, contains a list of subscribed active sensor events, which can

be used in the guards constraint.

– RemoveGuard(gid): Removes a sensor guard from the broker. This is only possible

if there exist no running instances of a guard.

A sensor guard instance has a unique gid, a constraint, a state (activated, deacti-

vated), an activation set, a subscription set and provides the following functions:

– Activate() / Deactivate(): Called by the broker to enable or disable a sensor guard

instance during the runtime of a workﬂow.

– Subscribe(URI, SubConstraint): Creates a subscription for an event provided by an

active sensor. The subscribed event can then be used in a guards constraint as part

of the boolean condition since the event either occurred, i.e. its true or it did not

occur, i.e. its false.

– Unsubscribe(URI): Removes a subscription of a sensor guard at the sensor broker.

3.5 Sensor Broker

A sensor broker can be seen as a central repository that manages and controls sensors.

A sensor has to be registered at the sensor broker, after that the sensor can be found

and used via the broker. A workﬂow designer can register sensors at the service broker

and sensor guards can then query simple sensors directly, use services provided by a

passive sensor or subscribe to events offered by an active sensor. The registered sensors

are reusable and each guard instance can include an arbitrary number of constraints

deﬁned over a set of available sensors, services and events. The broker provides the

following methods:

– RegisterSensor(SensorId): Registers a sensor at the broker. Once a sensor has been

registered it can be used by a sensor guard.

– UnregisterSensor(SensorId): Removes a sensor from the broker.

3.6 Meta Model

We use a workﬂow metamodel shown in ﬁgure 2 to describe workﬂow deﬁnitions,

workﬂow instances, sensors, the sensor broker and sensor guards. A workﬂow con-

sists of nodes and each node has a unique identiﬁer and a type (activity, conditional

split, parallel split). A node instance can read data from simple sensors or call services

offered by passive sensors and use them in conditional split nodes for a decision or in an

activity. Furthermore a node can have adjacent successors and predecessor. A workﬂow

may also contain sensor guards which are an extension of data guards. In contrast to a

data guard, a sensor guard is not limited to monitor workﬂow data inside a database, it

can also monitor external sensors. We support three kinds of sensors namely simple-,

complex, active- and passive sensors. A sensor guard instance can query simple sensors,

call services offered by a passive sensor or subscribe to events provided by an active

sensor. A service of a passive sensor is a Webservice that can be perform any type of

computation with sensor data. An event provided by an active sensor monitors sensor

data and notiﬁes all subscribers when an event occurs.

Figure 3 shows an example workﬂow with a sensor guard that uses all introduced

types of sensors in its guard constraint. Activities that are shaded in grey are guarded ac-

tivities and only during execution of this activities the sensor guard will be active and in-

form the user or engine about a violation of its constraint. The workﬂow contains a sim-

ple sensor(Simple), a passive sensor(Passive) and an active sensor(Active) and an exam-

ple constraint that uses the given sensor like, e.g., Simple < 30 && P assive.Some−

Service() > 20 && !Active.StormW arningEvent() . Simple sensors can be queried

by any activity node or conditional node and be used in guard constraints. Services of-

fered by the passive sensor can be used in activities, conditionals and guards, for ex-

ample activity A calls the GetHumidity() Webservice and the guard constraints also

contains a service call to the passive sensor in its constraints. Events offered by ac-

tive sensors can be subscribed by sensor guards and then used in their constraint. If an

event occurs between transitions of two activities, then the next time the guard becomes

active he receives a notiﬁcation of the corresponding active sensor and the guard con-

straint will invalidate. If any part of the boolean constraint is violated while the guard is

active then either a workﬂow administrator is informed or an exception handling routing

is started.

3.7 Exception Handling

Based on sensor guards, that monitor that certain predeﬁned conditions hold during a

workﬂow instance execution common exception handling and compensation methods

can be applied. For example rollback to a certain point in the workﬂow, migrate all

running instances to a new workﬂow schema, migrate-adhoc only a single running in-

stance to a new ad-hoc workﬂow, suspend-resume which allows to suspend a workﬂow

instance and resume it at a later point when for example an exception that was raised by

-sid

-UpdateInterval

-cost

+Activate()

+Deactivate()

Sensor

-gid

-constraint

-state

+Activate()

+Deactivate()

+Subscribe()

+Unsubscribe()

+HasEvents()

Sensor Guard Instance

-gid

-constraint

+activationSet()

Sensor Guard

-wfid

-name

Workflow

-wfid

WorkflowInstance

-id

-type

+guarded()

Node

-id

-type

+guarded()

NodeInstance

-activates

guards

+Query()

SimpleSensor

-HookedSensors[]

+HookSensor()

ComplexSensor

-sid

+WriteLogEntry()

+ReadLogEntry()

Sensor Data Log

-url

-name

+Query()

Service

+InformSubscriber()

Active Sensor

-id

-InterruptCondition

+SubscribeEvent()

+UnsubscribeEvent()

Event

Passive Sensor

0..*

1..*

0..*

succ

pred

0..*

succ

pred

0..*

0..1

0..*

1..*

0..*

1..*

0..*

1..*

0..*

calls

has

offers

hook

call service

subscribe event

reads

query

guards

has

instanceOf

guards

has

instanceOf

Fig. 2. General Workﬂow Metamodel incorporating Sensor Guards.

a sensor guard during the execution of an activity step will be resolved with a high prob-

ability and lastly rollback and retry. For some details on workﬂow exception handling

refer to [12], for workﬂow evolution we’d like to refer the reader to [13] which features

a very mature framework and describes methods that support instance migrations and

ad-hoc instance changes. The example of the suspend and resume method shows, that

there is also a need for intelligent schedules for sensors, that can calculate in advance

when a sensor has to be switched on to collect data, so that a workﬂow instance that

uses a service that needs logged data for a certain time period to work.

4 Conclusions

We introduced an architecture that supports the modeling of sensor-aware workﬂows

and discussed techniques that are needed to implement our approach. Sensors offer

workﬂow management systems information about the environment and allow the exe-

cution of workﬂow to depend on the context of the process execution. Since the context

may change during the execution we introduced workﬂow sensor guards which are an

extension to the already powerful mechanism of data guards for the treatment of data

aspects in WfMSs. Guards can be deﬁned in the workﬂow deﬁnition and are enabled to

GetHumidity()

A B

Simple > 30

S S S

Active Passive Simple

Guard G: < constraint >

Fig. 3. Workﬂow with Sensor Guard.

protect the workﬂow from unrecognized changes in the context. When a sensor value

leaves the range of expected values the guard raises an exception and the workﬂow sys-

tem can react with the usual exception handling mechanisms. So sensors and guards

allow the creation of context-aware workﬂows and support the monitoring and steering

of the control ﬂow through data provided by sensors.

References

1. Dey, A.K.: Understanding and using context. Personal Ubiquitous Comput. 5 (2001) 4–7

2. Eder, J., Lehmann, M.: Workﬂow data guards. In: OTM Conferences (1). (2005)

3. Combi, C., Gambini, M.: Flaws in the ﬂow: The weakness of unstructured business process

modeling languages dealing with data. In: Proc. CoopIS 2009. Volume 5870 of LNCS.,

Springer (2009)

4. Salber, D., Dey, A.K., Abowd, G.D.: The context toolkit: aiding the development of context-

enabled applications. In: CHI ’99: Proceedings of the SIGCHI conference on Human factors

in computing systems. (1999)

5. Ardissono, L., Furnari, R., Goy, A., Petrone, G., Segnan, M.: A framework for the manage-

ment of context-aware workﬂow systems. Proc. of WEBIST 2007, 3rd Int. Conf. on Web

Information Systems and Technologies (2007)

6. Wieland, M., Kopp, O., Nicklas, D., Leymann, F.: Towards Context-Aware Workﬂows. In:

CAiSE07 Proceedings of the Workshops and Doctoral Consortium Vol.2, 2007, Tapir Aca-

demic Press (2007)

7. Wieland, M., Kaczmarczyk, P., Nicklas, D.: Context Integration for Smart Workﬂows. In:

Proceedings of the Sixth Annual IEEE Int. Conf. on Pervasive Computing and Communica-

tions, IEEE computer society (2008)

8. Modafferi, S., Benatallah, B., Casati, F., Pernici, B.: A methodology for designing and

managing context-aware workﬂows. In: Mobile Information Systems II. (2005)

9. Shin, K., Cho, Y., Choi, J., Yoo, C.W.: A workﬂow language for context-aware services. In:

MUE ’07. Multimedia and Ubiquitous Engineering, 2007. (2007)

10. Luckham, D.C.: The Power of Events: An Introduction to Complex Event Processing in

Distributed Enterprise Systems. Addison-Wesley Longman Publishing Co., Inc., Boston,

MA, USA (2001)

11. Hallerbach, A., Bauer, T., Reichert, M.: Guaranteeing soundness of conﬁgurable process

variants in provop. In: CEC ’09: Proceedings of the 2009 IEEE Conference on Commerce

and Enterprise Computing. (2009)

12. Eder, J., Liebhart, W.: The workﬂow activity model wamo. In: Third International Confer-

ence on Cooperative Information Systems (CoopIS 1995). (1995)

13. Dadam, P., Reichert, M.: The adept project: a decade of research and development for robust

and ﬂexible process support. Computer Science - R&D 23 (2009) 81–97

14. Wieland, M., K

appeler, U.P., Levi, P., Leymann, F., Nicklas, D.: Towards Integration of

Uncertain Sensor Data into Context-aware Workﬂows. In: Tagungsband INFORMATIK

2009. (2009)