Integrating JWT with Activiti

Master's Thesis in Computer Science
Integrating Java Workflow Tooling with
the Activiti process engine
A concept of transforming, executing,
deploying and monitoring business processes
Eugen Petrosean
(Matr-Nr. 1071092)
May 2014

Contents
Part 1 – Introduction.........................................................5
1 Motivation........................................................................................5
Part 2 – Introducing workflow concepts, terminology and
relations ...........................................................................7
2 Workflows – Introducing the basics of business processes..............7
2.1 Getting to know relationships between basic terminology............................7
2.2 Taking a closer look at the workflow reference model..................................9
2.3 Understanding workflow components........................................................10
3 Business Process Modeling and Notation – Introducing high-level
modeling with BPMN 2.0...................................................................13
3.1 Getting to know BPMN 2.0..........................................................................13
3.2 Walking around the business process management life cycle.....................15
3.3 Understanding the BPMN 2.0 meta model.................................................16
4 Java Workflow Tooling – Introducing the service-oriented JWT tool
stack..................................................................................................18
4.1 Getting to know Java Workflow Tooling......................................................18
4.2 Dealing with the Java Workflow Tooling meta model................................19
4.3 Understanding the implementation approach of the meta model .............21
5 Activiti – Introducing executable business processes in BPMN 2.0.23
5.1 Getting to know Activiti...............................................................................23
5.2 Getting familiar with the Activiti Engine component.................................25
5.3 Understanding execution and task listeners...............................................27
5.4 Deploying processes to the Activiti Engine.................................................28
6 Esper – Introducing complex event processing (CEP)....................29
6.1 Understanding business activity monitoring..............................................29
6.2 Understanding complex event processing..................................................30

6.3 Working with the event processing language..............................................31
6.4 Taking a closer look at the Esper CEP Engine............................................32
Part 3 – Integrating Java Workflow Tooling with the
Activiti process engine.....................................................34
7 Introducing a real business process................................................34
7.1 Analyzing the loan request process..............................................................34
7.2 Using decision tables in the loan request process ......................................35
8 Specifying integration requirements between Java Workflow
Tooling and the Activiti process engine.............................................37
8.1 Understanding integration challenges between JWT and Activiti..............37
8.2 Dealing with conceptional differences between JWT and Activiti.............38
8.3 Using the Activiti tool stack for extending JWT business processes ..........41
Part 4 – Implementing executable Java Workflow Tooling
business processes..........................................................42
9 Creating the JWT Extensions development environment...............43
9.1 Introducing the JWT Extensions approach ................................................43
9.2 Illustrating the JWT Extensions development process .............................46
9.3 Clarifying the implementation details of the JWT Extensions development
environment......................................................................................................48
10 Transforming Java Workflow Tooling business processes ...........55
10.1 Developing an in-memory transformation mechanism.............................55
10.2 Creating, mapping and appending target transformation elements........60
10.3 Applying a post-transformation mechanism ...........................................63
11 Executing Java Workflow Tooling business processes ..................66
11.1 Mavenizing Activiti dependencies..............................................................66
11.2 Generating service task listeners ...............................................................67
11.3 Specifying user tasks..................................................................................69
12 Deploying Java Workflow Tooling business processes..................74
12.1 Generating deployment archives................................................................74
12.2 Deploying processes via the Activiti Explorer...........................................75
13 Monitoring Java Workflow Tooling business processes................78
13.1 Specifying additional monitoring listeners ...............................................78
13.2 Understanding monitoring parameters....................................................84
13.3 Dealing with monitoring event types and queries.....................................87
13.4 Developing monitoring unit tests..............................................................92

13.5 Analyzing monitoring outputs...................................................................95
Part 5 – Summary............................................................98
14 Conclusions..................................................................................98
Appendix A.....................................................................101
Appendix B....................................................................103
Appendix C.....................................................................105
References.....................................................................107

Part 1 – Introduction
1 Motivation
In recent years, information technology has made huge steps forward, resulting in the
creation of new ways of organizing business processes.
At the beginning, the development of business processes implied that they were
developed with the assumption that business processes would be managed by people.
According to this approach, an organizational structure was developed under which
particular tasks were assigned to groups of people, or departments. Only then did
people consider whether information systems could support, or take over, the work.
Nowadays, business processes are designed in a more abstract way, without
considering implementation. Only then the information systems and the organization
can be designed hand in hand by deciding whether each task in a business process
should be performed by an information system or a person.
Information systems like word processors, drawing systems, spreadsheet systems,
database systems and electronic-mail systems are used to reduce people's workload in
offices but simultaneously they remain generic in nature and are not limited to a
specific business application, as, for example, accounting systems are.
Alongside with these information systems a new class of generic software for managing
business processes has been evolving – so-called workflow management systems.
Workflow management systems ensure that the right information reaches the right
person at the right time, or is submitted to the right computer application at the right
moment. Thus, they do not perform any of the tasks in a process but delegate their
execution to a specific application software.
In the past, the functional structure of an organization played the most important role
in how it was organized. Now, as already mentioned, business processes are crucial,
and therefore good tools are required to define and analyze business processes.
Today, Activiti represents one of the most powerful open-source workflow management
systems due to its concept and architecture. It is not only a generic workflow
management system but also a framework which can be integrated in every Java
application software. This vision to consider workflow management systems not as a
monolithic architecture, provides a graceful approach to use Activiti for different
development tasks in regard to business processes.
Java Workflow Tooling is another important attempt in scope of a research project to
provide a number of tools which would simplify the process of defining and improving
business processes. In order to have a mechanism of analyzing business processes, it is
important for business analysts to get insight into the execution of business processes.
This is not an easy task because Java Workflow Tooling does not have any mechanisms
to execute business processes and therefore the analysis of processes which targets at
improving them, seems to be impossible.
For this purpose, we consider two possibilities how we can deal with this problem:
either we implement a standalone solution for executing and monitoring processes, or
we use powerful components from the Activiti tool stack, integrate them with Java
5

Workflow Tooling, and implement afterwards only the monitoring mechanism. The
second choice is a more realistic one because we can rely on techniques and approaches
which were developed by people from the Activiti community with much technical
expertise in implementing such business process technologies.
That's why we are going to focus in this master's thesis on how we will integrate Java
Workflow Tooling with Activiti, and ensure that business processes defined within the
Java Workflow Tooling tool stack will become executable by means of Activiti, and then
on this basis implement monitoring aspects required for further analyses of business
processes. As Java Workflow Tooling is a tool stack for developing business processes
within Eclipse, the technological realization of integration aspects will be performed
from a developer's point of view by extending the Eclipse plugins of Java Workflow
Tooling and Activiti.
The remainder of this master's thesis is organized as follows. Part 2 introduces the
standard terminology developed by the Workflow Management Coalition (chapter 2)
and explains how these workflow concepts are applied in BPMN 2.0 (chapter 3), in
Java Workflow Tooling (chapter 4), and in Activiti (chapter 5). Furthermore, it provides
fundamental understanding of how business activity monitoring (chapter 6) can be
implemented in regard to mentioned workflow concepts.
Part 3 highlights the idea of how we are going to integrate Java Workflow Tooling with
Activiti. On the basis of a real business process (chapter 7) we will specify integration
requirements between the two technologies and illustrate possible difficulties of
integrating Java Workflow Tooling components with the Activiti tool stack (chapter 8).
Part 4 explains how we propose to implement the concept resulted from the integration
requirements between Java Workflow Tooling and Activiti. For this purpose we are
going to present an approach of creating a Java Workflow Tooling Extensions
development environment (chapter 10) to ensure that Java Workflow Tooling process
definitions can be transformed to Activiti/BPMN 2.0 process definitions (chapter 11),
executed by the Acitiviti process engine (chapter 12), deployed to the Activiti Explorer
(chapter 13), and afterwards monitored (chapter 14) according to techinques imple-
mented on the basis of knowledge presented in chapter 6.
6

Part 2 – Introducing workflow concepts, terminology and relations
Part 2 – Introducing workflow concepts,
terminology and relations
2 Workflows – Introducing the basics of business
processes
2.1 Getting to know relationships between basic
terminology
Before we start implementing the integration of JWT with Activiti, we will first take a
look at the topic of business process management [Wfm99, Hol94, Wak02]. We should,
as far as possible, use the terminology developed by the Workflow Management
Coalition (WfMC). This is an organization dedicated to developing standard termino-
logy and standard interfaces for workflow management systems components.
Once we have a good sense of this broad world, we will look at the BPMN 2.0
specification and see why it is such an important industry standard. Now let us take a
look at figure 2.1 to understand how different terms hang together because they will be
used throughout this thesis.
Figure 2.1: Relationships between basic terminology [Wfm99]
7

In figure 2.1, you can see two branches of interrelated terms. The left one represents a
branch of terms which are important to know while defining business processes. In
contrast, the right branch contains terms which deal with the execution of business
processes. For each of this terms we present a concise definition according to the WfMC
which formulated the main terms and concepts of the business process management
approach [Wfm99].
Definition (Business Process). A set of one or more linked procedures or
activities which collectively realize a business objective or policy goal, normally within
the context of an organisational structure defining functional roles and relationships.
Definition (Workflow). The automation of a business process, in whole or part,
during which documents, information or tasks are passed from one participant to
another for action, according to a set of procedural rules.
Definition (Workflow Engine). The workflow engine takes care of the actual
management of the workflow. Amongst other things, it is concerned with task-
assignment generation, resource allocation, activity performance, case preparation
and modification, the launching of application, and the recording of logistical
information.
Definition (Workflow Management System). A system that defines, creates and
manages the execution of workflows through the use of software, running on one or
more workflow engines, which is able to interpret the process definition, interact with
workflow participants and, where required, invoke the use of IT tools and
applications.
Definition (Process Definition). The representation of a business process in a
form which supports automated manipulation, such as modeling, or enactment by a
workflow management system. The process definition consists of a network of
activities and their relationships, criteria to indicate the start and termination of the
process, and information about individual activities, such as participants, associated
IT applications and data, etc.
Definition (Activity). A description of a piece of work that forms one logical step
within a process. An activity may be a manual activity which does not support
computer automation, or a workflow (automated) activity. A workflow activity
requires human and/or machine resources to support process execution; where
human resource is required and an activity is allocated to a workflow participant.
Definition (Automated Activity). An activitiy which is capable of computer
automation using a workflow management system to manage the activity during
execution of the business process of which it forms a part.
Definition (Manual Activity). An activity within a business process which is not
capable of automation and hence lies outside the scope of a workflow management
system. Such activities may be included within a process definition, for example, to
support modeling of the process but do not form part of a resulting workflow.
Definition (Process Instance). The representation of single enactment of a
8

process including its associated data. Each instance represents a separate thread of
execution1
of the process which may be controlled independently and will have its own
internal state and externally visible identity which may be used as a handle, for
example, to record or retrieve audit data relating to the individual enactment.
Thus, these definitions give us insight into aspects which will be discussed throughout
this thesis from a practical point of view. It is possible to implement a concrete
prototype concerning the ideas of the integration of JWT and Activiti because of their
maturity among business process management tools.
2.2 Taking a closer look at the workflow reference model
In section 2.1, we described the most important terms which we are going to use
throughout this thesis. Among the definitions presented in the previous section, we
explained the behaviour of the Activity object type. As processes consist of logical
steps represented by the Activity object type, it is important to understand how does
the Activity object type relates to other object types. In figure 2.2, you can see a
number of interrelated object types. For each of these object types we are going to
provide a short definition according to the WfMC specification.
Figure 2.2: Basic process definition meta model [Hol94]
As you can see, WfMC introduced a basic meta model for process definitions by
identifying core object types which are appropriate for the interchange of process
definitions. Now let us have a look at definitions mentioned in the introduction of this
section.
1 Where a process includes parallel activities, a process instance may include multiple
concurrent threads of execution
9

Definition (Workflow Participant – Role). A resource which performs the work
represented by a workflow activity instance. This work is normally manifested as one
or more work items assigned to the workflow participant via the worklist. A workflow
participant is normally identified by reference within the process definition to a role or
organizational entity which can then be filled by one or more of the resources available
to the workflow system to operate in that role during process enactment.
Definition (Transition Condition). A logical expression which may be evaluated
by a workflow engine to decide the sequence of activity execution within a process.
Transition conditions identify the flow relationship between activities and are used to
effect the desired sequence of activity execution which may include parallel or
sequential execution conditions.
Definition (Invoked Application). An invoked application is a workflow
application which is invoked by the workflow management system to automate an
activity, fully or in part, or to support a workflow participant in processing a work
item.
Definition (Workflow Relevant Data). Data which is used by a workflow
management system to determine the state transitions of a workflow instance, for
example within pre- and post-conditions, transition conditions or workflow
participant assignment.
These core object types form the basis of process definitions for such
specifications/technologies like BPMN 2.0, Activiti and Java Workflow Tooling. The
concrete details of how these core object types are implemented, we will discuss in the
following sections of this chapter.
2.3 Understanding workflow components
As mentioned in section 2.1, in order to define and to execute business processes, we
need to proceed in two different ways. According to figure 2.1, we have to take into
account two aspects – how a process definition can be defined and how a process
definition can be executed. In figure 2.3, you can see the dividing line between the
runtime and the build time of a process definition. The dividing line emphasizes that
the process definition obtained during the build time is shared with the Workflow
Enactment Service during the runtime. The Workflow Enactment Service is defined as
follows.
Definition (Workflow Enactment Service). The workflow enactment service
provides the runtime environment in which process instantiation and activation
occurs, utilising one or more workflow management engines, responsible for
interpreting and activating part, or all, of the process definition and interacting with
the external resources necessary to process the various activities.
From this point of view two different types of components are used in order to model
and to run business processes. There are clear benefits in using this kind of approach.
Firstly, it defines a point of separation between the build time and runtime
environments enabling a process definition generated by one modeling tool to be used
as input to a number of different workflow runtime products. Secondly, it offers the
potential to export a process definition to several different workflow products which
10

could co-operate to provide a distributed runtime enactment service.
Figure 2.3: Different phases during build and run time [Wfm99]
Figure 2.4 illustrates from another point of view what kind of components interact with
the Workflow Enactment Service.
Figure 2.4: The workflow reference model [Wfm99]
The interaction of the Workflow Enactment Service with external resources occurs via
the Invoked Applications interface and the Workflow Client Applications
11

interface. The Invoked Applications interface which enables the workflow engine to
directly activate a specific tool to undertake a particular activity. This would typically be
a server-based application with no user interface. For this purpose a particular activity
uses a tool which requires end-user interaction. It will normally be invoked via the work
list interface to provide more flexibility for user task scheduling.
The Workflow Client Applications interface represents an interface through which
a workflow engine interacts with a work list handler responsible for organizing work on
behalf of a user resource. It is the responsibility of the work list handler to select and
progress individual work items from the work list.
12

3 Business Process Modeling and Notation –
Introducing high-level modeling with BPMN 2.0
3.1 Getting to know BPMN 2.0
When the Business Process Management Initiative (BPMI) published BPMN in 2004
(see figure 3.1), the abbreviation stood for “Business Process Modeling Notation“. The
goal was to create a process notation with standard graphics which also could be used
for process automation. In 2005, the Object Management Group (OMG) took over the
development of BPMN. In 2011, the OMG approved version 2.0. Now, BPMN means
“Business Process Model and Notation” and has its own meta model [Fre12, Rad12].
Figure 3.1: The timeline of the BPMN 2.0 standard [Rad12]
Before version 2.0, it was not possible to execute BPMN process definitions directly in
process engines because version 1.2 had not defined all the technical aspects required
to execute BPMN process definitions. But the introduction of BPMN 2.0 enabled direct
execution of BPMN process models in process engines. This was the first important
criterion in favor of its use. The second important criterion was the standardization of
BPMN which yields the following benefits:
(1) You become less dependent on certain business process management tools
because you do not need to learn a new notation every time you change tools.
(2) The likelihood increases that your customers, suppliers, consultants and etc.
have a grasp of BPMN and will therefore understand your process definitions
13

more readily.
(3) When you hire new staff members, the odds are higher that they have
already heard about BPMN and can create such process definitions.
BPMN was developed to model processes as logical and chronological sequences of
events. You often hear BPMN being criticized for not representing organizational
structures, strategies, business rules and it landscapes. On the one hand, it is important
to incorporate these topics into process documentation, on the other hand, it relieves
BPMN from further complex constructs and keeps it from being a monstrosity that
nobody would want to compile, develop, or even understand.
But even without these constructs, the BPMN 2.0 specification represents a substantial
specification (550 pages) including over 100 BPMN 2.0 constructs. It can be very
difficult to get started with BPMN 2.0 and try to comprehend the basics of the
specification. Therefore, it is important to start by structuring the BPMN 2.0 into
different groups of modeling detail (see figure 3.2).
Figure 3.2: A categorization of BPMN 2.0 constructs by the WfMC [Rad12]
With these different levels in mind (see figure 3.2), it is easier to start with BPMN by
using, for example, the first level group of BPMN constructs. A more concrete
description of level groups is presented below.
Level 1 – is described as descriptive BPMN which can be used for
high-level modeling with a restricted palette of BPMN constructs.
14

Level 2 – can be used for detailed modeling, including event and
exception handling, and is described as analytical BPMN. It uses a
wide range of BPMN constructs.
Level 3 – is the execution model of BPMN (which is new in BPMN
2.0) which can be deployed on a process engine.
3.2 Walking around the business process management life
cycle
In order to be able to implement business processes, it is important to understand that
a number of steps have to be performed to obtain high-quality business processes.
Creating fully functional business processes involves five steps, often referred to
collectively as the business process management life cycle [Rad12, Wes07] shown in
figure 3.3.
Figure 3.3: The five steps of the BPM life cycle [Rad12]
Each of these five steps represents an important development phase in implementing a
successful process solution. That's why we will take a closer look at these aspects in part
3 and 4 of this thesis by explaining what kind of approaches we applied to provide
support for the business process management life cycle. According to these five steps
we will describe how JWT process definition can become executable by means of the
Activiti Engine. These five steps are explained as follows:
Design – The first step consists of activities that define the business process:
identifying high-level activities, discussing possible organizational changes,
defining service level agreements, and specifying process details such as
actors, notifications, and escalations.
Modeling – In this step, the business process is fully specified and validated.
The process flow is formalized, for example, by using BPMN; additionally,
process variables are defined and candidate services which can be used to
execute an activity, are identified. To validate the business process, “what-if”
scenarios are performed with process simulation.
15

