Giancarlo Tretola and Eugenio Zimeo
Department of Engineering, University of Sannio, 82100, Benevento, Italy
Keywords: Service composition, Adaptation, Monitoring, Event-driven programming.
Abstract: A fundamental requirement for modern large-scale distributed applications is the need to quickly adapt to
the fast variations in their operational environment. In SOA the need for adaptation influences design,
enactment and execution of service compositions (workflows). To maintain a high quality standard and to
support continuous improvements of workflows, the quality of intermediate steps has to be assessed during
execution and, if needed, interventions have to be performed at the same time. The key concept is to avoid
problems, anticipating the detection of their causes. We propose a monitoring system based on the definition
of general management policies that are translated in management rules using an event-driven approach.
Rules are employed to react to unexpected events, malfunctions, errors or violations of constraints with the
objective of dynamically adapting the process in order to overcome the problems still maintaining a high-
quality delivery.
Workflow management is becoming an effective
approach for distributed application development
using the Internet as infrastructure and services
composition as programming paradigm for
exploiting distributed resources and functionalities,
both in Web environment (Natis and Schulte, 1996;
Peltz, 2003) and Grid computing (Czajkowski et al.,
2001; Foster et al., 2002).
In these contexts, service performance, reliability,
responsiveness and other quality related features
might change dynamically and quickly. The ability
of the process to reach the functional goal and to
satisfy QoS constraints must be dynamically
adjusted consequently (Buhler and Vidal, 2005).
Workflow paradigm is naturally oriented to
analyze the achieved results in order to improve the
process definition: Adaptive Workflows (Tretola,
2007; Buthler and Vidal, 2005; Sheth and Verma,
2005). Adaptivity needs agents able to interact with
the services and the execution environment for
retrieving and analyzing the information of interest
in order to identify anomalies. Process anomalies
can be classified in three categories: behavioural,
caused by improper execution of process activities;
semantic, caused by logically erroneous results after
activity execution; systemic, caused by
malfunctioning of the supporting infrastructure.
In order to intercept anomalies during process
execution, monitoring plays a fundamental role. It is
intended as a planned or event-driven measurement
of one or more properties of a workflow instance in
order to identify anomalies. Monitoring is useful to:
measure the actual QoS of the provided services for
comparison to the declared one; verify the
compliance of the running process with constraints
and requirements and to detect the deviation from
the plan; enable manual and automatic corrective
actions able to handle unexpected events; collect and
store the information related to all the processes
executed, in order to support further analysis aimed
at processes improvement; monitor the operational
environment in which the process is executed and to
enable adaptation to changes.
We propose an approach for measuring and
evaluating data, on the way, which may alert the
system of incoming problems in order to avoid
further complications. The actions that may be
undertaken are operation related to the control flow
of the process, rescheduling or re-planning. The
action may be also related to the binding of a
functionality to another performer. To complete the
approach it is necessary to underline the necessity to
have a semantic definition of the entities involved in
the monitoring and the related measurement
processes usable for obtaining numerical
information about such entities (Giallonardo and
Zimeo, 2007; LOCOSP Project).
Tretola G. and Zimeo E. (2009).
In Proceedings of the 4th International Conference on Software and Data Technologies, pages 423-428
DOI: 10.5220/0002282504230428
Figure 1: Monitoring system and related components.
The architectural component in charge of process
monitoring is the Monitor. It is a component that
analyzes the activities of the process and shows real-
time information about them, such as status and
advances. It is also able to interact with other kinds
of sensors or generally measurement tools to retrieve
information on the context that may influence the
process. The process monitor is also able to access
to information describing service semantics and
QoS. It also stores the collected data to enable post
execution evaluation and to compare the measured
QoS with the declared one.
The monitor behavior is based on the definition
of general management policies, defined for
handling with the problems that may arise during
execution. Such policies are translated in
management rules, prior to execution, using an
event-driven approach. Rules are employed to react
to unexpected events, malfunctions, errors or
violations of constraints with the objective of
dynamically adapting the process in order to
overcome the problems still maintaining a high-
quality delivery (Tretola, 2007).
Considering process composed using SOA approach
we may consider several works dealing with the
problem of monitoring. Such works may be
classified in three groups.
Language based. In this approach the
monitoring is performed using the built in features
offered by the process definition language. It is
similar to Exception handling in programming
languages. The monitoring policy is embedded in
the process definition.
Example: the approach proposed in Dellarocas
and Klein that acts before execution, associating to
exception processes for detection and avoidance.
Weaving. The monitoring policy is defined
independently from the process and its definition
language. Before executing the process its
monitoring policy is added to the process instance
and executed by the work. It is similar to Pre-
processing phase in some programming languages or
to the pre-execution binding. The monitor policy is
bound to the process instance.
Example: Monitoring rules are defined
separately and blended with the WS-BPEL process
at deployment-time (Green et al., 2000).
Dynamic. The monitoring policy is defined using a
specific definition language. Then the policy is
provided to specific components and services in the
execution system in charge of monitoring process
execution. It is similar to Event based systems. The
monitor policy is associated to the enactment
Examples: in Zeng et al. it is presented the
proposal to combine workflow management and
agents. responsible for monitoring QoS parameters,
introducing flexible variation in the process, using
predefined alternatives, and supervising of the
service process in execution by the provider.
Crossflow (Green et al., 2000) is a dynamic
approach to monitoring, performed by components
responsible for monitoring QoS parameters,
introducing flexible variation in the process, using
predefined alternatives, and supervising of the
service process in execution by the provider. In
Baresi and Guinea the approach is based on
managing exceptions through the ECA paradigm,
using CHIMERA-EXC language for specifying
exception handling, and ECA rules based approach
to monitor exception
Event Condition Action rules (ECA rules) have
been used in many settings, including active
databases (Patton, 1999; Widom and Ceri, 1995), for
triggering functionality based on data monitoring,
and workflow management, specifying and
implementing business processes (Bonifati, 2001).
They automatically perform actions in response to
events provided that stated conditions hold. ECA
rules allow for the management of an event, in
specified condition, by means of a predetermined
They are characterized by three parts: an Event
defines the event, among the set of observable
events, which the rule reacts to; a Condition
expresses the configuration of the state needed for
performing an action; an Action describes the
activity to be performed if the condition is verified.
The advantages of using ECA rules for checkpoint
modelling are several.
ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies
Monitoring requires a measurement process in order
to retrieve information from running processes. It
may retrieve information from: workflow instances,
running activities and produced artefacts. The
measurement is performed by dedicated
measurement tools able to provide the quantitative
evaluation of the monitored parameters. In order to
enable the retrieving of information, a common
description of such resources is needed to the
process designers and to the service providers.
An ontology-based model is a possible solution
for enabling interactions among system components
and to grant future extensibility of the system. The
ontology has to provide a common and shared model
for allowing measurements of basic parameters and
also for derived ones, which are obtained by
aggregating different parameters. Properties may be
related to: Internal properties of the workflow (i.e.
activity state, variable value, etc.) or External
properties (i.e. artefacts or quantity influenced or
influencing the process, QoS attributes, SLAs, etc.).
Furthermore, in order to take into account
context information it is necessary to perform
measurements from the environment of running
workflow instance. Measures may be related to two
main aspects: internal environmental conditions
influenced by or influencing the process execution
(i.e. the provisions in a warehouse, the latency in a
server, etc.) and external conditions influencing the
goal related to the process ((i.e. the increase of
demand or of the price of a product).
In order to describe quality parameters, and more
generally non-functional parameters of the
monitored resources, an adequate semantic model is
needed. A domain independent ontology is used to
define conceptual basis of the measurement, then a
domain dependent ontology has to be defined for the
specific operational environment (LOCOSP Project).
In our vision the Monitoring System is able to act at
run-time, measuring and managing the process in
execution. The approach proposed is based on the
concept of checkpoint: a point in the control flow in
which the Monitoring System performs some
measurements, evaluates the overall state of the
executing process, and may perform some actions.
A checkpoint is an additional concept added to
the control flow that represents a moment of
verification and validation of the process
progressing towards the goal regarding the non-
functional aspects of the performing activities. They
may be associated to a single activity, to a set of
activities or to a process instance. A checkpoint can
be viewed as a sub-process composed of the
sequence of two activities: monitoring and
The monitoring activity has the role to collect the
data necessary to asses the situation of the process
activity or activities to be monitored. The data
retrieved are examined to decide whether a
management procedure has to be started. In such
case, the appropriate procedure is selected and
Management procedure is related to a specific
interface, we have defined, for dynamic adaptation,
which allows run-time modification to the control
flow of a process instance in execution in the
workflow engine.
A checkpoint has an activation criterion, which
represents the triggering cause that starts the
checkpoint activities. It may be of different types:
synchronous, i.e. based on a temporal event;
asynchronous, i.e. based on the occurrence of non-
temporal events. A synchronous criterion is further
classified as absolute time, the specific date and
time in which the checkpoint has to be performed
(for example the 23rd of March at 15:00); relative
time, a time period starting from an event related to
the process execution (for example after 1 minute
from starting of a selected activity). An
asynchronous criterion is subdivided in generic
workflow events (e.g. the start of an activity) and
specific resource events generated during the
activity execution (e.g. the percentage of task
completion). Each activation criteria is bound to an
event that is generated internally, by the workflow
enactment system (first three types), or externally in
the service provider system (the fourth type).
The conceptual behaviour of a checkpoint is
based on the Event Condition Action paradigm
(ECA rules). It enables the separation of the
workflow definition from the monitoring policy.
Workflow enactment and checkpoint execution are
two parallel executing flows. The control flow of the
process defines the normal flow of the execution,
managed and supervised by the workflow engine.
The monitoring flow handles the reaction flow that
is responsible to handle the events fired during the
execution of the process. Different process instances
may be monitored with different policies.
Checkpoints are separated entities associated to the
process for the execution; therefore it is possible to
change or redefine them for each instance to be
enacted. Finally, since a checkpoint is event-based,
it is possible to use the same measurement tools and
management actions in several situations. It is
sufficient to associate them to the appropriate event.
When an event fires, the checkpoint starts the
execution: the monitoring process performs the
measurement of the interested parameters and
decides whether a management action has to be
performed. This is performed by evaluating an
activation condition, composed of logical (AND and
OR) and relational operators (greater than (>), less
than (<) and equal (=)). The operands can be of three
types: constant values known at design time; local
variables defined in the checkpoint context and
evaluated during the execution; workflow variables
retrieved from the process instance in the workflow
engine at execution time. It is worthy to note that
more than one checkpoint may be associated to a
single event. It is possible to have more than one
ECA rule that reacts to the same event, with
different conditions to be evaluated and different
management actions to be performed.
The Monitoring System is based on two main
interacting components: one is the observed system,
the workflow engine, and the other is the observer,
the Monitor, responsible to supervise the QoS
parameters of the process during its execution. After
a process is described, checkpoints can be associated
to it. In order to allow this, the observed and the
observer have to share the definition of the
observable parameters, the tools able to provide a
measure for them and the procedure to be used to
perform corrective actions. The selected model is a
shared ontology describing the QoS parameters of
the specific domain, obtained by specializing the
domain independent ontology. The ontology is used
both during the checkpoint definition, for selecting
which values have to be used for evaluating the
condition, and during the checkpoint execution, for
selecting the specific measurement process and for
assigning a measure to the entity according to the
defined metrics.
The Monitoring System is a general purpose
element able to dynamically adapt to parameters to
be monitored, using the ontology to act correctly.
The components of the systems and their roles are
shown in figure 2.
Process Definition Tools. They contribute to the
process definition. A prototype implementation
enables the definition of a process and related
Engine. It is the component responsible for the
process enactment. This is used as an observed
system. So it is characterised by an external interface
composed of two parts: sensing and effecting. The
sensing interface is used to access to the information
about the process and activities in execution. The
effecting interface is used to interact with the engine
for altering the structure of the process during its
Monitor. It represents the observer in the system. Its
role is to receive events, to execute the ECA rules
bound to the specified checkpoints, and to interact
with the engine using the sensing-effecting interface.
It is also able to interact with the measurement tools
in order to perform some parameter measurements
for evaluating the conditions.
Measurement Tools. They are the set of external
tools that are able to measure and evaluate the QoS
parameters involved in the execution.
Management Tools. They are a set of tools that are
able to execute corrective actions on the executing
process control flow on the external environment
(i.e. Send a notification to a service provider).
Sensing-Effecting Interface. The Sensing interface
allows for retrieving information from the engine in
order to assess the state of the component. The
Effecting interface allows for managing the
Rule Engine. The checkpoint description, provided
using the XML language, is then translated into a
rule engine implemented with Jess (JESS). The rule
engine manages the ECA rules.
Figure 2: The overall system with the execution Engine
and the Monitor.
In order to allow the management, the Workflow
engine should allow access to the internal state of
the process instances that is in execution. In our
ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies
experimentation we have defined a set of operations
that are needed for allowing such modification.
First of all we have defined and implemented
operation for suspending and resuming a process
enactment, i.e. the activity are considered atomic
and enacted activities are completed, but no more
activity is activated for the execution. We
considered this policy for taking into account several
problems that may arise in adapting a process that
usually is based on distributed activities. What
happens if a triggering event arrives in the middle of
the distributed transaction? In our approach no
alteration of the running activities is performed, the
enactment is suspended and no other activity
execution is started.
While suspended a process may be dynamically
modified using other operation we have introduced.
It is possible to add an activity in the control flow,
updating the transitions in the process graph. It is
also possible to remove an activity from the control
flow also in this case updating the transitions in the
control flow, removing the unnecessary ones. We
have also implemented operations that allows for
altering the activities start-line and deadline in order
to perform a re-scheduling of the activities
enactment without changing the process control
flow. We are considering also other operation: for
example re binding to perform a different selection
of another resource to execute an activity. Other
operations are under evaluation, for example re-
planning of the single instance or re-planning of the
original process description and so on.
The ECA rules are managed by a Knowledge
Base or an Agent. In our test we used a JESS engine,
in which fact and rules are asserted basing on two
categories. The first one is the generic rules that are
applicable to any process because are related to
events that may happen in each workflow, i.e. a
service not reachable. To the second categories
belong the rules that are specific of the particular
workflow and of its operative environment. The use
of a knowledge base is interesting because it may
works in two ways. One is based on reaction of the
engine to variation of the knowledge base, for
example assertion of a new fact, in order to check if
there are active rules. This may be used to perform
reaction to event received by the manager. Another
way of work for the engine is a backward reasoning,
in which a rule is analyzed in order to check if it is
active given the current facts and rules asserted in
the knowledge base.
In this section, we present a first example related to
a context monitoring scenario. In this case the
workflow process is related to management of
activities in a vineyard. The parameters under
measurement are environmental parameters:
temperature, humidity, wind velocity, luminosity
etc. The environmental information may be used to
reschedule activity in the vineyard, for example
repeating a treatment against parasites if “humidity
and the temperature are greater than known
CHECKPOINT: Parasite Avoidance
ON EVENT: Temperature
IF CONDITION: (temperature > 30) &&
(measured humidity > 0.75)
Another action we are considering in our virtual
experimentation is the using of heater during bad
season to decrease damage from frost.
ON EVENT: Temperature
IF CONDITION: (temperature > 5) &&
(measured wind < 0.5)
This is an example of a context aware application
in which there is no need to specify in the process all
the possible intervention in each possible moment
because the system reacts to the dangerous situation
modifying the process accordingly.
Nowadays, distributed applications, implemented
using workflow management, place a great
challenge. The large availability of services allows
for the possibility to select from a wide offer of
functionalities. Such functionalities are provided by
different organization and with different levels of
performance. The monitoring is then a fundamental
phase in the life cycle of workflow, for allowing the
possibility of fine tuning in the selection of services.
Collecting the measurement of the actual QoS of
invoked services allows for a greater confidence in
subsequent selection operations. Moreover,
monitoring provides a lot of information at run-time
that may be used to prevent problems. The detection
of a non conformity in QoS of a service that is in use
in a workflow may be dealt immediately, without
waiting consequent problems. Problems in the
interaction may be resolved without waiting errors
blocking the systems. The management action may
involve a rebinding of the activity to another service,
the rescheduling of activities in the process or the
planning of new activities to be executed to handle
the new situation. As we have seen activity and
process related values are not the only data that may
be used. Context measurement is also really useful
in the process management. They allow for
retrieving information, external to the specific
activities in execution that may alter the operational
environment, demanding for adaptation of the
process control flow, or even change the overall goal
of the process. Dynamic monitoring enables the
execution of process that otherwise may be not
described if not using complex syntax and detailed
description of each anomalies to be handled in the
control flow.
Our experimental work is related to SAWE
(SAWE) a Workflow Enactment System designed to
be autonomic and adaptive, able to execute process
using Web Services, Java local or remote objects,
and Grid resources. In our work we have defined a
conceptual checkpoint model and used an XML
extension to model it.
Future activities are related to the realization of a
higher level language for the definition of
monitoring policy coupled with the definition of an
interface for dynamically managing the process
execution. The objective is to make totally
automated the monitoring and the management.
The research activities of this work are framed in the
research project ArtDeco, funded by MIUR.
Tretola, G., 2007. Autonomic Workflow Management in
e-Collaboration Environment. Ph.D. Thesis.
Paton, N., 1999. Active Rules in Database Systems.
Widom, J., Ceri, S., 1995. Active Database Systems.
Morgan-Kaufmann, San Mateo, California.
Bonifati, A., Ceri, S., Paraboschi, S., 2001. Pushing
reactive services to XML repositories using active
rules. In Proc. 10th World-Wide-Web Conference.
Natis Y.V., Schulte, R.W., 1996. Service Oriented
Architectures, Part 1.
Peltz, C., 2003. Web Services Orchestration and
Choreography. Computer, vol. 36, pp. 46-52.
Giallonardo, E., Zimeo, E., 2007. More Semantic in QoS
Matching. In IEEE International Conference on
Service-Oriented Computing and Applications, pp.
Czajkowski, K., Fitzgerald, S., Foster, I., Kesselman, C.,
2001. Grid Information Services for Distributed
Resource Sharing. In: 10th IEEE International
Symposium on High Performance Distributed
Computing, pp. 181-194.
Foster, I., Kesselman, C., Nick, J., Tuecke, S., 2002. The
Physiology of the Grid: an Open Grid Services
Architecture for Distributed Systems Integration.
Technical report, Global Grid Forum.
Buhler, P. A., Vidal, J. M., 2005. Towards Adaptive
Workflow Enactment Using Multiagent Systems.
Information Technology and Management 6, pp. 61-
Sheth, A.P., Verma, K., 2005. Autonomic Web Processes.
Proceedings of the Third Conference on Service
Oriented Computing, International Conference on
Service Oriented Computing.
Dellarocas, C., Klein, M., 2000. A Knowledge-based
Approach for Handling Exceptions in Business
Processes. Information Technology and Management
1, pp. 155-169.
Zeng, L., Ngu, A., Benatallah, B, 2001. An Agent Based
Approach For Supporting Cross-Enterprise
Workflows. ADC, pp. 123-130.
Green, P., Aberer, K., Ludwig, H., Hoffner, Y., 2000.
Crossflow: Cross-Organizational workflow
Management For Service Outsourcing In Dynamic
Virtual Enterprises. IEEE Data Eng. Bull. 24(1), pp.
Baresi, L., Guinea, S., 2005. Towards Dynamic
Monitoring of WS-BPEL Processes. International
Conference on Service Oriented Computing, pp. 269-
Casati, F., Ceri, S., Paraboschi, S., Pozzi, G., 1999.
Specification and Implementation of Exceptions in
Workflow Management Systems, ACM Trans.
Database Syst. 24(3), pp. 405-451
LOCOSP Project,
ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies