Designing Evolutionary Workflow Processes:
a Version-based Approach
Mohamed Amine Chaâbane, Lotfi Bouzguenda,
Rafik Bouaziz, Faïez Gargouri
Laboratoire MIRACL, ISIMS
Route de Tunis, km 10, BP 242, 3021 Sakeit Ezzit
Sfax, Tunisia
ma.chaabane@fsegs.rnu.tn
Abstract— Nowadays, it is important to consider the fast
changing environment which drives organizations to frequently
adapt their Workflow Processes (WP). Consequently, this paper
deals with the design of Evolutionary Workflow Processes
(EWP). EWP refer to any modification of the tasks and their
coordination (process model), actors and roles (organizational
model), and/or data (informational model). First, this paper
proposes a global approach to ease EWP design, specification
and implementation. Second, it defines a meta-model for EWP
design. More precisely, this meta-model captures all the concepts
involved in the design of WP, and integrates the notion of version
in order to describe the evolution of WP.
Keywords- workflow processes, evolution, versions
I. INTRODUCTION
Nowadays, organizations have to take into account the open
and dynamic worldwide economic context in which they are
involved. Indeed, this changing context leads them to
frequently change their workflow processes (or business
processes). The problem of Evolutionary Workflow Processes
(EWP) is consequently important and is still open [1].
The EWP problem has been addressed several times using
an adaptive workflow approach. This approach consists in
changing schemas of workflow processes, and adapting and
migrating their corresponding instances [2, 3, 4]. However, in
adopting this adaptive workflow approach, it is impossible to
distinguish between temporary and permanent changes of
workflow processes.
We think that, if we address this EWP problem using a
version perspective, it is then possible to describe both
temporary and permanent changes since:
• we keep track of evolutions and changes of derived or
alternative workflow processes, each one representing
a possible schema for a considered workflow process,
• we permit different instances of a same workflow
process to have different schemas.
In the workflow context, where long term processes are
involved, adaptation of workflow process instances according
to a new schema is not always easy and is sometimes
impossible. So, it is important to be able to manage different
schemas for a workflow process in order to allow several
Eric Andonoff
Laboratoire IRIT, Université Toulouse 1
2 rue du Doyen Gabriel Marty
31042 Toulouse Cédex, France
andonoff@univ-tlse1.fr
instances of this workflow process to own different schemas.
Thus, versions are a promising solution to deal with EWP.
Versions are used in several fields of computer science in
which was highlighted the need of describing the evolution of
real world entities over time: versions are used to keep
different states of an entity (not only the last one), these states
corresponding to the different versions of the considered entity.
Versions are used in the database field, mainly in object-
oriented databases [5, 6], temporal databases [7, 8] or scientific
databases [9]. But also for specific database application fields,
such as computer aided design or computer aided
manufacturing [10, 11]. Versions are also used in software
engineering to handle software configurations [12]. Finally,
versions are considered in conceptual models such as the Entity
Relationship model [13, 14], the OMT model [15] or the UML
model [16]
Nevertheless, to the best of our knowledge, only few efforts
have been put on management of versions in the workflow
context. For instance, [1] and [17] have addressed the
workflow change context using versions. [1] has proposed a
solution to deal with workflow schema evolution that is based
on workflow type versioning and workflow migration. More
particularly, [1] investigated instance migration issues. [17] has
discussed version-based evolvement of workflow process
schemas. More precisely, [17] defined a method to handle
workflow process schema definition through the notion of
preserving directed graph.
However, both [1] and [17] addressed the version issue of
WP only considering what is called in workflow literature the
“process model”, which describes the tasks involved in the
process and their coordination. But, using only this model is
not enough to have a comprehensive description of workflow
processes [18]. Two others models have to be considered: the
organizational model and the informational model. The former
model structures the workflow actors and authorizes them,
through the notion of role, to perform tasks making up the
processes. The latter model defines the structure of the
documents and data required and produced by the processes.
These two models are glued together with the process model
since, in addition to the tasks and their coordination, the
process model also defines the required resources (information,
actors) to perform the tasks.
 Consequently, this paper addresses the Evolutionary