Execution – The modeled business process is implemented in a business
process application, often using a business process management system. You
still need to add technical details to the business process before you can
execute it. The process is implemented with a process language like BPMN
2.0.
Monitoring – The processes are monitored for business goals that are
defined by key performance indicators (KPIs). Examples of KPIs are “the
average number of orders received in a day should be at least 30” and “the
time to send a proposal to a customer based on a web inquiry should not
exceed eight hours”.
Optimization – Based on new insights, changing business requirements,
and monitoring results, the implemented business processes will need to be
optimized. When the optimization phase is done, the business process goes
into the design phase again and the cycle is completed.
3.3 Understanding the BPMN 2.0 meta model
As the OMG document [Omg11] describing the BPMN 2.0 specification comprises 550
pages, it contains many details about the BPMN 2.0 meta model. This meta model
represents an approach of how BPMN 2.0 model elements with their dependencies
should be used and implemented. For example, Activiti (see chapter 5) applies the same
meta model as described in the BPMN 2.0 standard. That's why while using Activiti, we
can rely on the knowledge presented in this specification.
In figure 3.4, you can see the class diagram of the BPMN 2.0 meta model. We
illustrated the main aspects of the meta model which will be important for us during
this master's thesis. We left out many classes and associations between them, and
focused only on the inheritance hierarchy of the core model elements because the
explanation of the entire meta model would go beyond the scope of this thesis.
As mentioned in section 3.1, the minimal set of elements of the first level (see figure
3.2) are elements of three categories – activities, gateways and events. Activities are
represented in figure 3.4 by the Activity abstract class which is the base class for
tasks – for the ServiceTask and UserTask. The second category are gateways. Two
important gateways are the ParallelGateway and the ExclusiveGateway. The
definitions of these elements are presented in appendix A. The third category are
events. The BPMN 2.0 specification defines many different events but we will focus
only on the StartEvent and the EndEvent. The SequenceFlow element cannot be
assigned to one of these three categories because it connects other elements with each
other. Therefore, the SequenceFlow element can be considered as a standalone
element which does not belong to any of these three categories. The Process and
SubProcess elements represent element containers for other model elements, among
other things, model elements of the categories mentioned above.
It is also important to emphasize that the BPMN 2.0 meta model with its basic concepts
was implemented in scope of Activiti by introducing Activiti extensions for the
constructs which were necessary to execute process definitions, and which has not been
defined in the BPMN 2.0 specification, for example, execution and task listeners. But
we will go into greater detail of this topic in section 5.5.
16

Figure 3.4: The BPMN 2.0 meta model [Omg11]
17
Part2–Introducingworkflowconcepts,terminologyandrelations

4 Java Workflow Tooling – Introducing the service-
oriented JWT tool stack
4.1 Getting to know Java Workflow Tooling
Java Workflow Tooling (JWT) is an Eclipse Technology project and its goal is to
provide a set of tools which will help to develop, deploy and test workflows [Jwt14]. The
development of Java Workflow Tooling started in 2007 (see figure 4.1) when small and
medium-sized enterprises realized that business processes in the context of ERP can
improve their productivity and provide a new level of innovative working methods
within their organizations. As most companies use simultaneously several applications,
it is important to have the possibility to integrate them in a way that relevant data can
be exchanged among them. As process integration is not an aspect which can easily be
implemented, Java Workflow Tooling aims to provide a new concept by introducing an
adaptable framework for different graphical representations and XML notations, as
well as different workflow engines.
Figure 4.1: The timeline of Java Workflow Tooling
The JWT project aims to provide build-time and runtime generic tools for workflow
engines and to introduce generic APIs for defining and administrating business
processes. Java Workflow Tooling comprises several important components which are
important to achieve the mentioned objective.
Workflow Editor – The Workflow Editor is a visual tool for
creating, managing and reviewing process definitions.
18

Workflow Administration and Monitoring – This compo-
nent is used for deploying and testing workflows in a workflow
engine i.e. handle an engine's process definition repository by
loading/unloading/updating/instantiating/monitoring process
definitions and performing mappings among participant defini-
tions and real users and among application and tool agents.
Runtime Tools – This component provides the user with all
kinds of tools to adapt a workflow at runtime.
4.2 Dealing with the Java Workflow Tooling meta model
As mentioned in previous sections, it is important to understand how elements of a
process definition relate to each other. For the JWT process definition a number of
interesting concepts were introduced to provide a notation (see appendix B) which
shows similarities with BPMN 2.0 core constructs and with UML Activity Diagram
elements [Bar07, Lau07]. The meta model of JWT is designed in a way that each
element in JWT is an element of type ModelElement. The ModelElement class (see
figure 4.2) is the basic unit and represents the most abstract element of the meta
model. A special kind of a model element is an element of type NamedElement. All
elements which have a name and an icon are at least elements of type NamedElement.
Figure 4.2: The Java Workflow Tooling meta model – Roles and Applications
The ReferenceableElement class represents an element which can be referenced by
other elements. To include elements into an activity which are normally outside the
scope and are defined for more than one process model, the reference approach can be
19

used to point to an existing element of type ReferenceableElement. These references
can be connected through edges of type ReferenceEdge (see figure 4.3) .
Figure 4.3: The Java Workflow Tooling meta model – References
An example for a referenceable element would be a Role element or an Application
element (see figure 4.2) .
To model the flow of executable elements, let us take a look at figure 4.4. To model the
start or finish of a process, the InitialNode and FinalNode elements can be used. To
model parallel process flows and the synchronization afterwards the ForkNode and
JoinNode elements can be applied. For exclusive choices and merges afterwards the
DecisionNode and the MergeNode elements can be used.
Figure 4.4: The Java Workflow Tooling meta model – Control nodes
It is also important to understand how these elements fit into the entire JWT meta
model. All processes modeled with JWT are activities which are subclasses of the Scope
class which in turn includes all elements in a graphical model (see figure 4.5). Examples
for such elements are elements of type ActivityNode and ActivityEdge. One
example for an element of type ActivityNode is an Action element which is
executable (subclass of ExecutableNode) and has therefore a name and an icon
20

(subclass of NamedElement). The StructuredActivityNode class represents an
executable element and simultaneously has its own scope with elements of type
ActivityNode and edges of type ActivityEdge which connect two elements and can
be constrained with a Guard object.
Figure 4.5: The Java Workflow Tooling meta model – Processes
4.3 Understanding the implementation approach of the
meta model
The meta model of Java Workflow Tooling is based on the Eclipse Modeling
Framework (EMF) which provides tools and runtime support to produce a set of Java
classes for the model and a set of adapter classes which enable viewing and command-
based editing of the model [Sbp09]. This means that the implementation of the specific
logic can be generated, and therefore manual coding can be avoided.
It is also important to emphasize that the JWT meta model is built according to the
Meta-Object Facility (MOF) standard which defines four layers:
M0 – This layer is used to describe real world objects.
M1 – This layer is used to create user-defined models. This would be, for
example, models written in UML.
M2 – This layer is used to define how models are build and structured.
The most prominent example is the UML meta model, the model which
describes UML itself. Also JWT is such a meta model.
21

M3 – This layer represents meta meta models which are used to build
meta models. The construction of a meta meta model is implemented by
means of the M3 layer itself. The example is the Ecore meta meta model
of EMF.
In figure 4.6, you can see how in the basic editor of EMF the Java Workflow Tooling
meta model can be defined and edited.
Figure 4.6: The Java Workflow Tooling meta model in the EMF editor
22

5 Activiti – Introducing executable business processes
in BPMN 2.0
5.1 Getting to know Activiti
The Activiti project was started in 2010 by Tom Baeyens and Joram Barrez, the former
founder and the core developer of jBPM (JBoss BPM). The goal of the Activiti project is
to build a super-fast and a rock-solid open source BPMN 2.0 process engine [Act14,
Rad12]. It is funded by Alfresco2
but it acts as an independent open source project.
Alfresco uses the Activiti process engine to support features such as a review and
approval process for documents which means that the document has to be approved by
one or a group of users. For this kind of functionality, Activiti is integrated into the
Alfresco system to provide the necessary process and workflow engine capabilities.
Figure 5.1: The timeline of Activiti
As Activiti is a BPMN 2.0 process engine framework, it aims to provide an approach for
implementing business processes in isolation and to be applicable as a component in
everyday software development. This vision will help to avoid that executable business
processes can become indispensible and monolithic part of a larger application. It is
also important to emphasize that Activiti called its first stable and production-ready
release 5.0. The version 5.0 indicates that Activiti is not building experimental stuff but
continues to build on the experience of its founders which they gained developing the
jBPM versions 1 to 4 (see figure 5.1). They use that knowledge as a base line and work
2 Alfresco is known for its open source document management system of the same name.
23

with the community to build the next generation BPM solution.
The Activiti project contains a number of components, among other things, the process
engine which provides the core capabilities to execute BPMN 2.0 processes. Figure 5.2
illustrates an overview of the full Activiti tool stack.
Figure 5.2: An overview of the Activiti tool stack [Rad12]
The different components are summarized as follows.
Activiti Engine – The core component of the Activiti tool stack that
performs the process engine functions, such as executing BPMN 2.0
business processes and creating workflow tasks.
Activiti Modeler – A web-based modeling environment for creating
BPMN 2.0 – compliant business process diagrams.
Activiti Designer – An Eclipse plugin that can be used to design
BPMN 2.0 – compliant business processes with the addition of Activiti
extensions, such as a Java service task and execution listeners. You can
also define unit test processes, import BPMN 2.0 processes, and create
deployment artifacts.
Activiti Explorer – A web application which can be used for a wide
range of functions in conjunction with the Activiti Engine. You can, for
example, start new process instances and get a list of tasks assigned to
you. In addition, you can perform simple process management tasks,
like deploying new processes and retrieving the process instance
status.
24

Activiti REST – A web application which provides a REST interface
on top of the Activiti Engine. In the default installation, the Activiti
REST application is the entry point to the Activiti Engine.
5.2 Getting familiar with the Activiti Engine component
Activiti is a BPMN 2.0 process engine framework which implements the BPMN 2.0
specification. It is able to deploy process definitions, start new process instances,
execute user tasks and perform other BPMN 2.0 functions.
The core of the Activiti Engine is the Activiti engine component which consists of two
layers as shown in figure 5.3. The first layer is the engine itself which provides the
engine interfaces and implements the BPMN 2.0 specification. The engine component
also includes a process virtual machine abstraction which translates the BPMN 2.0
engine logic into a state machine model (see figure 5.4). This process virtual machine,
therefore, is capable of supporting other process languages and provides the
foundational layer of the Activiti Engine.
Figure 5.3: An overview of the different layers of the Activiti Engine [Rad12]
The core of the process virtual machine is the state machine model. A BPMN 2.0
process definition consists of elements like events, tasks and gateways which are wired
together via sequence flows. When such a process definition is deployed on the process
engine and a new process instance is started, the BPMN 2.0 elements are executed one
by one. This process execution is similar to a state machine where there is an active
state and, based on conditions, the state execution progresses to another state via
transitions.
In the Activiti engine most BPMN 2.0 elements are implemented as a state (see figure
5.4). They are connected with leaving and arriving transitions. Every state or
corresponding BPMN 2.0 element can have a piece of logic which will be executed
when the process instance enters the state.
As mentioned above, the Activiti Engine is the entry point to deploying new process
definitions, starting new process instances, querying for user tasks, and so on. But it is
also responsible for the options of how the Activiti Engine can be run during the
development of business processes.
25

Figure 5.4: An abstract overview of a state machine and how it is implemented in the
Activiti Engine [Rad12]
A good way to test a BPMN 2.0 process is to run the Activiti Engine inside the Java
Virtual Machine (JVM) with in-memory database (see figure 5.5). In this deployment
scenario, the unit tests can also be run within a continuous build environment without
the need for external server components.
Figure 5.5: The deployment scenario where the Activiti Engine runs within the JVM
with an in-memory database [Rad12]
But there are also other options for running the Activiti Engine in a development
environment. The deployment alternative can be when the Activiti Engine runs within
the same JVM as the unit test and connects to a standalone database. It is also possible
to run unit tests when the Activiti Engine runs on an application server, such as Apache
Tomcat, with a standalone database by using the Activiti REST API (see figure 5.6).
26

Figure 5.6: A typical Activiti Engine environment where the process engine runs on an
application server with a standalone database [Rad12]
5.3 Understanding execution and task listeners
When the process engine executes a process, several things happen in the background.
Automatic activities are executed, transitions are performed and user tasks are created
and assigned to the configured users and groups. When you want to get more
information out of the process execution, Activiti provides an extension on top of the
BPMN 2.0 specification, referred to as execution and task listeners (see table 5.1).
BPMN 2.0 construct Event types Description
Process start, end A start and end event of a process instance
can be captured with a process execution
listener.
Activity start, end A start and end execution listener of an
activity can be implemented.
Transition take A transition execution listener can catch a
take transition event.
User task create,
assignment,
complete
A user task throws events when it is created,
when the task assignment has been
performed, and when the user task has been
completed.
Table 5.1: An overview of the event types that can be configured using the Activiti
execution and task listeners extension
Activiti supports two types of listeners, the ExecutionListener and the Task-
Listener. The ExecutionListener can be used to implement a listener for the
process, activity, and transition event types. The TaskListener is solely dedicated to
the listener implementation of a user task. These listeners provide great hooks into the
process execution, and they can be used for things like business process monitoring.
27

5.4 Deploying processes to the Activiti Engine
In previous sections, we described how the Activiti Engine comes into play when BPMN
2.0 elements within a process definition should be executed. But before a process can
be started, its process definition should become available to the Activiti Engine. That's
why another step is required during which the specific process definition will be
deployed on the Activiti Engine and serve as a basis for starting new process instances.
For this purpose Activiti introduced two types of deployment archives which can be
accepted/consumed by the Activiti Engine/Activiti Explorer. Let us take a look at these
definitions.
Definition (Activiti BAR file). A business archive (.bar file) is the unit of
deployment on the Activiti Engine. It is equivalent to a standard Java .jar file and is
therefore a zip file. It should contain only BPMN 2.0 processes because Java classes
which are added in the .bar file will not be added to the classpath. When a .bar file is
deployed, it is scanned for files with a bpmn20.xml extension. Each file that has this
extension will be parsed and can contain multiple process definitions.
In general, there are three options for deploying a business archive. You can use Java,
Ant, or Activiti Explorer. In part 4 we will describe more precisely how Activiti process
definitions obtained from JWT process definitions can be deployed with the Activiti
Explorer by uploading business archives. Another important archive is the Activiti Java
archive which can be defined as follows.
Definition (Activiti JAR file). A Java archive (.jar file) is the unit of deployment
on Activiti Engine and contains all the classes the process needs at runtime, such as
the Java service tasks or implementations of event listeners, should be present on the
Activiti Engine classpath for the processes in the business archive to run.
To include Activiti Java archives to run processes with the Activiti Explorer, you have to
copy that archive to the webapps/activiti-explorer/WEB-INF/lib directory of the
Tomcat distribution.
28

6 Esper – Introducing complex event processing (CEP)
6.1 Understanding business activity monitoring
When many different business processes are running in an organization, it is very
interesting for each organization to get real-time insight into all of their running
processes and thus get a better understanding of what kind of effective and swift
decision-making procedures can be defined.
To provide this real-time information about what is happening in an organization,
business activity monitoring (BAM) can be applied [Rad12, Rsa13]. This section will
cover what business monitoring is and what aspects come into play in order to
implement it. Now let us take a look at the definition of business activity monitoring.
Definition (BAM). Business activity monitoring (BAM) is a discipline that focuses
on real-time monitoring, and therefore it is all about knowing what is going on in an
organization at any given moment of time.
But business activity monitoring is often used in the same context as business
intelligence. Although both have the shared goal of providing an organization with vital
information concerning the business state, there are differences between the two
aspects. The next definition will clarify these differences.
Definition (BI). Business intelligence (BI) is a discipline that focuses mainly on
historic data to perform its analysis. Information is gathered from different systems
and stored in data warehouses, where it can be analyzed and processed to produce
reports and possibly forecasts.
Although business activity monitoring and business intelligence serve similar goals of
improving business in the future, BI focuses mainly on the past to achieve those goals,
whereas BAM focuses on the present.
Figure 6.1: A typical business monitoring solution [Rad12]
In figure 6.1, you can see the three main steps which are important to implement a
BAM solution:
29

(1) Gather events – This involves inputting data by receiving events
from as many sources as needed. Events are typically sent from other
applications and contain short messages of information, such as,
“customer A bought 5 items of product B for $100”.
(2) Analyze the gathered data – An example of analysis in this step
is filtering. When a certain product has recently been heavily
advertised, a company might be interested in how many people are in
the process of buying it. In this case, filtering takes place on the
shopping baskets to retrieve only the information that is needed for a
specific measurement.
(3) Report the result of the analysis – After the information has
been analyzed, the results need to be communicated. Dashboards, like
the one illustrated in figure 6.1, can help to quickly display trends and
spot exceptional situations. When values reach certain limits, actions
can be taken, such as sending an email.
6.2 Understanding complex event processing
CEP is the technology that performs filtering, correlation, aggregation and computing
on volumes of real-time event data [Eni11, Rad12]. For example, a manufacturing plant
management system diagnoses mechanical failures based on observable symptoms. In
this case the basic events are symptoms describing things that do not work properly,
and the main purpose of the event processing is to find the root cause of these
symptoms. This means that from basic events, an event processing system may infer a
complex event.
Many complex event processing applications keep the logic that processes the events
separate from the event producers and event consumers, as shown in figure 6.2.
Figure 6.2: The structure of an event processing application [Eni11]
A CEP engine looks like an inverted database. Whereas you first store data in a
database and then start quering, a CEP system lets you define the queries first and then
starts running data through those queries.
The events which enter the CEP engine are processed immediately. There is no
database underneath this mechanism. Only the concept of event windows exists which
30