Workflow Processes (EWP) issue adopting a comprehensive
approach, i.e. considering the organizational, informational and
process models of workflow processes.
More precisely, this paper proposes a framework for
designing, specifying and implementing EWP. It also addresses
the EWP design problem as follows:
• it specifies a meta-model for workflow process design
which captures all the concepts involved in the three
models of workflow processes,
• it extends this meta-model in order to be able to define
versions of workflow processes by adding, deleting or
updating elements of the three workflow process
models (e.g. processes, tasks, actors, documents).
The remainder of this paper is organized as follows. Section
2 presents our approach for EWP design, specification and
implementation. Section 3 introduces the meta-model we
propose for designing WP while section 4 explains how to
make the modeled workflow processes evolutionary. Finally,
section 5 discusses the advantages of the proposed solution
compared to related works and concludes the paper.
II. A FRAMEWORK FOR EWP DESIGN, SPECIFICATION AND
IMPLEMENTATION
The framework we propose for Evolutionary Worflow
Processes (EWP) design, specification and implementation is
presented in figure 1 below.
Conceptual
Level
EWP meta model
WP meta model Designer
+
WP Versions
Versioning kit
Logical
Level
Translation rules Translation kit
Yawl Language
BPEL XPDL BPMN WfNET
Physical
Level
PETALS Bonita ... ...
VPM
Figure 1. A Framework for EWP Design, Specification and Implementation
In this framework, we distinguish three abstraction levels,
each one corresponding to a specific activity: the conceptual
level for EWP design, the logical level for EWP specification,
and the physical level for EWP implementation.
The basis of the conceptual level is a meta-model for EWP,
composed of a meta-model for classical Workflow Process
(WP) description, and a versioning kit to support the modeling
of workflow processes versions. A designer has to instantiate
this EWP meta-model in order to define versions of an
evolutionary workflow process. These versions are linked
together with a is-derived-from relationship.
The logical level provides a translation kit and a set of
translation rules to define a specification of a workflow process
version. A specification is given according to a language; we
propose, in our framework, translations into the main current
business process languages: BPEL [19] which is considered as
the industrial standard for service oriented applications, XPDL
[20] or BPMN [21] which are recommended by the Workflow
Management Coalition and the Object Management group,
WfNet [22] or Yawl [23] if one follows van der Aalst’s
propositions.
Finally, the physical level corresponds to implementation
tools such as, for instance, Petals for a BPEL specification,
Bonita or Virtual Process Machine for an XPDL specification,
the Yawl system, …
This paper only deals with evolutionary workflow
processes design (conceptual level). The two others levels
(logical and physical) are not addressed here. The following
sections respectively introduce the Workflow Process (WP)
meta-model and show how we extend it with versions.
III. A META-MODEL TO DESIGN WP
As mentioned before, a workflow meta-model must allow
the expression of three workflow complementary aspects,
usually described through three different interacting models:
the organizational, informational and process models. The
main important model is the process model which defines
component tasks and their coordination, but this model also
refers to the organizational model and to the informational
model defining required and produced resources before and
after tasks execution [18].
WP Version
But does such a meta-model for WP design (i.e. meeting
the previous requirement) already exist or do we have to define
WP Version a new one by ourselves?
Unfortunately, workflow meta-models defined in the
literature do not have a comprehensive approach considering
these three workflow complementary aspects but rather focus
on tasks description and their coordination (e.g. [24], [25],
[26]). Consequently, we have defined our own meta-model
which answers to the previous requirement. This meta-model is
shown in figure 2.
YAWL In this UML meta-model, a workflow process is composed
of tasks which can be atomic or composite. A composite task is
itself recursively composed of atomic or composite tasks. A
composite task also uses a workflow pattern which participates
to the definition of task coordination. In our meta-model, the
main workflow patterns described in the literature (sequence,
split, choice…) are provided. An atomic task can have pre-
conditions and post-conditions, and performs one or several
actions. A task is performed by a role (belonging to the
organizational model) and consumes and/or produces
informational resources (belonging to the informational
model). Informational resources correspond to system data,
workflow data (i.e. data, document or form), and application
data (i.e. database and data repository). A role is played by an
actor belonging to some organizational units. An actor is a
human or a not human (machine or software) resource. Finally,
an actor may be internal or external.
 Workflow Process Process Model version may be deleted but not updated. To describe a new