can be defined as follows.
Definition (Event window). An event window defines how many events the CEP
engine is going to remember when performing its pattern matching.
There are two different types of windows:
Length windows – A length window instructs the CEP engine to
keep the last N events. When the length window is full and a new event
arrives, the oldest events are published out of the window.
Time windows – A time window instructs the CEP engine to keep
events for the specified amount of time. If the age of an event exceeds
the time interval, it is pushed out of the window.
In figure 6.3, you can see a stream of different event types entering the CEP engine. The
engine performs different types of operations on the events, like filtering, aggregating
similar events, and joining different types of events together. While these operations
are performed on the events, a pattern matching mechanism runs on the results to
search for combinations of data the engine needs to put out. Finally, the output is sent
to possible listeners to act upon.
Figure 6.3: Basic overview of a CEP engine in action [Rad12]
In figure 6.3, you can also see a timeline which emphasizes that there is some sort of
life of the event in the engine during which processing takes place.
6.3 Working with the event processing language
The event processing language (EPL) follows an SQL-like syntax and allows a CEP
engine to store queries as EPL queries which will run through the data [Esp14]. It has
all important SQL constructs: select, from, where, group by, having and order by.
The select clause in an EPL query specifies the event or the event properties to
retrieve. The from clause refers to the event type, and where, just like in SQL, specifies
31

filter conditions in the statement.
select specific_attribute as specific_name from
specific_event where user_name = 'John'
Besides filtering using the where clause, EPL supports the concept of windows. With
this concept, you are looking at a stream of events. Suppose you are looking for
specific events which were sent in the last 30 seconds. The EPL would look like this:
select * from specific_event.win:time(30 seconds)
EPL support some standard functions as well, such as sum, avg, min and max:
select sum(specific_attribute) from
specific_event.win:time(30 seconds)
With the sum function, the sum of all specific events over the last 30 seconds is
returned. The last feature is the joining of different event types:
select * from specific_event1.win:time(30 seconds) as se1,
specific_event2.win:time(30 seconds) as se2 where se1.id = se2.id
Two different event types occuring in a window of 30 seconds are joined by their ids.
We will use EPL queries to implement the logic of business activity monitoring for
Activiti processes obtained from corresponding JWT business processes.
6.4 Taking a closer look at the Esper CEP Engine
Esper is an open source complex event processing implementation, and uses the event
processing language to perform operations on events by filtering out certain events,
changing an event instance from one form to another, and examining a collection of
events to find a particular pattern [Esp14]. The reason why we decided to use the Esper
CEP Engine is that it is an open source project (see table 6.1) and works with any Java
process. It is a lightweight framework in comparison to the OpenESB platform which
comprises a wide range of enterprise service bus technologies which are not crucial for
our task.
Language or product name Vendor or open source
Aleri SAP
Esper Open source
IEP – Open ESB Open source
Oracle CEP Oracle
SPADE IBM
StreamInsight Microsoft
StreamSQL EventFlow TIBCO
Table 6.1: Event processing technologies [Eni11]
32

The Esper Engine can be described (see figure 6.4) as a set of aspects which are
necessary to perform complex event processing. EPServiceProvider acts as a real
engine which provides core functionality such as filtering, aggregating, and joining
events. Another important aspect is the support of EPL statements which can be
defined by the user and afterwards interpreted by the engine.
Figure 6.4: Overview of the Esper Engine [Jte09]
But also the support for defining new events is crucial for performing customized
complex event processing. We will talk about all these aspects in part 4 with the
objective to develop an approach which will enable us to apply business activity
monitoring to Activiti processes obtained from JWT process definitions.
33

Part 3 – Integrating Java Workflow Tooling with the Activiti process engine
Part 3 – Integrating Java Workflow Tooling with
the Activiti process engine
7 Introducing a real business process
7.1 Analyzing the loan request process
In this section, we will introduce the loan request process which we are going to use as
a sample process for explaining how JWT process definitions can be integrated with the
Activiti Engine. That's why it is important to start by exploring the loan request from a
business perspective. In figure 7.1, you can see the loan request process defintion which
uses the BPMN 2.0 modeling notation with explanations what kind of documents have
to be generated while performing loan request process steps.
Figure 7.1: An overview of the loan request process
For an organization which wants to handle loan requests from its newly created
website, it is important to use a business process responsible for this kind of work flow.
The process contains automated steps for checking the credit amount in relation to the
income of the potential customer. Not all steps in the process will need to be automated
because the management believes that each loan request should be evaluated by the
management group when certain conditions cannot be satisfied.
A loan request process starts when the organization receives a request for a loan. This
information is accompanied by some basic information, like the customer's name,
34

email address, current income, and the amount of money the customer wants to
borrow. Before the loan request is evaluated, a credit check is performed. The credit
check ensures that the requested loan amount is not higher than half of the income of
the applicant. The result of the credit check is stored as additional process information
which indicates whether the management group should evaluate the loan request or
not.
7.2 Using decision tables in the loan request process
In section 7.1, we explained the main ideas of the loan request process and how it will
be modeled to provide the necessary work flow while working on loan requests. But the
logic of the credit check should be defined anywhere in the process definition. As a
typical business process in a financial organization involves retrieving, creating, or
storing a document, we are going to use an Excel document to store formulas used in
the credit check (see table 7.1).
A B C
1 Customer name
2 Email address
3
4 Income Loan amount Loan amount * 2
5 0 0 0
6
7 Credit check = A5 > C5
8
Table 7.1: The credit check Excel template showing the formula for the credit check
calculation
This Excel document will serve as an Excel template for generating a new Excel sheet
which will contain the loan request details and the outcome of the credit check for that
specific loan request (see table 7.2).
A B C
1 Customer name Paul Smith
2 Email address paul.smith@gmail.com
3
4 Income Loan amount Loan amount * 2
5 5000 8000 16000
6
7 Credit check False
8
Table 7.2: The result of the loan request evaluation
The second step is the evaluation of the specific loan request. The loan request
35

evaluation task differs a bit because it only reads an Excel document containing a
decision table (see table 7.3). The task looks up the evaluation outcome in the decision
table and adds the credit check value to the executing loan request process. This value
will be used to decide whether the loan request should be evaluated by the management
group or not.
A B C
1 Credit check Loan amount Status
2 True < 4000 Approved
3 True >= 4000 Needs manager approval
4 False N/A Denied
5
Table 7.3: The Excel decision table to be used in the loan request evaluation
According to table 7.2, the credit check detected that the requested loan amount is
higher than half of the income of the applicant. That's why the decision table 7.3
provides that the loan request will be denied and this automatic decision will not even
require the opinion of a member of the management group.
36

8 Specifying integration requirements between Java
Workflow Tooling and the Activiti process engine
8.1 Understanding integration challenges between JWT
and Activiti
In section 2.1, we illustrated the main connections between modeling and execution
aspects of business processes which can be handled by standard business process
management systems. As Activiti aims to provide a framework which should function
as a component in everyday software development, we have very good prerequisites to
succeed in integrating Java Workflow Tooling with Activiti and provide an important
feature for JWT, namely making JWT business processes executable.
In figure 8.1, we presented interrelations between Java Workflow Tooling and Activiti
by modifying figure 2.1.
Figure 8.1: Relationships between Java Workflow Tooling and Activiti
Thus, you can see that the left branch contains JWT terms, whereas the right branch
only Activiti concepts. This means that according to our integration approach the
lifecycle of a business process can be considered as a composition of two technologies
which are based on principles explained in section 2.1. This fact will make it easier to
realize our visions that Java Workflow Tooling business processes can become
executable without implementing a new workflow engine.
37

8.2 Dealing with conceptional differences between JWT
and Activiti
The main difference between JWT constructs and Activiti elements is how activities
(see Activity definition described in section 2.1) can be modeled. As we distinguish
between automated activities and manual activities, two different constructs should be
provided.
In section 4.2, we described the concept of referenceable elements implemented in the
JWT meta model which enable to specify whether an Action element should be
considered as an automated activity or as a manual activity. From this point of view, we
can now take a look at table 8.1 which illustrates how automated and manual activities
of JWT correspond to BPMN 2.0 activities.
Table 8.1: Main differences between core constructs of JWT and Activiti
This insight is very important to us because during the transformation phase of JWT
process definitions to Activiti process definitions, we should take into account the
concept of referenceable elements implemented in JWT and therefore develop a
mechanism to map a group of JWT elements to single BPMN 2.0 constructs. It is also
important to emphasize that Activiti (see appendix C) provides significantly more
modeling elements than JWT. As our goal is to implement an one-directional
transformation mechanism (integration of JWT with the Activiti Engine), it is therefore
only important to find for each JWT modeling approach the corresponding BPMN 2.0
construct, and perform the necessary transformation step. Thus, the sample process
illustrated in section 7.1 can be modeled as a JWT business process (the result is shown
in figures 8.3 (part 1 and part 2)) within the JWT Eclipse plugin, and after applying our
future transformation mechanism we will obtain a BPMN 2.0 process definition with
Activiti extensions as shown in figures 8.4 (part 1 and part 2).
38

Figure 8.3: An overview of the loan request process designed in the JWT Workflow Editor – Part 1
Figure 8.3: An overview of the loan request process designed in the JWT Workflow Editor – Part 2
39
Part3–IntegratingJavaWorkflowToolingwiththeActivitiprocessengine
39

Figure 8.4: An overview of the loan request process designed in the Activiti Designer – Part 1
Figure 8.4: An overview of the loan request process designed in the Activiti Designer – Part 2
40

8.3 Using the Activiti tool stack for extending JWT
business processes
In section 2.3, we described workflow components defined by the WfMC which are
crucial for running business processes in an organization. As we are going to integrate
Java Workflow Tooling with the Activiti process engine, it is important to understand
what kind of components should be put together to achieve the desired level of
integration between JWT and Activiti.
As JWT provides only one matured component, the JWT Workflow Editor, it is
interesting to get insight into how this component will be interrelated with Activiti
components. In figure 8.2, you can see the illustration of our approach.
Figure 8.2: Overview of integration components between JWT and Activiti
Thus, our goal is to implement a strong integration between the JWT Workflow Editor
and the Activiti Engine by means of providing the process definition xml format which
could be accepted and consumed by the Activiti Engine. As the Activiti Designer and
Activiti Explorer interact directly/indirectly with the Activiti Engine, there is no need to
change something on their behaviour. It is easier to transform the output produced by
the JWT Workflow Editor into the BPMN 2.0 format. For this purpose we are going to
introduce the JWT Extensions component which will contain the logic of obtaining the
BPMN 2.0 structure of JWT process definitions, and implementation approaches in
regard to monitoring aspects.
41

Part 4 – Implementing executable Java Workflow Tooling business processes
Part 4 – Implementing executable Java Workflow
Tooling business processes
The fourth part of the master's thesis gives a detailed insight into the architecture of
main components which are necessary to execute Java Workflow Tooling business
processes by means of the Activiti Engine. As mentioned in the previous part (part 3)
and in section 3.2, there is a number of steps which are crucial for an efficient and
accurate integration of Java Workflow Tooling with Activiti. These steps (see figure 8.5)
form the basis for our implementation and will be discussed in detail in the next
chapters.
Figure 8.5: An overview of implementation steps
As you can see in figure 8.5, we illustrated the main steps in a flowchart to emphasize
how the specific steps relate to each other and at the same time fit into the big picture
of our implementation tasks. The main ideas can be summarized as follows:
Step (1) – Integration (see chapter 9)
Implementing concepts for extending the JWT development
environment.
Step (2) – Transformation (see chapter 10)
Implementing a transformation mechanism for transforming JWT
models to Activiti models in the BPMN 2.0 notation.
Step (3) – Execution (see chapter 11)
42

Implementing a mechanism for generating service and user tasks.
Step (4) – Deployment (see chapter 9, chapter 12)
Implementing a packaging mechanism for bundling process defini-
tions and process-related execution/task listeners into a package which
in turn can be consumed by the Activiti Explorer.
Step (5) – Monitoring (see chapter 13)
Implementing a monitoring mechanism for getting real-time insight
into the status of business processes running in an organization.
Step (6) – Evaluation (see chapter 13, section 13.5)
Implementing an evaluation mechanism for merging the results of the
monitoring analysis with JWT process definitions. However, this topic
goes beyond the scope of this thesis.
9 Creating the JWT Extensions development
environment
In order to implement the steps explained above, we need a well-conceived approach of
how we want to integrate the JWT plugin with the Activiti process engine. This
approach should provide a basis (classes and mechanisms) for extending JWT process
definitions so that they can become executable by means of the Activiti process engine.
9.1 Introducing the JWT Extensions approach
In the introduction of this chapter, we described the main mechanisms which are
important for developing and running business processes in an organization. As our
goal is to extend the modeling capabilities of the JWT plugin and to provide the
opportunity to run JWT process definitions, we need to define an integration layer
between the JWT plugin and the Activiti Engine. For this purpose we introduce the
JWT Extensions tier (see figure 9.1) which comprises all the aspects dealing with the
execution of business processes.
43

Figure 9.1: An architectural overview of the JWT Extensions layer
The JWT Extensions layer consists of three Java projects (see figure 9.2) which contain
the specific functionality for making JWT process definitions executable.
Figure 9.2: The Java projects for the JWT Extensions layer
The tasks of each project can be described as follows:
jwt-transformation-activiti – comprises packages for transforming JWT
process definitions into BPMN 2.0 models with Activiti extensions (jwt.trans-
formation.activiti) as shown in figure 9.3. It also contains packages for
generating for each JWT process definition a separated Activiti project
(jwt.generation.activiti) with execution/task listeners and service task listeners
(jwt.execution.activiti). These listeners make use of additional libraries (jwt-
transformation-activiti-util, jwt-transformation-activiti-integ-
ration) which will be automatically integrated into Activiti projects during
their generation (jwt.integration.activiti).
Figure 9.3: The Java packages of the jwt-transformation-activiti project
jwt-transformation-activiti-util – comprises packages for serializing and
deserializing xml configuration formats. These formats are part of the JWT
Extensions layer and are used to configure the behaviour of monitoring and unit
44

testing approaches (see figure 9.4).
Figure 9.4: The Java packages of the jwt-transformation-activiti-util
project
jwt-transformation-activiti-integration – comprises packages for provi-
ding a framework for integrating execution/task listeners with the monitoring
infrastructure (see figure 9.5).
Figure 9.5: The Java packages of the jwt-transformation-activiti-
integration project
The concept which was implemented to include integration and util packages into
Activiti projects generated on the basis of JWT process definitions, represents a generic
approach. There is no need to generate manually a .jar file with the integration and
util packages and include it through the Eclipse environment as a class library into the
generated Activiti project because, on the one hand, it may be complicated and time-
consuming, on the other hand, any changes to the source code during the development
of the JWT Extensions layer will cause the repitition of the integration process and,
amongst other things, a manual generation of the specific .jar file.
Our solution is to consider the jwt-transformation-activiti-integration and
jwt-transformation-activiti-util projects as Eclipse plugins which in turn
enable us to access the source code and compiled Java bytecode by means of the Eclipse
infrastructure (org.eclipse.core.runtime). This implies that we can manage source and
bytecode files from our main project, the jwt-transformation-activiti project,
and generate the specific .jar file on-the-fly.
In Listing 9.1, we illustrated how we can get the source code and the bytecode location
of the integration and util plugins in order to replicate the folder structures in our .jar
file and subsequently copy plugin files to it.
//the bin folder path of the jwt-transformation-activiti-integration plugin
URL integrationBinBundleRoot = Platform.getBundle(
ActivitiIntegrationProjectOptions.integrationPluginName)
.getEntry("/"+ ActivitiIntegrationProjectOptions.binFolderPath +"/");
45

//the src folder path of the jwt-transformation-activiti-integration plugin
URL integrationSrcBundleRoot = Platform.getBundle(
ActivitiIntegrationProjectOptions.integrationPluginName)
.getEntry("/"+ ActivitiIntegrationProjectOptions.srcFolderPath +"/");
//the bin folder path of the jwt-transformation-activiti-util plugin
URL utilBinBundleRoot = Platform.getBundle(
ActivitiIntegrationProjectOptions.utilPluginName)
.getEntry("/"+ ActivitiIntegrationProjectOptions.binFolderPath +"/");
//the src folder path of the jwt-transformation-activiti-util plugin
URL utilSrcBundleRoot = Platform.getBundle(
ActivitiIntegrationProjectOptions.utilPluginName)
.getEntry("/"+ ActivitiIntegrationProjectOptions.srcFolderPath +"/");
Listing 9.1: Retrieving the source code and the bytecode location of the integration and
util plugins
9.2 Illustrating the JWT Extensions development process
In the previous section, we introduced three basic projects for realizing the JWT
Extensions layer and providing the necessary infrastructure for extending the JWT tool
stack. Whereas the aspects mentioned in the previous section were explained from an
architectural point of view, the aspects in this section will be illustrated from a user's
point of view describing how a developer can extend a JWT process definition and
implement a process execution model on its basis.
We use the example described in section 7.1, and illustrate how the development
process will look like, namely how the transition from the JWT project to the Activiti
project will be performed by means of the JWT Extensions layer.
By analyzing the flowchart in figure 9.8, we determine that the creation of the Activiti
project involves the subsequent creation of a number of JWT Extensions files which are
crucial for executing JWT process definitions. Our approach does not base on the
concept of creating the specific Activiti project by using the Activiti tool stack and
integrating JWT Extensions files into it but, on the contrary, we create a Java project
realizing the structure and behaviour of an Activiti project what enables us to integrate
the JWT Extensions layer into the pre-defined structure of the Activiti project more
easily and efficiently. As a result, we get the opportunity to keep generated Activiti
projects completely under our control. Figure 9.6 shows the JWT project with its
process definition file as a starting point of the transition between JWT and Activiti.
Figure 9.6: The JWT project showing the loan request process files
46