1..* is_composed_of 1
Workflow Pattern state of this entity, we have to derive a new version (from the
frozen one). A working version is a version that temporarily
is_composed_of 1..*
Composite Task
1..* 0..* 0..* Pre-Condition
Task
0..*
has_pre-conditions describes one of the entity states. It may be deleted and updated
Atomic Task
1..*
1..* has_post-conditions
execute
0..*
Post-Condition to describe a next entity state. The previous state is lost for the
benefit of the next state.
1..*
1..* 1..*
1..* 1..*
Action
performed_by
produces
consumes

Organizational Model
B. The Versioning Kit and its integration into the Meta-
Informational Model
1..* 1..*
Informational
1
Role
1..* 1..*
Organizational Unit
model for EWP Design
resource
0..* played_by
Actor
0..*
1..* member
This kit is composed of a set of classes, properties and
relationships which make classes of the previous meta-model
1..*
Workflow System Application 1..* use
Data Data Data
Not Human Human Internal External
“versionable”. A class is called “versionable” if its instances
Data Document Form Data
Repository
Database
1..*
Software Machine are versions [11, 15]. We propose to introduce the notion of
version for only some classes of the previous meta-model.
Figure 2. Meta-model for WP Design Regarding the process model, we propose to keep versions
for only two classes: the Workflow Process and the Atomic
Task classes. It is indeed interesting to keep track of evolution
IV. ADDING VERSIONS TO DESIGN EWP
for both workflow processes and atomic tasks since this
This section shows how we introduce the notion of version evolution corresponds to changes in the way that business is
in the previous meta-model in order to be able to capture a carried out. For instance, new customer requirements may
series of workflow processes evolutions and changes, each one imply to organize the activity of an organization in order to
representing a possible schema for a considered workflow increase the level of its production. At the atomic task level,
process. versions describe changes in activities realization, while at the
Firstly, we define the notion of version. Then, we introduce workflow process level, versions describe changes in work
the versioning kit we add to the previous meta-model and give organization (coordination of activities). We defend the idea
an example of an evolutionary workflow process. Finally, we that tasks and workflow processes versioning is important to
define a set of operations for management of workflow help organizations to face the fast changing environment in
processes’ versions. which they are involved nowadays.
Regarding the others models, it is necessary to handle
A. The Version Concept versions for the Informational resource class from the
In order to clearly present the versioning kit we briefly informational model, and versions for the Role class from the
introduce the basic concepts for versions [11, 15]. organizational model.

A real world entity has characteristics which may evolve
during its life cycle: it has different successive states. In
systems which provide version management, this entity is
described by a set of versions. A version corresponds to one of
the significant entity states.
E1.v0
Entities
E1
En.v1
En
En.v0
Figure 3. The Version Concept
As shown in figure 3, versions are linked by a derivation
link and they form a version derivation hierarchy. When
created, an entity is described by only one version. The
definition of every new entity version is done by derivation
from a previous one. Such versions are called derived versions
(e.g. E1.v1 is a derived version from E1.v0). Several versions
may be derived from the same previous one. They are called
alternatives (e.g. E1.v2 and E1.v3 are alternatives derived from
E1.v1).
A version is either frozen or working. A frozen version
describes a significant and final state of an entity. A frozen
As mentioned before, for each of these “versionable”
classes, we define a new class which contains versions (a
“versionable” class), called “Version of…”. We also specify
two new relationships: (i) the is_version_of relationship which
links a class (an “entity” class) to its corresponding “Version
of…” class (“versionable” class), and (ii) the derived_from
E1.v1 E1.v2 relationship which describes version derivation hierarchies.
Versions This latter relationship is reflexive. The underlying idea of our
E1.v3 proposition is to describe both entities and their corresponding
versions as indicated in figure 3. Consequently, (i) versions are
En.v2
En.v3
therefore involved in the process definition, and (ii) a couple
version and corresponding entity are obviously created when
the first version of an entity is created. Regarding properties of
these “versionable” classes, we introduce the version number,
creator name, creation date and status properties in the
“Version of “ classes.
Figure 4 below presents the new obtained meta-model in
terms of classes and relationships.
C. EWP Modeling Example
In order to illustrate the utilization of the EWP meta-model,
i.e. its instantiation, we propose to model a simplified and
revisited version of the workflow process example introduced
in [17]: the Production example. This voluntary simplified
example illustrates a production business process and involves
a factory which owns one production pipeline following the The solution we provide to model theses derivation
workflow process shown in figure 5(a). hierarchies consists in instantiating the EWP meta-model. The
Version of is_version_of
Workflow Process, the Atomic Task “versionable” classes and
Workflow Process
1..*
1..*
derived_from
1
Workflow Process
is_composed_of 1
Process Model
their “Version of…” corresponding classes are involved in this
is_composed_of 1..*
Workflow Pattern
instantiation, along with the Composite Task and Workflow
1..* 0..*
Composite Task
0..* 0..* Pre-Condition Pattern none “versionable” classes. This instantiation is
visualized in figure 7 below.
has_pre-conditions
Task derived_from
1..*
1..* has_post-conditions 0..*
1 1..* Version of Post-Condition
Atomic Task execute
Atomic Task is_version_of
1..*
1..*
1..*
1..*

1..*
Action The process model of the four versions of the Production
produces
performed_by
workflow process can be seen as follows:
consumes

1..* 1..* Informational Model

is_version_of
Role
Production.v1 = Seq (SP, P, QC, Pa),
1 1..* 1
Informational is_version Version of
resource 1
_of
1..*
Informational
resource
derived_from Version of Role
0..*
1..* 1..* Organizational Unit
0..*
1..* member
Production.v2 = Seq (SP, Sp-Jo (P, P), QC, Pa),
1..*
derived played_by
Actor

Workflow System Application 1..* use

_from
Production.v3 = Seq (SP, Sp-Jo (FUP, P), QC, Pa),
Data Data Data Not Human Human Internal External

1..* Production.v4 = Seq (SP, Sp-Jo (P(m), P), QC, Pa),