The result of applying the transition between JWT and Activiti is shown in figure 9.7.
As mentioned above, it is a Java project which comprises a number of files considered
as files belonging to the JWT Extensions layer.
Figure 9.7: The Activiti project showing the loan request process files
The most important aspects taken into consideration during the generation of the
Activiti project are:
• Creating execution/task listener classes in the monitoringListeners package.
It is part of the JWT Extensions layer.
• Creating service task listener classes in the serviceTaskListeners package. It
is part of the JWT Extensions layer.
• Integrating the jwt-transformation-activiti-integration.jar file as a
referenced library. It is part of the JWT Extensions layer.
• Creating configuration resources in the monitoring package. It is part of the
JWT Extensions layer.
As you can see, the diagrams package containing the bpmn file was not mentioned in
the list above because this part of the Activiti project represents the native structure
defined by Activiti, and therefore was not created within the scope of the JWT
Extensions layer. The mechanism of how the JWT .workflow file can be transformed
to an Activiti .bpmn file will be explained in the next chapter (see chapter 10).
Another pre-defined approach within the Activiti project is the dependency
47

management and the project build management. Their support is realized by means of
Apache Maven to retrieve the necessary Activiti libraries and dependencies from the
Activiti workspace directory. The pom.xml in the root of the Activiti project stores the
necessary Maven configuration.
Figure 9.8: The flowchart showing the relationship between the loanRequestProcess
and jwt-loanRequestProcess-activiti
9.3 Clarifying the implementation details of the JWT
Extensions development environment
In the previous two sections, we introduced the fundamental aspects of the JWT
Extensions layer and illustrated the development environment within the Eclipse IDE
from a developer's point of view as a demonstration of how JWT process definitions can
be extended by means of the Activiti infrastructure. Now it is time to take a look at the
core asset of the JWT Extensions layer from an architectural point of view and explain
how the main ideas have been implemented to provide the mentioned functionality.
As you can see in figure 9.9, we distinguish between two types of project classes:
ActivitiGenerationProject – represents the core functionality shown in
figure 9.9. It manages any dependencies like Java class files, xml files and .jar
files of the JWT Extensions layer which will be automatically included into any
48

Figure 9.9: The class diagram showing the relationship between ActivitiGenerationProject and ActivitiIntegrationProject
49
Part4–ImplementingexecutableJavaWorkflowToolingbusinessprocesses

generated Activiti project. All files managed by the ActivitiGeneration-
Project class can be compressed and bundled (via the IProjectDeployer
interface) into packages (see figure 9.12) which in turn will be accepted by the
Activiti Engine.
ActivitiIntegrationProject – represents the functionality to access Java class
files located in the jwt-transformation-activiti-integration project and
in the jwt-transformation-activiti-util project. It also implements the
IProjectDeployer interface which can be considered as a mechanism for
bundling Java class files from both projects.
In this context, it is also important to describe the approach of how we bundle Java
class files from different locations into a single .jar file. In figure 9.10, we presented a
class structure which is responsible for managing temporary folders of each project.
Figure 9.10: The class diagram showing the concept of temporary folders
They are important for performing copy operations on files which afterwards will be
included into a .jar file like jwt-transformation-activiti-integration.jar (see
figure 9.7).
50

Figure 9.11: The process of generating and integrating a .jar file into an
Activiti project
As you can see in figure 9.11, the process of generating and integrating a .jar file into
an Activti project goes through several phases. The main idea is to copy all folders and
files to a temporary folder – in our case to the tempClasses folder, and compress it as
a whole folder to a .jar file. Then the compressed .jar file will be automatically
copied to the libs folder of the generated Activiti project and integrated into it as a
referenced library. We can emphasize that the process described above is the most
important step to set up the Activiti development environment and to extend it in a way
that the JWT Extensions layer infrastructure can be accessed from there.
In figure 9.12, you can see a similar process – the deployment process – during which
two deployment packages (.bar file and .jar file) will be created so that they can be
consumed by the Activiti Engine.
Figure 9.12: The process of creating deployment packages
As shown in figure 9.7, the generated Activiti project comprises a number of files which
are created on-the-fly and included into the project. In order to generate project files
with a specific content (xml structure or Java source code) in the right way, we
introduced a mechanism for specifying different file templates which in turn can be
easily rendered and maintained.
In figure 9.13, we illustrated a class diagram of how we can access different file
templates and retrieve the corresponding contents. For this purpose we defined a file
template factory (ActivitiGenerationProjectFileTemplateFactory) and a file
51

template object (ActivitiGenerationProjectFileTemplate) which interact with
each other in a way that the file template factory assumes responsibility to create
concrete templates implementing the ICodeTemplate interface (see figure 9.14),
renders them, assigns the file path and file content to the file template object, and
afterwards returns it to the ActivitiGenerationProject.
Figure 9.13: The class diagram showing a list of defined file templates
As you can see in figure 9.13, we created templates for almost all types of files used in
the generated Activiti project shown in figure 9.7. An example of how we define a
template is illustrated in listing 9.2. In the template string we define only place holders
for specific parameters which will be included during the rendering process of the
specific template.
public class ActivitiGenerationProjectServiceTaskClassTemplate
implements ICodeTemplate {
public String getCode() {
return "package %s;n" +
"n" +
"import org.activiti.engine.delegate.DelegateExecution;n" +
"import org.activiti.engine.delegate.JavaDelegate;n" +
"n" +
"public class %s implements JavaDelegate {n" +
52

"t@Overriden" +
"tpublic void execute(DelegateExecution execution) throws
Exception {" +
"n" +
"t}n" +
"}n";
}
}
Listing 9.2: Implementing a file template to generate Java service task classes
A detailed illustration of how the template classes in figure 9.14 are involved in the
entire process of creating project files is shown in figure 9.15.
Figure 9.14: The class diagram showing template classes which derive from the
ICodeTemplate interface
The starting point of the sequence diagram in figure 9.15 is the JWT plugin which
listens to user interactions. When the user clicks the button “Generate Activiti Project”,
the process of generating a new Activiti project starts. It activates the Activiti-
GenerationProjectFactory class which is responsible for creating Activiti projects by
the specific project name and performs the creation of template classes by using the
ActivitiGenerationProjectFileTemplateFactory class. Afterwards the Activi-
tiGenerationProject class consumes the created templates and embeds them in the
Eclipse Java project.
53

Figure 9.15: The sequence diagram showing the creation of file templates
54

10 Transforming Java Workflow Tooling business
processes
One of the most important challenges in integrating Java Workflow Tooling with the
Activiti process engine is the fact that JWT process definitions cannot be interpreted by
the Activiti Engine. The only format which can be accepted by the Activiti Engine are
the BPMN 2.0 modeling constructs. As mentioned in part 2, there are many different
elements grouped into three different levels which can be used for high-level business
modeling without a lot of restrictions. But we are going to take into account only those
constructs which are supported by the Activiti Engine (see appendix C), and which can
be easily mapped to JWT constructs. JWT constructs do not represent elements which
can be assigned to different levels because all of them originate from the first level
(level 1) to provide a minimal set of elements for high-level modeling (see figure 3.2).
This means that our transformation approach has only to deal with elements from the
first level and perform only level 1 – to – level 1 transformations. As we want to provide
the ability to extend the list of transformations with new ones in the event of
introducing new JWT constructs, we are going to realize a generic transformation
approach which will be explained in detail throughout this section.
Figure 10.1: An overview of the transformation objectives between JWT and Activiti
In figure 10.1, we emphasized one more time two main transformation aspects which
we are going to take into account while implementing the functionality of transforming
JWT process definitions to Activiti process definitions. However, our objective is not
only to provide a mechanism for generating a reliable output for the Activiti process
engine but also to make transformed JWT process definitions visually editable by
means of the Activiti tool stack. That's why, we should also provide a mechanism for
transforming graphical information of JWT process definitions into a format which can
be accepted by the Activiti Designer. Activiti makes use of the BPMN 2.0 Diagram
Interchange standard which serves as a basis for visualizing Activiti process definitions
within the Activiti Designer. Thus, when the transformed information about graphical
positions of JWT elements will be included into the BPMN 2.0 output of JWT process
definitions, the developer will get the opportunity to see and to modify them as BPMN
2.0 diagrams.
10.1 Developing an in-memory transformation mechanism
In order to implement an in-memory transformation mechanism, we should be aware
of two main aspects which we have mentioned above. We do not only want to make
55

JWT process definitions to be accepted by the Activiti Engine but we also want to
provide the possibility for editing them as BPMN 2.0 process definitions. For this
purpose the process of transforming the relevant graphical information of JWT process
definitions should become an inherent part for our in-memory transformation
approach.
We decided to realize our transformation approach as a custom implementation
because the meta model of Activiti process definitions does not base on the Ecore
model of EMF [Sbp09] which in turn is the basis for the Model-to-Model Transfor-
mation [Mot14] framework of which we could make use, if Activiti supported EMF.
Now let us take a closer look at the code snippet (see listing 10.1) which was
implemented to initialize the transformation process between JWT and Activiti process
definitions.
private void transformModel(
final JwtMemoryModel jwtMemoryModel,
final ActivitiMemoryModel activitiMemoryModel){
TransformationManager transformationManager =
new TransformationManager();
transformationManager.defineTransformation(
jwtMemoryModel, activitiMemoryModel,
new ITransformation() {
public void onTransformModel(
TransformationPerformer performer) {
JwtToActivitiModelFormatter formatter =
new JwtToActivitiModelFormatter(performer);
formatter.transform(
jwtMemoryModel.getModel(),
activitiMemoryModel.getModel());
}
public void onTransformDiagramInterchange(
TransformationPerformer performer) {
...
}
});
transformationManager.startTransformation();
}
Listing 10.1: Implementing the initialization of the transformation process
In listing 10.1, you can see how a transformation process between JWT and Activiti can
be defined and afterwards started. A detailed explanation of how the specific classes are
related to each other is presented in the class diagram in figure 10.2.
The private method transformModel which is also shown in listing 10.1 is part of the
JwtToActivitiTransformation class (see figure 10.4) and functions as a holder of the
transformation logic.
56

Figure 10.2: The class diagram showing the architecture of the transformation process
57

The class diagram in figure 10.2 reveals the concept of classes which were introduced to
provide a flexible mechanism for defining in-memory transformations between two
different meta models.
The starting point of this transformation mechanism is the TransformationManager
class which provides the functionality for registering a transformation (see
defineTransformation method) and afterwards starting it (see startTrans-
formation method). Each transformation which can be registered and executed by the
TransformationManager class implements the ITransformation interface with two
basic methods onTransformModel and onTransformDiagramInterchange. These
methods were designed intentionally in that way in order to separate the two
transformation flows and to strengthen their isolation.
In listing 10.1, you can see that we did not create a concrete class which would
implement the ITransformation interface but, in contrast, we make use of one of the
most powerful features of Java programming language by notifying it that an
anonymous class which implements the interface should be instantiated [Fla05].
Each of these two methods onTransformModel and onTransformDiagramInter-
change await an instantiated TransformationPerformer class as a parameter. It
tracks each transformation step by instantiating each time the Transformation-
Element class and storing it within the TransformationPerformer object.
In turn, the TransformationElement class stores the mapping information about how
an element of the source meta model was transformed into an element of the target
meta model. Both elements are also stored within the specific Transformation-
Element object. However, in listing 10.1 we cannot see how a new transformation step
can be defined. This aspect will be explained in section 10.2.
As shown in figure 10.3, the main transformation phases can be arranged into a
sequence of logical steps which begins with the reading process of a JWT model
(.workflow file) from the hard drive and ends with the writing process of the
corresponding Activiti model to the hard drive. We did not implemente both the first
step (1) and the third step (3) because the first step is performed automatically by the
EMF framework and the third one by a helper class within the Activiti Designer plugin.
Hence, we focused on the second step (2) and implemented the concept which we
described in detail throughout this section.
Figure 10.3: An overview of the main transformation phases
The sequence diagram (see figure 10.4) gives one more time an overview of main steps
performed between the JWT plugin and the JwtToActivitiTransformation class in
order to transform a JWT process definition into a BPMN 2.0 output. After creating
and passing back the transformation result in terms of BPMN 2.o XML, the JWT plugin
will create a .bpmn file with the specific content. As soon as we click on this file, it will
be loaded and displayed by the Activiti diagram editor.
58

Figure 10.4: The sequence diagram showing the main steps to start the transformation process
59

10.2 Creating, mapping and appending target
transformation elements
As mentioned above, our goal is to create an architecture which will provide a reliable
mechanism for performing in-memory transformations between JWT and Activiti
process definitions. We decided to implement this approach without using the Eclipse
transformation framework – Model-to-Model Transformation – because only the meta
model of JWT makes use of EMF as a core framework for the mentioned
transformation framework. In contrast, the Activiti meta model was implemented
without usage of EMF. This means that the only way to perform transformations
between JWT and Activiti is to develop a custom transformation mechanism.
We have described that for creating high-value process definitions a simple minimal set
of elements can be sufficient. Thus, we are going to illustrate the main concepts of our
approach by including the basic model elements into our class diagrams. As we want to
make JWT process definitions executable by the Activiti process engine, only an
unidirectional transformation comes into question. Therefore, the perspective of
describing the approach and applying naming conventions for the specific classes is
always – JWT-to-Activiti.
The ActivitiModelElementFactory class (see figure 10.5) is a factory which is
responsible for creating BPMN 2.0 elements with additional Activiti extension
definitions. When our transformation logic needs to transform a new JWT element, we
can just extend the ActivitiModelElementFactory class in the way that we add a
method which will create during its invocation an instance of the corresponding BPMN
2.0 element from the Activiti meta model.
Figure 10.5: The factory class for creating Activiti model elements
After creating a BPMN 2.0 element by means of the ActivitiModelElementFactory
class, this element should be appended to an Activiti model. For this purpose we have
introduced the ActivitiModelElementAppender class (see figure 10.6). The number
of methods in this class is the same as in the ActivitiModelElementFactory class
because each method is responsible for appending only one concrete BPMN 2.0
element to the Activiti model. Another class which represents a similar behaviour is the
JwtToActivitiModelElementMapper class (see figure 10.6). It has the same number
of methods and provides the necessary functionality to perform mappings between
60

JWT and Activiti meta model elements.
Figure 10.6: An overview of map and append methods between JWT and Activiti
Consequently from this standpoint, it follows that these three classes should function
together and be controlled by a more major one (see figure 10.7).
Figure 10.7: An overview of transform methods
The JwtToActivitiModelFormatter class contains only one public method trans-
61

form which represents the functionality for transforming a JWT process definition to
the corresponding Activiti process definition. Thus, this method is responsible for
transforming each element of the JWT model to its target element and appending them
to the Activiti model. All other methods are private methods because they contain only
the specific logic for transforming a single model element, and their invocation is
therefore controlled by the main transform method.
Each private transform method transforms a model element according to the
following illustration (see figure 10.8).
Figure 10.8: An overview of dependencies used in transform methods
Hence, according to our approach three logical steps should be performed to transform
an element of one model to an element of another model. Firstly, we create the target
model element; secondly we map data from the source model element to the target
model element and finally append it to the target model. Now let us have a look at the
concrete implementation of these methods.
In the following listings (listing 10.2, 10.3, 10.4) we illustrated how the JWT Activity
element will be transformed to the Activiti/BPMN 2.0 Process element by invoking –
create (see listing 10.2), map (see listing 10.3), append (see listing 10.4) – operations.
Transform
private Process transformActivity(
final Activity activity,
final Bpmn2MemoryModel model){
//transforms the jwt activity element to the activiti process element
final Process process = ActivitiModelElementFactory.createProcess();
this.performer.transform(activity, process,
new ITransformationStep(){
public void onPerform() {
JwtToActivitiModelElementMapper
.mapActivityToProcess(activity, process);
}
public void onFinish() {
ActivitiModelElementAppender
62

.appendProcess(process, model);
}
});
return process;
}
Listing 10.2: A transform method for transforming the JWT Activity model
element to the Activiti Process model element
Map
public static void mapActivityToProcess(
Activity jwtActivity,
Process activitiProcess) {
if(!StringUtils.isEmpty(jwtActivity.getName())) {
activitiProcess.setName(jwtActivity.getName());
}
}
Listing 10.3: A map method for mapping the JWT Activity model element to the
Activiti Process model element
Append
public static void appendProcess(
Process process,
Bpmn2MemoryModel appendTo){
appendTo.addProcess(process);
}
Listing 10.4: An append method for appending the Activiti Process model element to
the Activiti model
10.3 Applying a post-transformation mechanism
In section 10.1, we described how a JWT process definition can be transformed into an
Activiti process definition by passing through three phases (see figure 10.3). It is a
flexible approach when we want to transform static process definitions. However, our
transformation mechanism has to deal with dynamic data which is essential for
extending and adapting to Activiti process definitions. The dynamic information about
model elements originates every time when execution and monitoring aspects should
be taken into account. As mentioned throughout this thesis, in order to provide Activiti
process definitions with the specific logic, we must define Java classes containing the
logic and attach them to the corresponding service tasks. As the transition from a JWT
process definition to an Activiti process definition is planned as an automatic
transformation, Java classes must be generated on-the-fly and referenced within the
63

transformed Activiti process definition.
As our in-memory transformation mechanism was implemented as an isolated module
for performing transformations between JWT and Activiti, we cannot combine it with
the generation of Java classes for service tasks. They should be generated afterwards.
This means that a new phase (see figure 10.9) should be introduced and placed between
the last two phases (see figure 10.3).
Figure 10.9: Extending the main transformation phases
As mentioned above, we clarified that in order to apply Activiti listeners according to
table 5.1 (see section 5.5), we need to include them into Activiti process definitions as
references by providing their class names. For this purpose we introduced the
ActivitiModelElementListenerFactory class which contains methods for creating
Activiti listeners for the basic Activiti model elements (see figure 10.10).
Figure 10.10: An overview of create methods for defining Activiti listeners
But our objective is to initialize Acitiviti listeners in a way that they could be identified
by our post-transformation mechanism and supplemented with the right class names.
Now let us have a look at a concrete implementation of the createSequenceFlow-
Listeners method (see listing 10.5) in order to understand how we performed the
current task.
public static List<ActivitiListener> createSequenceFlowListeners() {
ActivitiListener takeListener = new ActivitiListener();
takeListener.setEvent("take");
takeListener.setImplementation(
"{{ sequenceFlowTakeExecutionListener }}");
List<ActivitiListener> listeners = new
ArrayList<ActivitiListener>();
64

Integrating JWT with Activiti

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Integrating JWT with Activiti

Similar to Integrating JWT with Activiti (20)

Recently uploaded

Recently uploaded (20)

Integrating JWT with Activiti