Data Form Data Database
Document Repository Software Machine Organizational Model
where SP stands for Schedule Production, P for Produce,
Figure 4. The EWP Meta-model
QC for Quality Checking, Pa for Packaging, FUP for Fix
Unqualified Products, P(m) for Produce (manual), Seq for the
This production business workflow includes several workflow pattern sequence and Sp-Jo for the workflow pattern
activities: production scheduling, production using a work Split-and-Join.
center, quality checking and packaging. In order to increase its Version of
productivity, the factory decides to add a new work center. The Workflow Process
derived_fromrelationship is_version_of
workflow process is then updated as shown in figure 5(b). If [vwp1, v1, wp1, nil, ct1, ...]
[vwp2, v2, wp1, vwp1, ct2, ...]
Workflow Process inverse relationship
[wp1, Production, {vwp1}, ...]
one of the two work centers, for instance work center#1, has a [vwp3, v3, wp1, vwp2, ct3, …]
structure of the
[vwp4, v4, wp1, vwp2, ct4, …]
technical problem and consequently is removed from the worflow process
version
Version of
Atomic Task
process for maintenance, two solutions are proposed to attempt Composite Task
is_version_ofelationship
r
[vat1, nil, at1, nil, ...] derived_from
keeping the production output: fixing unqualified products or [ct1, wpa1, {vat1, vat2, vat4, vat5}, ...]
[vat2, v1, at2, nil, ...] relationship
[vat3, v2, at2, nil, ...]
using employees for manual production. The workflow process [ct2, wpa1, {vat1, ct5, vat4, vat5}, ...]
[vat4, nil, at3, nil, ...] is_version_ofelationship
r
[ct3, wpa1, {vat1, ct6, vat4, vat5}, ...]
is then updated as shown in figure 5(c) and 5(d). [ct4, wpa1, {vat1, ct7, vat4, vat5}, ...]
[vat5, nil, at4, nil, ...]
[vat6, nil, at5, nil, ...] is_version_of
inverse relationship
[ct5, wpa2, {vat2, vat2}, ...]
[ct6, wpa2, {vat6, vat2}, ...] Atomic Task
Start Start Start Start [ct7, wpa2, {vat3, vat2}, ...]
5(a) 5(b) 5(c) 5(d) [at1, Schedule Production, {vat1}, ...]
Workflow Pattern [at2, Produce, {vat2, vat3}, ...]
workflow pattern
[at3, Quality Checking, {vat4}, ...]
Schedule Production Schedule Production Schedule Production Schedule Production [wpa1, Sequence]
which structures the [at4, Packaging, {vat5}, ...]
composite task [wpa2, Split-and-Join] [at5, Fix Unqualified Products, {vat6}, ...]

Produce Produce Produce Fix Unqualified Produce Produce Produce

Products (Manual)

Figure 7. Instantiation of the EWP Meta-model

Quality Checking Quality Checking Quality Checking Quality Checking

Packaging Packaging Packaging Packaging D. Operations for Version Management

In this section, we only focus on the two main operations
End End End End
for version: create and derive. The derive operation
corresponds to the creation of a version from an existing one
Figure 5. Evolution of the Production WP while the create operation corresponds to the creation of a
version at the first level of the derivation hierarchy (i.e. from its
This example highlights, as illustrated in figure 6, two corresponding entity). These operations are implemented as
derivation hierarchies. The first one is the Production workflow methods in each “Version of …” (“versionable”) class for the
process one, while the other one is the Produce task one. derive operation and in each “entity” class for the create
operation.
Entities Versions
More precisely, the derive operation for a task consists in
Production.v2 Production.v3
adding, deleting or updating pre-conditions, post-conditions,
Workflow Process Production
Production.v1 Production.v4 actions, informational resources and/or roles. The derive
operation for a workflow process consists in adding, deleting or
Task Produce
Produce.v1 updating composite and/or atomic tasks, in choosing other
Produce.v2 workflow patterns, and in deriving atomic tasks. The derive
operation for an informational resource corresponds to an
update of the resource while the derive operation for a role
Figure 6. Workflow Process and Task Derivation Hierarchies
consist in adding, deleting or updating actors and/or
organizational units.
 In addition to these two main operations, we also propose
specific operations for version selection and version hierarchy
selection. Because of space limitation, we do not detail here
these selection operations.
V. DISCUSSION AND CONCLUSION
This paper deals with Evolutionary Workflow Processes
(EWP) using versions. More precisely, it has presented a
solution for the design of EWP defining: (i) a meta-model to
design Workflow Processes (WP), and (ii) a versioning kit to
support the modeling of WP versions.
We distinguish two main approaches to deal with WP
evolution: an adaptation-based approach and a version-based
approach.
In the adaptation-based approach, evolution of WP consists
in changing workflow processes schema, and adapting and
migrating their corresponding instances. The most
representative works of this approach are the Peter Dadam’s
and Stefanie Rinderle’s ones [2, 3]. But, using this approach, it
is impossible to keep different schemas of a workflow process.
Moreover, as defended in the introduction and in [17], several
different schemas of a workflow process may conjointly exist.
That is the reason why few research efforts (but very few in
fact) have been done to deal with EWP adopting a version-
based approach. The main works adopting this approach are [1,
14]. [1] proposed a solution to handle workflow type
versioning and workflow migration investigating more
particularly instance migration issues. [17] also discussed
version-based evolvement of workflow process schema. More
precisely, [17] defined a method to handle workflow process
model schema definition through the notion of preserving
directed graph.
Our proposition differs from the previous works in two
main points.
First, we propose a framework for EWP design,
specification and implementation. Even if this framework is in
its first definition step, it is intended to become a tool for
management of workflow processes versions. Such a tool
permits the specification of running workflow process versions
from their corresponding conceptual representations, and also
includes an adaptation strategy used if necessary.
Second, we propose a meta-model for EWP design which
integrates in a comprehensive approach the three workflow
dimensions, i.e. information, organization and process
dimensions. This meta-model defines a set of classes to
describe workflow processes, identifies classes for which it is
necessary to handle versions, and consequently add a set of
classes, properties and relationships (versioning kit) to describe
versions of workflow processes. This meta-model also defines
a set of operations for management of workflow process
versions. Regarding the set of classes, we have described some
concepts (such as workflow pattern, pre-condition, post-
condition and action) as classes in order to enable their sharing
between several versions of workflow processes and tasks.
Consequently, we only need to store the differential between
two derived or alternative versions, thus avoiding redundancy
and reducing storage space.
As future work, we plane to implement our framework for
EWP design in order to be able to define workflow process
versions. This implementation will obviously integrate a tool
for a graphical representation of the modeled workflow
processes. We also plane to implement the translation kit along
with a set of translation rules to define, using a “logical”
language (i.e. a language relevant from the logical level), a
specification of a workflow process version.
REFERENCES
[1] M. Kradofler, and A. Geppert, “Dynamic Workflow Schema Evolution
based on Workflow Type Versioning and Workflow Migration”, Int.
Conf on Cooperative Information Systems, Edinburgh, Scotland,
September 1999, pp. 104-114.
[2] M. Reichert, and P. Dadam, “ADEPTflex: Supporting Dynamic Changes
of Workflow without Loosing Control”, Int. Journal on Intelligent
Information Systems, 10(2), 1998, pp. 93-129.
[3] S. Rinderle, M. Reichert, and P. Dadam, “Disjoint and Overlapping
Process Changes: Challenges, Solutions and Applications”, Int. Conf on
Cooperative Information Systems, Agia Napa, Cyprus, October 2004,
pp. 101-120.
[4] P. Kammer, G. Bolcer, R. Taylor, and M. Bergman, “Techniques for
supporting Dynamic and Adaptive Workflow”, Int. Journal on
Computer Supported Cooperative Work, 9(3/4), 2000, pp. 269-292.
[5] W. Cellary, and G. Jomier, “Consistency of Versions in Object-Oriented
Databases”. Int. Conf. on Very Large DataBases, Brisbane, Australia,
August 1990, pp. 432-441.
[6] E. Sciore. “Versioning and Configuration Management in Object-
Oriented Databases”. Int. Journal on Very Large Databases, 3(1), 1994,
pp. 77-106.
[7] S. Gançarski, “Database Versions to Represent Bitemporal Databases”.
Int. Conf. on Database and Expert Systems Applications, Florence,
Italia, September 1999, pp. 832-841.
[8] R. Bouaziz and Z. Brahmia,“Gestion des données temporelles dans un
environnement multi-versions de schémas”, int journal Revue des
Sciences et Technologie de l’Information (RSTI), Série Technique et
Science Informatique (TSI), 2008, in press.
[9] I. Chen, V. Markowitz, S. Letovsky, P. Li, and K. Fasman, “Version
Management for Scientific Databases”. Int. Conf. On Extended
Database Technology, Avignon, France, March 1996, pp. 289-303.
[10] HT. Chou, and W. Kim, “A Unifying Framework for Version Control in
a CAD Environment”. Int. Conf. on Very Large DataBases, Kyoto,
Japan, August 1986, pp. 336-344.
[11] R. Katz. “Towards a Unified Framework for Version Modelling in
Engineering Databases”. Int. Journal on Computing Surveys, 22(4),
1990, pp. 375-408.
[12] J. Kimball, and A. Larson, “Epochs: Configuration Schema, and Version
Cursors in the KBSA Framework CCM Model”. Int. Workshop on
Software Configuration Management, Trondheim, Norway, June 1991,
pp. 33-42.
[13] J. Roddick, N. Craske, and T. Richards, “A Taxonomy for Schema
Versioning based on the Relational and Entity Relationship Models”.
Int. Conf. on the Entity Relationship Approach, Arlington, Texas, USA,
October 1993, pp. 137-148
[14] R. Bouaziz, M. Mkaouar and M. Moalla, “Intégration de la dimension
temporelle au modèle entité-relation”, INFORSID conf, Hammamet,
Tunisia, juin 2006, PP 531-546.
[15] E. Andonoff, G. Hubert, A. Le Parc, and G. Zurfluh, “Integrating
Versions in the OMT Models”. Int. Conf. on the Entity Relationship
Approach, Cottbus, Germany, October 1996, pp. 472-487.
[16] M. Mkaouar and R. Bouaziz, “UML-TF : un profil UML pour la
représentation des faits temporels”, int journal Revue des Sciences et
 Technologie de l’Information (RSTI), Série Technique et Science
Informatique (TSI), vol. 26 – n°3-4, 2007, pages 305-338.
[17] X. Zhao, and C. Liu, “Version Management in the Business Change
Context”. Int. Conf. on Business Process Management, Brisbane,
Australia, September 2007, pp. 198-213.
[18] W. van der Aalst, “Inter-Organizational Workflows: An Approach
Based on Message Sequence Charts and Petri Nets”. Int. Journal on
Systems Analysis, Modelling and Simulation, 34(3), 1999, pp. 335–367.
[19] Oasis Web Services Business Process Execution Language Technical
Committee, “Web Services Business Process Execution Language
Version 2.0”. Available at http://docs.oasis-open.org/wsbpel/2.0/wsbpel-
v2.0.pdf, April 2007, pp.1-264.
[20] Workflow Management Coalition, “The XML Process Definition
Language”. Available at http://www.wfmc.org/standards/xpdl. htm.
[21] Object Management Group, “The Business Process Modeling Notation”.
Available at http://www.bpmn.org/.
[22] W. van der Aalst, “Verification of Workflow Nets”. Int. Conf. on
Application and Theory of Petri Nets, Toulouse, France, June 1997, pp.
407-426.
[23] W. van der Aalst, L. Aldred, M. Dumas, and A. ter Hofstede, “Design
and Implementation of the YAWL System”. Int. Conf. on Advanced
Information Systems Engineering, Riga, Latvia, June 2004, pp. 142-159.
[24] M. Rosemann, and M. zur Muehlen, “Evaluation of Workflow
Management Systems: a Meta-model Approach”. Australian Journal of
Information Systems, 6(1), 1998, pp. 103-116.
[25] B. List, and B. Korherr, “An Evaluation of Conceptual Business Process
Modelling Languages”. Int. Symposium on Applied Computing, Dijon,
France, April 2006, pp. 1532-1539.
[26] K. Lei, and M. Singh, “A Comparison of Workflow Meta-models”,
Workshop on Behavioural Modelling and Design Transformations:
Issues and Opportunities in Conceptual Modelling, Los Angeles, CA,
USA, November 1997, available at http://osm7.cs.byu.edu/
ER97/workshop4 /ls.html.