![WfMC Generic Structure [11]](https://www.researchgate.net/profile/Michael-Oland/publication/334262850/figure/fig3/AS:778065781211138@1562516746923/WfMC-Generic-Structure-11_Q320.jpg)
Content uploaded by Michael Andrew Oland
Author content
All content in this area was uploaded by Michael Andrew Oland on Jul 07, 2019
Content may be subject to copyright.
BABES¸-BOLYAI UNIVERSITY CLUJ-NAPOCA
FACULTY OF MATHEMATICS AND COMPUTER SCIENCE
HIGH PERFORMANCE COMPUTING AND BIG DATA
ANALYTICS
MASTERS DISSERTATION
A Parallel Programming Driven Comparison Between Workflow
Management and Advanced Case Management Systems
Supervisor
Asscoiate Professor Dr. Virginia Niculescu
Author
Michael Andrew Oland
2019
Abstract
Computers and information technology are commonly used to perform com-
plex tasks more efficiently. Within information technology, two disciplines
that are often used to assist businesses and other domains complete processes
in a more efficient manner are workflow management and advanced case man-
agement. Workflow management is a discipline that is used to document,
enforce, and streamline repetitive processes. Advanced Case Management is
an emerging field that is an alternative to traditional workflow management
and that offers more flexibility in completing processes. Both disciplines can
provide additional efficiency gains through enabling business to distribute
tasks to multiple users simultaneously.
Another discipline in computer science is parallel and high-performance
computing. It offers users a similar ability to increase performance and
throughput of complex processes through parallel task execution and work
distribution across multiple systems.
To explore the commonality between the three disciplines, this paper
will review both the disciplines of workflow management and advanced case
management from a parallel programming perspective. In addition, this
paper will present a prototype of a new framework based on the guard-stage-
milestone methodology of advanced case management, that has been built on
the Akka actor model framework, uses a common big data NoSQL database
for data storage, and can be used to demonstrate how an advanced case
management system can be used to as a parallel task execution environment.
Contents
1 Introduction 4
1.1 RelatedWork ........................... 5
1.2 Outline of Dissertation . . . . . . . . . . . . . . . . . . . . . . 5
2 Workflow Management 7
2.1 Key Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Processes ......................... 8
2.1.2 CaseTypes ........................ 9
2.1.3 Tasks............................ 9
2.1.4 Content and Attributes . . . . . . . . . . . . . . . . . . 10
2.1.5 Routing and Rules . . . . . . . . . . . . . . . . . . . . 10
2.1.6 Case ............................ 10
2.2 Resource Allocation . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Workflow Management Systems . . . . . . . . . . . . . . . . . 12
2.3.1 Process Definition Tool . . . . . . . . . . . . . . . . . . 13
2.3.2 Workflow Management Engine . . . . . . . . . . . . . . 15
2.3.3 Work Lists and Handlers . . . . . . . . . . . . . . . . . 15
2.3.4 Workflow Relevant Data . . . . . . . . . . . . . . . . . 17
2.3.5 Example Architectures . . . . . . . . . . . . . . . . . . 17
3 Advanced Case Management 20
3.1 Key Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 20
3.1.1 Process .......................... 21
3.1.2 CaseType......................... 21
3.1.3 Tasks............................ 21
3.1.4 Case ............................ 22
3.1.5 Attributes......................... 22
3.1.6 Routing and Rules . . . . . . . . . . . . . . . . . . . . 23
1
3.2 Comparison with Workflow Management . . . . . . . . . . . . 23
4 Parallel Execution Patterns 24
4.1 Control and Routing Patterns . . . . . . . . . . . . . . . . . . 25
4.1.1 Classes of Parallel Computation . . . . . . . . . . . . . 25
4.1.2 Parallelism......................... 26
4.1.3 Pipeline .......................... 29
4.2 Work Distribution and Allocation . . . . . . . . . . . . . . . . 29
4.2.1 Direct and Push Distribution . . . . . . . . . . . . . . 29
4.2.2 Dynamic Distribution . . . . . . . . . . . . . . . . . . 30
4.3 DataPatterns........................... 31
4.3.1 Scoping .......................... 31
4.3.2 Rules and Routing . . . . . . . . . . . . . . . . . . . . 32
4.4 OtherPatterns .......................... 34
5 Actor Model 35
5.1 Key Principles of Actor Design . . . . . . . . . . . . . . . . . 35
5.2 Mapping Actors to Workflow . . . . . . . . . . . . . . . . . . . 36
5.3 Akka................................ 36
6 Implementing Dynamic Case Management with Actors 38
6.1 Goals................................ 39
6.2 Implementation Methodology . . . . . . . . . . . . . . . . . . 40
6.3 Architecture............................ 41
6.3.1 Core ............................ 42
6.3.2 Planning Data Model (dcm.planning) . . . . . . . . . . 43
6.3.3 Executor (dcm.executor) . . . . . . . . . . . . . . . . . 50
6.3.4 Engine (dcm.engines) . . . . . . . . . . . . . . . . . . . 52
6.4 ActorFramework ......................... 53
6.4.1 Persistence ........................ 54
6.4.2 Locking .......................... 55
6.4.3 Task Executor . . . . . . . . . . . . . . . . . . . . . . . 56
6.4.4 Guard ........................... 57
6.4.5 Interaction......................... 58
6.5 Serialization Framework . . . . . . . . . . . . . . . . . . . . . 59
6.5.1 Value Serialization . . . . . . . . . . . . . . . . . . . . 60
6.5.2 Implementations . . . . . . . . . . . . . . . . . . . . . 62
2
Chapter 1
Introduction
One of the primary reasons for using computers and information technology
is to assist people in completing work in a faster and more efficient manner.
Computers initially started as mechanisms for performing calculations in less
time than a human could. This technology has continued to progress into
the modern systems we have today.
As an outgrowth of this technology, two lines of research and use have
emerged: using computers to make business processes more efficient through
the application of workflow management and a related area of applying ele-
ments of case management to a similar set of problems.
At their core, both Advanced Case Management (ACM) and workflow
management concern themselves with identifying work to be accomplished,
planning out the steps and activities necessary to complete the work, deter-
mining how to efficiently distribute that work between multiple resources,
and collecting the results.
While there have been a number of comparisons between ACM and work-
flow management, such as Case management: an evaluation of existing ap-
proaches for knowledge-intensive processes [20], these comparisons typically
focus on the business processing aspects of the solutions. This paper will
also compare the two disciplines, but it will do so through the discipline of
parallel programming.
While the areas of Business Process Management (BPM), workflow man-
agement, ACM, and parallel programming may not appear to be related,
there are potentials for commonality. Both workflow management and par-
allel programming will divide work into small units of work, distribute them
to multiple resources for completion, ensure completeness through synchro-
4
nization strategies, and gather the results. Given this commonality, this
paper will attempt to compare the two disciplines of ACM and workflow
management from a parallelism standpoint.
1.1 Related Work
Before comparing the two disciplines, it is important to understand the state
of the art as this will provide the basis for any comparisons.
Any survey of workflow patterns begins with the work of van der Aalst.
His book on workflow, Workflow Management: Models, Methods, and Sys-
tems [33] defines the common terms for elements of workflow and workflow
management. He, along with Russell, has also creating commonly used pat-
terns in workflow systems1[30] [27] [26] [28] [29]. The discussions on workflow
are also informed by this thesis’ author’s almost two decades of experience
implementing IBM Case Foundation (ICF) and IBM Case Manager (ICM),
IBM’s Enterprise Content Management (ECM), workflow, and advanced case
management products [36] [37].
This paper will also discuss advanced, or dynamic, case management.
Based on the work of van der Aalst [1] [32], Hull [12] [13] and Marin [17],
this area of research strives to overcome some key limitations of traditional
workflow systems through the application of classic case management tech-
niques. It is this technique and approach we used when creating a proof-
of-concept application for this dissertation. In describing the ACM terms
and patterns, they will often be described by using Case Manager Modeling
Notation (CMMN) from The Object Management Group (OMG) [24].
For comparisons to parallel programming, this paper builds on several
existing works including, Programming Language Design Concepts [34]. And
the parallel programming patterns from Massingill [21] and Keutzer [15].
1.2 Outline of Dissertation
This paper is organized as follows:
•Chapter 2 introduces workflow management, its history and identifies
the workflow terms and concepts that are used in Chapter chapter 3.
1The Workflow Patterns Initiative has published the full collection of patterns at http:
//www.workflowpatterns.com/, including animated examples of the control patterns.
5
•Chapter 3 introduces advanced case management as an alternative way
of approaching goal completion and identifies the processing concepts
embodied in this technique
•Chapter 4 reviews common patterns from workflow management as
they apply to advanced case management, and where applicable, par-
allel processing.
•Chapter 5 reviews the actor model of parallel programming.
•Chapter 6 describes the implementation of a the dynamic case man-
agement framework.
•Chapter 7 Evaluates the dynamic case management framework, recom-
mend additional areas of research and, present the conclusions.
6
Chapter 2
Workflow Management
Modern workflow management is an outgrowth of Petri Nets [25] and of-
fice automation systems. While there was an attempt in the 1970s to use
computer processing to help achieve business goals, it failed due to the com-
plexity of the challenges and limitations of the hardware at the time. The
late 1980s and early 1990s saw the rise of commodity hardware and software
which allowed for the development of computer-based workflow management
systems. These systems allowed for businesses to define, organize, and im-
plement processes for execution in or in conjunction with computer systems
[33].
Workflow management systems were first created in the 1980s with the
advent of computer-based workflow management systems, such as Action
Coordinator,FileNet WorkFlo1, and Staffware [26]. Today the technology is
used in many businesses across a wide range of industries.
BPM is a related discipline to workflow management that tends to focus
on the business aspects of the discipline where workflow management tends
to focus more on the technical side. The Workflow Management Coalition
(WfMC) defines BPM as follows:2
”Business Process Management (BPM) is a discipline involv-
ing any combination of modeling, automation, execution, control,
measurement and optimization of business activity flows, in sup-
1It should be noted that FileNet WorkFlo is the predecessor of the current IBM Case
Foundation and IBM Case Manager product suites that the author of this paper has been
involved in implementing for the past fifteen years.
2Source: http://www.wfmc.org/what-is-bpm
7
port of enterprise goals, spanning systems, employees, customers
and partners within and beyond the enterprise boundaries.”
2.1 Key Terms and Concepts
Workflow and business process management describe systems or processes
that define, control, and coordinate the execution of tasks in order to reach a
defined goal. In achieving the goal, the system also ensures that flow of work
is executed efficiently by ensuring the right work is done by the right person
or resource in the right time [37] [8] [33] [36]. The system should also allow
for tasks and work to be completed in parallel, also increasing the efficiency
of the system and its users.
In a white paper from 2002, Weidel defined the following fundamental
elements of workflow [35]:
•A workflow is defined as the fundamental path that a unit of work can
take from the entry point into a process flow to the point of completion
or exit from the flow;
•A workflow can have logical decision points that determine which branch
of the flow an object will take in the event of alternative paths;
•Every alternate path within the flow is identified and controlled through
a bounded set of logical decision points; and
•An instantiation of a workflow to support an object (unit of work)
includes all possible paths from beginning to end.
Beyond the above definitions, van der Aalst defined a number of key terms
used in describing workflows. The remainder of this section will describe
these terms and concepts [33].
2.1.1 Processes
In BPM, the purpose of a workflow is achieve a specific goal by involving
the right people in the process at the right time [37]. This planning will
ultimately result in what van der Aalst defines as a process. The process
will define the tasks to be completed; the order of the tasks; the rules which
8
Ar cle Submission Process
Write and Submit
Ar cle
Ini al Review Review Outcome
Perform Correc ons
Peer Review Review Outcome
Approved
Needs Work
Prepare for
Publishing
Sign Release
Paperwork
Pubslish
Reviewers Editor Author
Needs Changes
Ready for Peer Review
Figure 2.1: A BPMN activity diagram describing a business process
determine which tasks and what order are executed; and define any branch-
ing and merging that can occur during the execution of the process [33].
Figure 2.1 is an example of a process described using BPMN as defined by
OMG [23].
2.1.2 Case Types
In addition to the case itself, similar cases are typically grouped together as
a case type. The case type represents the product being ”manufactured” by
executing the workflow process [1].
2.1.3 Tasks
A task within a workflow or process represents the smallest logical unit of
work to be completed. It is typically an atomic unit and is carried out by a
single resource. A task can be thought of as a step in the process, such as:
retrieve credit score, check references, or issue credit card.
Tasks can be one of three types: [33]
•Manual - one or more people can complete this task type without
using an application
•Automatic - a type of task that can be completed without human
action
9
•Semi-automatic - a human task that may require specific resources
to be completed
2.1.4 Content and Attributes
When designing and executing a workflow, there will be the need to collect
and use data. This data takes two different forms: content and attributes
[33].
Attributes are data that is used by or generated from executing the
workflow. This data can be used for guiding the movement of the work
through the process or can be used for analysis or reporting purposes.
The second form of data structure used in workflow management is con-
tent. This is data outside the workflow management system that is referred
to by the case. Sometimes this content is called an attachment [36] and can
be a document or collection of documents that the case either represents or
will be part of the work accomplished in completing the goal of the case. Ex-
amples could be images of a car crash for an insurance claim, an application
form, or a document that is being reviewed for publication.
2.1.5 Routing and Rules
Routing within a workflow defines the steps that are taken to complete the
goal. The route is similar to the path taken in a physical map and depending
on the type of processing, specifically if the workflow includes conditional
branching, the route may not be known before the workflow is started.
Rules are decisions that determine which route(s) or path(s) a workflow
process will take. These rules use attributes or other elements available to
the workflow execution environment in determining the outcome and as a
result determine where the work should be routed next.
2.1.6 Case
The instantiation of a workflow process is called a case which represents
a single, tangible thing being produced or modified [33]. The thing can be
concrete or abstract, but it must be realized following the steps defined in the
process. Examples of a case can include insurance claims, credit applications,
or credit card charge dispute.
10
2.2 Resource Allocation
Within both process definition and execution, tasks are provided or allocated
to resources. This allocation can take multiple forms, such as: round-robin,
random, or shortest queue distribution. Resources can also be allowed to
pull work directly from a work list. A deeper discussion on resource allocation
is in section 4.2 [29].
It is the workflow system’s ability to distribute work and allocate re-
sources that enables many of the performance gains through a form of paral-
lel execution. If tasks in a workflow can be distributed to different resources,
they will be able to execute those simultaneously, providing parallel task ex-
ecution. Figure 2.2 is an example of a process that is split into sequential
and parallel tasks.
Figure 2.2: Sequential and Parallel Tasks in BPMN
11
2.3 Workflow Management Systems
The WfMC has created a reference architecture[11] for workflow systems
which defines the following key components:
•Process definition tool and process definitions
•Workflow management engine(s)
•Work lists, work list handlers, and user interfaces
•Workflow relevant data
This section describes several components of the architecture with the
full model is shown in Figure 2.3.
12
Figure 2.3: WfMC Generic Structure [11]
Throughout this section, examples will be given for both ICF and jBPM.
2.3.1 Process Definition Tool
The process definition tool is used to define and design the workflow processes
themselves. As described in subsection 2.1.1, the processes will define what
tasks are to be executed in completing the goal. The tool will also prepare
the processes for execution in the workflow management engines. Figure 2.4
shows the ICF process design tool called Process Designer which uses its
13
own design and iconography for process definition3[36]. Figure 2.5 shows
the jBPM process designer tool which uses BPMN as the basis for its process
design iconography and process definition4.
Figure 2.4: The ICF Process Designer process definition tool.
3Image captured from a working installation of ICF.
4Image captured from a working installation of jBPM
14
Figure 2.5: The jBPM process definition tool.
2.3.2 Workflow Management Engine
In the reference model, the engine(s) interpret the process, instantiate the
cases, implement the rules, control the routing of tasks, and allocate the
work. In the model, there can be one or more engines presenting work to
resources for execution. The engine is also tasked with maintaining workflow
relevant data and ensuring consistency across instances.
It is the workflow engine’s ability to present work to one or more users, in
the form of work lists as described in subsection 2.3.3, that allows for parallel
work execution. Similar to a job scheduler in a cluster, it will present tasks
to the various resources for completion.
2.3.3 Work Lists and Handlers
Work lists are a method of distributing tasks to work list handlers and ulti-
mately workflow participants. Depending on the type of participant, human
or automated, the work list handler could be a user interface or an appli-
cation that reads work items and automatically executes them without user
interaction.
Figures 2.6 and 2.7 show the ICF work lists and work handler user inter-
faces through the IBM Content Navigator (ICN) front end application.
15
Figure 2.6: IBM Case Foundation worklist in ICN
Figure 2.7: A work handler in ICN
16
2.3.4 Workflow Relevant Data
Workflow relevant data is case data that is gathered, used, and stored during
the lifecycle of the case. As mentioned in subsection 2.1.4, this data can
be used to control routing and for reporting purposes. Figure 2.7 shows the
work list handler, and the workflow relevant data is shown as PatientName,
Reason and Comment.
2.3.5 Example Architectures
Figures 2.8 and 2.9 show the architectures for jBPM5and ICF6. In the ICF
architecture, the workflow engine is represented in the services layer by the
Content Platform Engine (center highlighted in red) with case relevant
data being persisted in the repository database (bottom left highlighted in
red). In jBPM the execution engine is represented by the core engine and
human task service. Case relevant data is stored in the persistence layer.
5Image from https://docs.jboss.org/jbpm/v6.0/userguide/jBPMOverview.html
6Image from https://www.ibm.com/support/knowledgecenter/en/SSNW2F_5.2.1/
com.ibm.p8.sysoverview.doc/p8sov154.htm
17
Figure 2.8: jBPM Architecture
18
Figure 2.9: IBM FileNet Architecture
19
Chapter 3
Advanced Case Management
In addition to workflow management, there is an emerging area of research
around applying traditional case management techniques to process manage-
ment called ACM or Dynamic Case Management (DCM) [1] [13].
This method of process management came about as businesses and com-
puter scientists realized that workflows and workflow systems were overly
restrictive [1] [32] [17]. Modern case management started with an often cited
1994 MIT Sloane article reviewing how organizations moved from a restric-
tive workflow management model to a more case-centric model [5].
Subsequent work was completed by van der Aalst [1], Hull [12] [13], and
Marin [17]. The outcome of Hull and Marin’s work was IBM Case Manager,
a product built on the legacy of the IBM FileNet P8 Process Engine and
ultimately the FileNet WorkFlo system from the 1980s [37].
One key outcome of this research was the Guard-Stage-Milestone (GSM)
approach to managing ACM solutions [12]. While there may be other ap-
proaches to implementing advanced case management, it is the GSM ap-
proach that will be described in this chapter. The remaining part of this
chapter will map the GSM and ACM terms to those defined in chapter 2.
Much of this chapter is also based on the CMMN form of notations [24].
3.1 Key Terms and Concepts
While this section compares ACM terms to the workflow terms and concepts
from section 2.1, it should be noted that ACM planning elements can be
more high level. Specifically, the smallest unit of work can represent much
20
more complex processes, specifically other workflows processes.
The following terms are taken from Hull [12]; from the Advanced Case
Management with IBM Case Manager Redbook1[37]; the CMMN specifica-
tion by OMG [24]; Introduction to the Case Management Model and Notation
(CMMN) by Marin [16]; and from the author’s own experience implementing
ACM with ICM.
3.1.1 Process
While workflow management uses a process as its core component for repre-
senting a plan, case management uses a case plan as its design and planning
element. The case plan defines the key elements of a case that either must
be or can optionally be executed; how they are grouped together and the
milestones that completion of these represent.
The case plan can contain the following items:
•Stages - a stage is a way of grouping together tasks and case files,
described in subsection 3.1.5, into a logical group. A stage can contain
or define one or more tasks, case files, and one or more guards.
•Milestones - these represent an accomplishment to be achieved during
the completion of a case.
•Tasks - a set of work that may be completed during the lifecycle of the
case. Tasks are further described in subsection 3.1.3.
3.1.2 Case Type
Workflow management defines a group of similar tasks as a case type. Case
management follows a similar pattern by using the case plan to represent
the grouping. There is no specific term that is analogous to a workflow case
type, but ICM does use the term Case Type to define a case plan [37].
3.1.3 Tasks
Where workflow management defines the smallest unit of work as a single step
or task in a process, case management also uses the term task to represent
1The author of this paper also co-wrote the third revision of this Redbook
21
the smallest unit of work. One key difference between ACM and workflows
is that a task can represent a single activity or it can be a placeholder for a
complete process.
Within CMMN, tasks can be defined as one of five types: human block-
ing,human non-blocking,case,decision, and process. A human non-
blocking task is considered completed when the task is claimed by the worker
where a human blocking must be completed by the worker. Case tasks will
create a new case separate from the running case. A process task is a task
that will invoke a workflow process. A decision task is used to represent a
decision that will be made using the available case data [16] [24].
A task can also be described in CMMN as manual,repetition, and
required. A manual task can be started at any time by a case worker. A
repetition task can be repeatedly started and completed during the execution
of a case. A required task must be completed before a case can be completed
[16] [24].
3.1.4 Case
Case management, like workflow management, refers to an in-process plan
as a case or case folder. This case exists as long as the case exit criteria have
not been met. Unlike workflow management, a case is assumed to have a
long term storage location as well, meaning the data about the case itself
can persist even after the case execution has completed, as it does in ICM
[37].
In addition to guiding work, the case also provides case workers access
to the case data. This gives the workers a view of the case as a whole and
can allow workers more flexibility in meeting the case goals. More details
on the difference between Workflow Management System (WfMS) and ACM
are included in section 3.2.
3.1.5 Attributes
ACM and CMMN refers to the equivalent of attributes and content as case
data and case files. Case data represents the data contained about the case
in the case folder. ACM and CMMN also define a case file, which is the
equivalent of content from workflow management.
22
3.1.6 Routing and Rules
Where workflow defines routing and rules, case management defines guards
to control execution [12]. A guard provides a set of conditions that control
either the entry, exit or achievement within a case folder. Stages, tasks, and
milestones each can have entry conditions that define when that particular
element is either activated or achieved. Case folders and stages may also
contain exit guards that define when that element has been completed. A
task itself can also further defined to be required, optional, or repeating.
3.2 Comparison with Workflow Management
Unlike workflow management where the process is central to the case, case
management uses the case itself as the central component. Activities offer
more flexibility and attempt to balance between process- and data-centric
in nature [18]. The data in the case drives the completion as opposed to
the process itself as in workflow management. This affords the workers more
control as they can view the case in its entirety as opposed to viewing only
the task data presented them. Van der Aalst identified, and Marin reiterated
[18] the following core features of case handling [32]:
1. Avoid context tunneling by providing the users with access to all case
information instead of a subset.
2. Make activities available based on the case data rather than based on
prior activities.
3. Provide query mechanisms to identify work, separating work allocation
from authorization.
4. Allow workers to modify case data before or after activities have been
activated or completed.
In practice, that means that while the workflow designer explicitly states
what is permitted in the process, case design is less prescriptive with more
implicit modeling. This also means that data is a first class citizen along with
processes. The result is greater flexibility with the course of action emerging
gradually based on the experience of the workers [6].
23
Chapter 4
Parallel Execution Patterns
With common terms identified, key patterns can reviewed. As the discipline
of ACM is still fairly new, there are currently few identified patterns for
comparison. However, as ACM is a technique for assigning work, there are
comparisons to be made. This section will also reference parallel program-
ming patterns, when applicable, as the disciples of workflow management
and parallel programming share commonalities. This comparison will lean
heavily on the terms in Table 4.1.
Workflow Case Management
Case Case
Case Type Case Type
Task Task
Process Case Folder
Routing Guards
Attributes Case Data
Table 4.1: Key Concepts and Definition
As a reminder, patterns are a way of prescribing approaches to solving
problems and an attempt to create common language that teams and re-
searchers an use when describing a problem. The idea of patterns comes
from the 1977 paper discussing city design [4], but has consistently been
applied to computer science and informatics disciplines.
The patterns discussed will come from the following sources: the Work-
flow Patterns Initiative [33] [30] [27] [28] [29]; the work of Massigill [21] and
24
Keutzer [14]; the work of Hull [12] [13]; Marin [18] [19] [20] [17]; Zhu [37];
and the author’s experience implementing business processes. Other patterns
and sources will be identified in context.
Excluded from this discussion is any review of skeletons [3]. Future
work on this subject should include skeletons as a potential set of prede-
fined, reusable components for implementing or extending a hybrid workflow-
parallel programming system.
For the purposes of this paper, the patterns will be divided into several
types or classes of patterns, including: control and routing; work distribution;
data; and other patterns.
4.1 Control and Routing Patterns
The Workflow Patterns Initiative has identified and named a number of con-
trol patterns that are used to determine the rules for routing a unit of work
between the various resources involved. There are similar sets of patterns in
parallel programming. This section will identify and compare some of the
commonalities between them.
4.1.1 Classes of Parallel Computation
In parallel programming, patterns are often expressed using Flynn’s taxon-
omy, as pictured in 4.2 [7]. In addition to these classifications, there are also
classifications of Single Program Multiple Data (SPMD) and Multiple Pro-
gram Multiple Data (MPMD) that are defined by parallel execution of one
or more instances of the same program or different programs on the same set
of computing resources.
Instruction
Single Multiple
Data Single SISD MISD
Multiple SIMD MIMD
Table 4.2: Flynn’s Taxonomy
As described in subsection 2.3.2, workflow engines define two key forms
of parallelism: parallel within a task and parallel within the engine itself. A
process that contains a multiple instance section could be compared to Single
25
Instruction Multiple Data (SIMD) where the task is the instruction and the
workflow attributes or content being processed represents the multiple data
elements. A workflow system could also be compared to a SPMD where the
same process is used in multiple cases with different data.
4.1.2 Parallelism
In all three disciplines, there is a need to to guide the flow of execution,
control which can be both conditional and parallel. Conditional control is
where one path is taken depending on the rules or conditions encoded into
the program or process. Parallel control is where processing is split into units
of work that are executed in parallel by multiple computing units.
Figure 4.1: Parallel Split in BPMN
Figure 4.2: Multiple Instance in BPMN
26
Parallel Execution of Tasks
Workflow patterns for parallel task execution are: parallel split, see Fig-
ure 4.1, and the following multiple instance patterns: Multiple Instances
with a Priori Design-Time Knowledge,Multiple Instances with a
Priori Run-Time Knowledge, and Multiple Instances without a Pri-
ori Run-Time Knowledge [30].
The primary difference between parallel split and multiple instance pat-
terns is that the parallel split does not imply that the tasks completed on
each branch of the split are the same. In fact, the tasks could be completely
different. In multiple instance patterns, see Figure 4.2, the task is the same
with either a predefined or arbitrary number of instances of that task be
started when the transfer is triggered.
A very common pattern in parallel programming related to parallel ex-
ecution of tasks is fork-join. This describes a set of tasks that can be
executed in parallel within the same address space [21]. The solution for this
is creating threads and then after all work is completed, join the threads and
continue processing.
ACM does not define a sequential structure for task execution. In fact,
one of the key elements of ACM is that the execution of a case should be
flexible, allowing for the tasks to be completed in the order that best fits the
case data and case files [37][12]. Because of this, there is no direct definition
of parallelism within ACM, but it is implicit in the design. For example,
multiple tasks can be defined with the same entry guard. This would mean
they would be executed simultaneously, creating a form of parallelism similar
to fork-join in parallel programming or parallel splits in workflow.
Synchronization
In parallelism, there is a need to ensure that that further processing will not
continue until the individual tasks are complete. In parallel programming,
this is accomplished through semaphores, barriers, and other constructs.
Keutzer calls these patterns mutual exclusion, point-to-point synchroniza-
tion and collective synchronization. [14].
Workflow processing offers a similar set of synchronization and barrier
conditions that van der Aalst and Russell call synchronization and merge
[30]. When paired with a split, the merge will ensure that processing of
subsequent tasks will not complete until all the tasks before the merge are
27
finished.
The pattern Generalized AND-Join defines a form of synchronization that
is similar to a barrier in parallel programming. In this scenario, multiple tasks
are created and processing cannot continue until all of the tasks have been
completed. In the same way a barrier in parallel programming will not allow
processing to continue until all threads have reached the barrier.
Another form of synchronization and parallelism within workflow man-
agement is the thread-split/thread-merge pattern. In this pattern, a single
task is executed ntypes and distributed to multiple resources. An example
would be multiple reviewers for a single document or a voting scenario where
a single motion is distributed to multiple voters. The corresponding synchro-
nization pattern is thread-merge where further processing is halted until a
defined number of tasks from the split have been completed. For example, in
a voting scenario, processing may not continue until a majority of the voters
have rendered their vote.
Task 1
Task 2
Figure 4.3: Parallel merge in BPMN
Again, ACM does not explicitly define any synchronization elements, such
as merges in workflow management. Synchronization can be achieved within
the design through required tasks or guards. If a stage defines multiple
required tasks, that stage cannot be completed until those tasks are also
completed. Tasks could also be defined with a guard that requires multiple
tasks to be completed prior to starting the new task. Both of those situations
would allow for creating a barrier to the case moving forward until those tasks
were completed.
28
4.1.3 Pipeline
Another parallel pattern identified by Keutzer is the pipeline pattern [14].
This pattern has sequential processing of tasks executed on multiple compute
units. This way once the first task from the first set is completed and moved
to the second task, the first compute unit can begin processing the first task
of the second set. A sequential workflow process can be executed in a similar
manner, and in fact, this is often the situation in business where a sequential
process that utilizes different resources for each step can be processed in
parallel.
4.2 Work Distribution and Allocation
Once the process has been defined and the tasks have been identified, it is
important to determine how best to divide the work between the available
resources to ensure the most efficient execution and completion of the end
goal. When determining how to allocate work, there are a number of pat-
terns and mechanisms that are shared between workflow, ACM, and parallel
programming. These are direct and dynamic distribution. The workflow
resource patterns are defined by Russell and van der Aalst in [29].
4.2.1 Direct and Push Distribution
There are times when it is known before execution the work to be accom-
plished and it can be easily subdivided into sets of work that can be directly
assigned to the various resources. This assignment of work is classified as
direct or push distribution.
The direct distribution workflow pattern describes a scenario where
the process defines a task and then at execution the work is directly assigned
to a specific resource. Russell uses the following example to describe this
pattern: The Fix Bentley task must only be undertaken by Fred [29] . This
would be the equivalent of specifying a specific computer or core in a parallel
program for executing a specific unit of work.
Push distribution describes a set of work allocation patterns whereby
tasks are distributed to resources at runtime. This is accomplished by the
system dividing the work and placing the tasks in a queue or work list for the
resources to complete. Within this high level pattern, Russell [29] describes
29
a set of addition classifications of push distribution such as random;round
robin; and distribution by single or multiple resource.
Parallel programming has a similar pattern whereby the work is divided
into sets of tasks before execution. This is described as part of the embarrass-
ingly parallel pattern by Massingill [21]. An example of this type of allocation
would be a program that calculates matrix operations. As the matrix itself
is a fixed size, the program can divide the work by rows, or some other split,
with each row being assigned to a processing resource.
ACM is less concerned with how work is allocated to users, especially
as one of the CMMN task types is a process type. This type can refer to
a pre-defined workflow process that would apply the above work allocation
patterns. It does, however, define the concept of a case owner or case manager
[31]. This person is often responsible for creating and assigning work to
team members. In that scenario, ACM exhibits a form of push or direct
distribution.
4.2.2 Dynamic Distribution
In contrast to direct distribution, dynamic distribution occurs when the
work is not necessarily known ahead of time or when the optimal distribution
of tasks cannot be known. In these scenarios, the tasks are made available
for resources to request when they have capacity to spare.
The Workflow Patterns Initiative defines these distribution scenarios as
pull patterns where resources utilize a shared work list or queue instead of
maintaining a local list of work to be completed. In this manner, the work is
then automatically distributed among the resources. Given this mechanism,
the workflow team defined six distinct forms of allocation, with either the
resource itself or the system determining execution order [29].
In parallel programming, there are similar patterns including queue and
shared data structure-based work distribution. They all share a similarity
to the pull patterns in that there is a shared element and the resources are all
working from that same shared element. Three of these patterns identified
by Keutzer [15] are task queue,shared queue and shared map. A task
queue is similar to a work list in workflow processing in that the task queue
contains a set of tasks that the processing units can retrieve work from. A
shared queue and shared map also contain work to be completed.
In each of the options listed above, it is important to ensure that there is
a mechanism in place to synchronize access to the queue or work items.
30
4.3 Data Patterns
Data in workflow management and ACM is typically used in achieving the
business goal, or generated in the process of achieving that goal. Workflow
relevant, or case data, is often used for determining routing and rules within
a process. This type of attribute data is often smaller or discrete values.
There is a second set of data, the content or attachments, that can contain
a broader set of information that can be the information the process worker
will be operating on. For example, a step in a process may require a worker
to retrieve a spreadsheet or other structured data; perform calculations or
other analysis; and generate a set of results.
4.3.1 Scoping
Similar to how variables in programming have scope, workflow data can also
have a form of scope. Russell [28] defines the following types of data:
•Task Data - available only within the task itself
•Block Data - available only to the sub-workflow
•Scope Data - available only to subset of tasks in a case
•Case Data - available to all tasks and components in a case
•Workflow Data - available to all cases in a system
•Environment Data - execution environment
Case management does not define scope as in the workflow data patterns
from above, but one key element to ACM is the use of case data globally. A
case contains the case data and is made available to users, including those
not currently involved in a task. This is different than workflow management
where users typically only are exposed to workflow data when involved in
a task. Though not explicitly stated in CMMN or other definitions, it is
possible to offer data at the task level as well. For example, ICM offers case,
task and, process level properties and attributes.
31
Figure 4.4: IBM Case Manager case details view with case files on the left
and case folder data on the right.
4.3.2 Rules and Routing
One key use of data in workflow management is in rules that generate routing
decisions. At exclusive gateways or split points, values in the case data can
be used to determine which route is taken and how work is transferred to the
next task in the process. Figure 4.5 shows how routing is defined in jBPM
using Java language syntax.
32
Figure 4.5: Defining conditions for a route in jBPM.
As mentioned in 3.1.6, case data can also be used in ACM for managing
entry and exit criteria for cases, tasks, and milestones. In fact, the utilization
of data for these purposes parallels the workflow data-based routing patterns
listed below from [30]. The precondition patterns below apply to cases,
stages, milestones, and tasks. The post condition patterns apply to stages
and the case itself. The triggers apply to cases and tasks. Only the data-
based routing does not directly apply.
•Task Precondition - based on either the existence of a data element or
a specific data value.
•Task Postcondition - based on either the existence of a data element or
a specific data value.
•Event-based Task Trigger - starting a task based on an external event
•Data-based Task Trigger - starting a task when a specific data value or
condition is met.
33
•Data-based Routing - controlling flow based on data values.
4.4 Other Patterns
The following patterns more closely concerns itself with the workflow plan-
ning and design than any specific set of execution criteria. In fact, some of
these may even be used not by workflow designers, but by business analysts
or business representatives when determining how best to define a process.
The following are patterns pulled from Keutzer [15] that apply to both
parallel programming and forms of business process re-engineering, the dis-
cipline of reviewing business processes with respect to their workflow and
efficient completion.
Agent and repository maintains a central data repository that au-
tonomous agents can operate upon, or in workflow terminology, a central
repository of tasks that agents can pull from or that a manager can use to
push work to the agents. This form of work distribution is common in busi-
nesses where the workers are highly trained, self organizing, and trustworthy.
The puppeteer pattern similarly has a manager that controls the dis-
tribution of work and coordination of efforts between the agents involved in
completing the work. This form of work allocation and distribution is also
common in a business. It also forms the basis for a case manager as a role
within a case management solution. The case manager is the owner of the
case and is responsible for coordinating the work to achieve the goal.
Master/Worker is another method for distributing work. In this method,
a master will provide work to a collection of workers that will complete the
tasks and return the results to the master. This parallels a task queue, except
that it offers the additional control, and cost, of the master that generates
and manages the tasks [14]. Case management, especially in scenarios where
there is a case owner, also follows a similar implementation pattern.
The final analyzed pattern is the actor pattern which will be discussed
in greater detail in Chapter 5
34
Chapter 5
Actor Model
As parallel programming, and software development in general, has become
more distributed, there has been a need to develop methods for handling
parallelism. Once such method is implementing through actors. Originally
proposed by Hewitt in 1973 [10], the actor model defines a set of objects
that are self-contained, that communicate via message passing, and that are
concurrently executing [2].
This section is a high-level review of the actor methodology because the
proof-of-concept application created as part of this dissertation is written
using the Akka framework, a SCALA and Java-based actor framework. After
the high-level review of the methodology, this section will also introduce Akka
and its implementation of the actor methodology.
5.1 Key Principles of Actor Design
As with any methodology, there are a several fundamental elements and
principles for implementing actors [2]. These include:
•Actors are stand alone objects in the system that cannot be operated
on or investigated directly.
•Actors communicate using messages that request an operation
•Actors can send many messages simultaneously but will receive only
one at a time.
35
This means that actors offer a form of procedure that can be invoked only
through receiving a message [2]. This message allows for parallel execution
within the system and offers the actors a degree of flexibility in completing
the task requested. Actors can complete the work, forward the work to other
actors in the system, or even create new actors to complete the work1.
5.2 Mapping Actors to Workflow
In 2005, Van der Aalst described workers in case management as actors [32],
inviting the comparison between actors and workers. Workflow system users
and actors are both capable of completing specified types of tasks and can
both act on distributed systems. Workers in a workflow management system
also receive instructions to complete tasks and can operate in parallel with
other workers. In fact, the list of fundamental elements for actors in the
previous section can be applied to human workers as well:
•Workers are stand alone.
•Workers communicate using requests, tasks in workflow processing.
•Workers can send multiple messages, but can typically work on only
one task at a time.
•Workers can complete the task assigned or reassign it to others in their
organization.
Workflow systems also have mechanisms to invoke automatic systems as a
task in a workflow. There are various implementations, but in an actor-based
implementation, these automatic tasks would be completed by actors.
5.3 Akka
Actors are important in the context of this paper because the proof-of-
concept implementation of a dynamic case management system to use in
parallel programming or data processing contexts was built using the Akka
framework. Akka is a SCALA-based implementation of the actor model and
offers Java-based bindings.
1https://doc.akka.io/docs/akka/current/guide/actors-intro.html
36
While the Akka framework offers a number of features, the following were
key reasons for selecting it in this implementation:[9]
•Concurrency: Akka Actor Model abstracts the concurrency handling
and allows the programmer to focus on the business logic.
•Scalability: Akka Actor Model’s asynchronous message passing allows
applications to scale up on multicore servers.
•Fault tolerance: Akka borrows the concepts and techniques from
Erlang to build a ”Let It Crash” fault-tolerance model using supervisor
hierarchies to allow applications to fail fast and recover from the failure
as soon as possible.
•Event-driven architecture: Asynchronous messaging makes Akka a
perfect platform for building event-driven architectures.
•Location transparency: Akka treats remote and local process actors
the same, providing a unified programming model for multicore and
distributed computing needs.
•Scala/Java APIs: Akka supports both Java and Scala APIs for build-
ing applications.
37
Chapter 6
Implementing Dynamic Case
Management with Actors
In order to begin bridging the gap and to lay a foundation for further research,
a basic dynamic case management system was created using an actor-based
framework called Dynamic Case Management with Actors (DCMwA). The
implementation is a Java-based implementation of an ACM solution using
the Akka1framework. Implementing with Akka was based on the following:
it is a Java-based implementation of the actor model and it is common in
parallel and high-performance computing. For data storage, the Not Only
SQL (NoSQL) database MongoDB2[22] was used. Again, MongoDB was
selected because it has strong support for Java and is commonly used in
data analytics and big data applications.
This chapter describes the process of implementing DCMwA, the Data
Serialization Engine (DSE), and the architecture of the resulting frameworks.
The chapter is divided into the following sections:
•Section 6.1 describes the goals for the implementation.
•Section 6.2 describes the implementation methodology used.
•Section 6.3 describes the architecture of the implementation.
•Section 6.4 describes the actor implementation.
1Akka documentation and information available at http://akka.io/docs/
2MongoDB documentation and information available at https://www.mongodb.com/
38
•Section 6.5 briefly describes the DSE and its connection with Mon-
goDB.
6.1 Goals
When implementing DCMwA there were a number of key goals defined for
the framework to accomplish. They were as follows:
First, DCMwA was to be based on the GSM methodology outlined by Hull
[12]. This implementation would allow for experimenting with, and gaining
a better understanding of, GSM in a practical form. This is opposed to using
a Commercial off-the shelf (COTS) product, such as ICM, as these products
may have specific unmentioned assumptions or approaches to implementing
ACM and GSM that may not readily be apparent.
Second was to experiment with and utilize a parallel programming frame-
work or technique. Akka was recommended as it was a well-known imple-
mentation of the actor framework described in chapter 5. Another reason for
using Akka is it would allow for implementing automatic or non-human tasks
more easily. An additional goal was to determine if ACM and the techniques
it offers can be utilized or can enhance data processing and parallel pro-
gramming solutions. Using an existing parallel processing framework would
simplify invoking already built actors.
Third, the DCMwA implementation was to use a data storage and persis-
tence mechanism common in big data analysis and data processing applica-
tions. While many COTS solutions utilize traditional relational databases for
data persistence, NoSQL-based databases are rising in popularity in big data
applications. In addition to the commonality, building on top of a NoSQL
database allowed for experimenting with using the flexible data model as
opposed to the traditional relational model of other implementations, such
as ICM.
Finally, the implementation was to create one or more sample case plans
that could demonstrate parallelism. It was important to demonstrate that
two, or more, tasks could be executed simultaneously ensuring that the exit
guard could trigger after the two tasks had been completed. This would
demonstrate a form of synchronization that is seen in both workflow and
parallel programming.
39
6.2 Implementation Methodology
This section will describe the implementation methodology and will also
briefly describe the history of the implementation drawn from the Git commit
logs for the project.
DCMwA was implemented using an iterative implementation methodol-
ogy. This methodology allowed the most flexibility developing the imple-
mentation as some of the time spent coding was also spent researching and
understanding the GSM methodology.
Implementation began with the core design and planning classes that
allowed for the creation of an example case plan. The plan was heavily reliant
on GSM and CMMN, so implementation began with the high-level objects
defined by each: case,task,stage,milestone and guard. After that,
planning classes were created that would be used to define the names, entry
and exit criteria and relationships between the items. These relationships
will be described further in section 6.3
The next step was to build the data serialization engine framework and
create an initial serialization implementation using JavaScript Object Nota-
tion (JSON). This used Google Gson3as the JSON serialization and deserial-
ization library. This library allowed for iterative refinement the serialization
framework. The Gson library and its source code was also key in developing
a deeper understanding of Java’s reflection capabilities and how they can be
used to get and set class properties. A brief description of the serialization
framework will be in section 6.5.
With the serialization framework prototyped, additional elements of the
execution module were built, including the GSM and CMMN objects de-
scribed above. This also marked the beginning of the implementation of the
actors and experimenting with the Akka framework.
After starting the Akka implementation, guards and condition checking
were implemented. This resulted in the final core component necessary to
implement and test a full ACM solution.
The rest of the development process was concerned with completing the
development, testing a solution and ensuring all modules were functional.
3Google Gson details available at https://github.com/google/gson
40
6.3 Architecture
As described in the goals section of this chapter, the solution is based on the
GSM model [13] with additional input coming from CMMN [24]. The im-
plementation is divided into six distinct modules that are responsible for the
designing, executing, persisting, guard evaluation, and task execution. The
complete list of modules is contained in Table 6.1 and Table 6.2. Table 6.3
lists the third party modules used in the implementation. Figure 6.1 shows
how the modules related to each other.
Module Description
dcm.core Core enumerations and data storage classes
dcm.planning Planning and design classes used for creating the case type
or case folder prototype
dcm.guards An implementation of the guards, conditions and sentries
used in executing a case
dcm.executor The execution data model used for executing a case
dcm.engines A collection of concrete engine classes for handling persis-
tence, locking and task execution
dcm.actors The implementation of the Akka AbstractActor
Table 6.1: DCM Implementation Modules
Module Description
dse An abstract data serialization module allowing for data to be
serialized to abstract tree/node-based storage format, such as
JSON or XML.
dse.gson A Gson implementation for the data serialization engine that
allows storing data as JSON on the file system. This module
does not currently implement searching, so is incomplete and
was used initially for developing the dse.
dse.mongo A MongoDB implementation for the data serialization engine
that allows storing data into a MongoDB collection
Table 6.2: DSE Implementation Modules
41
Module Description
Akka Akka is the Java-based actor implementation framework used
in DCMwA
Gson Gson is a JSON serialization and deserialization framework
created by Google
MongoDB MongoDB is the data persistence and lookup solution used
by the implementation
Table 6.3: Third Party Modules
The remaining sections in this chapter will describe in greater depth each
of the DCMwA custom modules, with the exception of the Akka actor im-
plementation described in section 6.4. A description of the data serialization
engine will be included in section 6.5.
dcm.actorsdcm.core
dcm.engines
dcm.executor
dcm.guards
dcm.planningdse
dse.mongo
AkkaMongoDB
Figure 6.1: Module Relationship
6.3.1 Core
Of the modules, the core module is the smallest. This module is shared li-
brary that contains any classes that are shared across the whole of the project.
As such, it does contain several enumerations and the implementations of the
DateValue and TimeValue classes
DateValue and TimeValue were created to represent a specific time or
a specific date that would be independent of timezone. The Date property
type uses a traditional Java Date, stored as the number of milliseconds before
or after epoch. However, in implementing IBM Case Manager for customers,
42
the author consistently received requests for a date or time value that would
remain constant regardless of timezone. For example, they would want to
store the date of a transaction and not have that date shift based on timezone
where the system is being accessed. In ICM, the only way to store this type
of value was as a string because the date property is a Java date object.
While this was acceptable for display purposes, it did not allow for sorting,
localization, or range selection.
Figure 6.2: dcm.core
6.3.2 Planning Data Model (dcm.planning)
In the same way an implementation of a WfMS would provide for both de-
signing process and managing a case, a ACM implementation will also need
to implement both. This section describes the case planning classes listed in
Table 6.4. For class diagrams of the dcm.planning module, see Figure 6.3
and Figure 6.7.
As this section describes the classes used when creating a case plan, each
of the key items will include an example of how to represent that item in
43
CMMN.4
Class Description
CasePlan Represents the design of a case plan, including
any elements defined below.
MilestonePlan The definition of a milestone.
StagePlan The definition of a stage.
TaskPlan The execution rules for a given task.
PropertyDefinition<T>The definitions of properties that can be used
to store case data.
Condition An interface that any condition can implement.
Table 6.4: Key planning classes for DCMwA
Figure 6.3: dcm.planning class model
4All the graphics in this section were generated with the CMMN toolkit offered at
https://bpmn.io/toolkit/cmmn-js/
44
Case Plan
Class: dcm.planning.CasePlan
A case plan represents the design of a case to be executed. This plan
can contain a number of sub-elements, including milestones, stages, property
definitions, case-specific tasks and exit criteria. A case plan is persisted as a
single, monolithic object, including all stage, milestone, and task plans.
Item Quantity
Milestone [1:n]
Stage [1:n]
Property [1:n]
Task [0:n]
Guard [1:n]
Table 6.5: Case plan object relationships
Figure 6.4: An empty case folder in CMMN
Stage Plan
Class: dcm.planning.StagePlan
A stage plan is a way of combining together tasks and case files into a
logical group. They are similar to sub-processes in workflows [16].
A stage plan can contain the following:
45
Item Quantity
Task [0:n]
Entry Criteria [1:n]
Exit Criteria [1:n]
Table 6.6: Stage plan object relationships
Figure 6.5 shows the the two main types of stages: standard and discre-
tionary. It also shows a stage with entry and exit criteria. While CMMN
defines both discretionary and normal stages, the DCMwA implementation
currently only supports standard stages.
Figure 6.5: Stages in CMMN (left to right: standard, discretionary, and a
stage with entry and exit conditions)
Milestone Plan
Class: dcm.planning.MilestonePlan
A milestone represents an accomplishment that is achieved during the
execution of a case instance. They are used to track progress of that case
instance [16]. In DCMwA, a milestone can contain the following:
Item Quantity
Condition [1:n]
Table 6.7: Milestone plan object relationships
Figure 6.6 shows how a milestone is represented in CMMN. The figure
shows a standard milestone as well as required and repeatable milestones.
DCMwA currently only supports milestones without rules.
46
Figure 6.6: Milestones in CMMN (left to right: standard, repeating, and
required)
Property Definitions
As a case can contain properties, the framework also defines a number of
property types. A property definition defines the following criteria:
Property Description
Property name a unique name to use when accessing the property and
its values. This is similar to a variable name in program-
ming.
Data type the type of value that the property will store. Data types
are listed in Table 6.9.
Cardinality the number of values that the property will store. Car-
dinalities are listed in Table 6.10.
Table 6.8: Properties of a property definition
Type Description Java Class
String Collection of characters java.lang.String
Long 64-bit signed integer java.lang.Long
Double double-precision floating point java.lang.Double
Date Year/Month/Day as defined by the
Gregorian calendar
dcm.types.DateValue
Time Hour/Minute/Second in 24-hour
time not adjusted for timezone
dcm.types.TimeValue
Timestamp Milliseconds since epoch 1/1/1970
00:00:00 UTC
java.util.Date
Table 6.9: DCM Data Types
47
Type Description
Single Value A single, discrete value
Array An array of values
Table 6.10: DCM Property Cardinalities
Figure 6.7: dcm.planning.properties class model
The current property definition implementation is designed for future en-
hancements. Specifically, they do not support data-type specific limitations
such as allowable value ranges and string length limitations. Future imple-
mentations could implement additional parent classes for numeric data types
that would allow for defining the ranges. See Figure 6.8 for an example of
one of the planned future enhancements.
Figure 6.8: Example of future property definition enhancements.
Guards and Conditions
Interface: dcm.planning.conditions.Condition
Conditions are defined in the design module. There is a base Condition
interface that all other elements implement. Each stage, milestone and case
48
has only one guard for entry or exit. However, to accommodate multiple
exit conditions, a CompoundCondition exists which allows for combining
several conditions with either an AND or OR conditional.
Current guards implemented are:
Object Name Description
Case Case Started Triggered when a case is started
Milestone Milestone Reached Triggered when a milestone is
reached
Property
String is null, is not null, ==, !=, starts
with, ends with, contains
Boolean is null, is not null, ==, !=
Date
is null, is not null, ==, !=, >,
>=, <,<=
Double
Long
Time
Timestamp
Stage Stage Started Triggered when a stage starts
Stage Completed Triggered when a stage has com-
pleted
Tasks
Required tasks completed Triggered when all required case-
level or stage-level tasks have
been completed
Stage tasks completed Triggered when all tasks in a
given stage have completed
Task completed Triggered when a specific task has
been completed
Table 6.11: Currently implemented conditions
This is not a comprehensive set of conditions, but one that can be ex-
tended as necessary.
Task Plan
Class: dcm.planning.TaskPlan
A task plan defines a task that can be completed as part of the execution
of a case. CMMN defines four types of tasks: human,case,decision, and
49
process. For this implementation, a task execution framework was created
that will allow the designer to specific which task class to execute and any
instructions. This will allow for executing any arbitrary class instead of being
restricted to the CMMN types.
CMMN defines four decorators for the defined task types above. Fig-
ure 6.9 shows the four basic task types. In addition to the types, it includes
three optional decorators to define manually started, repeatable and required
tasks. Figure 6.10 shows the three optional decorators.
Figure 6.9: Task types in CMMN (left-to-right: human non-blocking, human
blocking, case, decision and process)
Figure 6.10: Task rule decorators in CMMN (manual, repetition and re-
quired)
6.3.3 Executor (dcm.executor)
The executor module contains the classes for executing a case plan as a case
and a collection of stages, tasks, milestones and conditions. Each of the items
are created from their corresponding plan objects and persisted individually
in the repository.
50
Figure 6.11: dcm.executor
For every planning class, there is a corresponding executor class.
Case
Class dcm.executor.Case
This case represents an in-process version of a CasePlan. It stores the
case folder property values and tracks the current case stage and the case
state.
Task
Class dcm.executor.Task
A task object represents an in-process task, a task that is ready to start,
or a task that has been completed. As with a Case it also stores the task-level
properties and contains a reference to the executor class and its configuration.
Stage
Class dcm.executor.Stage
51
A stage object represents a stage that is either ready to be activated, is
currently activated, or can be activated in the future. It also tracks its state
and provides a reference for any stage-specific tasks.
Milestone
Class dcm.executor.Milestone
A milestone object represents a milestone that either has been reached
or can be reached. It also tracks its state.
6.3.4 Engine (dcm.engines)
The engine module contains two data management engines: data persistence
and lock management.
Figure 6.12: dcm.engines
Persistence
Class dcm.engine.persistence.PersistenceEngine
52
The persistence module uses the data serialization engine described in
Section 6.5. It is responsible for Create, Retrieve, Update, and Delete
(CRUD) operations on case planning and execution objects. As mentioned
before, case objects are stored separately and cross-referenced by ids.
Locking
Class dcm.engine.locking.LockingEngine
In order to facilitate parallelism and ensure that case objects were not
overwritten, avoiding the lost update problem, the locking engine creates and
validates locks on individual objects. The locking mechanism is currently lim-
ited, only supporting write locks. It also does not currently support deadlock
checking via wait for graphs or any other mechanisms. These are items that
should be added as the framework matures.
6.4 Actor Framework
Built on top of the planning, execution, and guard management modules is
the actor module. This module contains the Akka-specific implementation
classes. Figure 6.13 provides a Unified Modeling Language (UML) class di-
agram. These classes implement four distinct actors: persistence (storage),
locking (locks), task execution (taskExec) and guard evaluation. Each actor
sends and receives a predefined set of messages which are also defined in
this module. The following sections will briefly describe the actors and Sec-
tion 6.4.5 will describe how they interact, including example UML sequence
diagrams.
53
Figure 6.13: dcm.actors
6.4.1 Persistence
Class: dcm.actors.persistence.PersistenceActor
Role: Perform create, store, and retrieve objects from the repository
This module interacts with the dcm.engines persistence engine and ul-
timately with the DSE. It receives messages for creating, retrieving, and per-
sisting objects in the repository. Only cases and case plans can be created,
though a future implementation should allow for creating discretionary and
repeating tasks and stages. The persistence engine also has an additional,
composite object that can represent a complete, current case record. This
case record includes all currently instantiated items, regardless of state that
can be used for condition evaluation. This reduces the need for round-trips
to collect the items necessary to evaluate conditions.
The actor accepts a number of messages for creating, retrieving, and
persisting the following items: case plans, cases, milestones, tasks, and stages.
Each request has a corresponding response. Figures 6.14 and 6.15 show the
complete messages in UML class diagrams.
54
Figure 6.14: Persistence actor request messages
Figure 6.15: Persistence actor response messages
6.4.2 Locking
Class: dcm.actors.locks.LockActor
Role: Manages creating, releasing, and validating locks on objects.
55
This module interacts with the locking engine and provides the ability
to acquire, validate and release one or more locks. The actor utilizes the
LockEngine from section 6.3.4, requesting the engine create, release, and
validate locks. The actor also communicates with a set of three request and
response messages that request the acquisition, validation, and retrieval of
locks. Figure 6.16 shows the request and response messages.
Figure 6.16: Lock actor message requests and responses.
6.4.3 Task Executor
Class: dcm.actors.task.TaskExecutorActor
Role: Launches and manages in progress tasks.
This module is responsible for launching and managing tasks. Each task
in a case has an executor class and a set of instructions encoded. The TaskEx-
ecutorActor will create an instance of the executor class and provide it the
task information and the encoded instructions. It will then launch the task
executor class by calling its launch() method.
56
Figure 6.17: Task messages
Figure 6.18: Sample task executors
6.4.4 Guard
This module will evaluate the conditions for a case, tasks, stages and mile-
stones. It performs the checks and will continually check until no more
changes are detected. This allows, for example, a stage to reach its exit
condition and then trigger an entry condition for another stage.
57
6.4.5 Interaction
The actors in the system interact with one another in order to complete the
execution of a case or the completion of an operation or set of operations. The
UML sequence diagrams in Figure 6.19 and Figure 6.20 show the interaction
between the key actors and subsystems. Specifically, the diagrams show the
steps in creating a case and a retrieve/update sequence.
Persistance Guards Locks Task
Execu on
User App
Retrieve Case Plan
CasePlan
Create Case from CasePlan
Evaluate Guards
Case Changes
Request Lock(s)
Return Locks
Start Task
Return Task Start Response
Return Case instance
Evaluate Locks
Lock Validity Response
Ini al Case Crea on Sequence
Release Locks
Locks Released
Figure 6.19: Case Creation Sequence
58
Persistance Guards Locks Task
Execu on
User App
Retrieve Case
Case
Persist Changes to Case
Evaluate Guards
Case Changes
Request Lock(s)
Return Locks
Start Task
Return Task Start Response
Return Case instance
Evaluate Lock(s)
Lock Validity Response
Case Update Sequence
Release Locks
Locks Released
Acquire Case Lock
Figure 6.20: Case Update Sequence
6.5 Serialization Framework
One major aspect of the DCMwA implementation is the generic DSE frame-
work that was created. The initial implementation was written to JSON and
serialized to disk, but that would not scale and did not meet the goal of using
MongoDB. As a result, a generic data serialization framework was created.
The design was based loosely on several JSON parsing libraries, such as Gson
or JSON4J. In these libraries, the object is created and children are added
as primitive values, arrays or maps.
The DSE follows this method by creating a set of interfaces, such as
SerializedValue,SerializedObject and SerializedArray. The framework also
provides an interface for defining a serialization engine, defining a serializable
object and a value serializer. These interfaces are briefly described in Section
6.5.1. Section 6.5.2 describes the two concrete implementations.
59
Figure 6.21: Data serialization engine core classes and interfaces
6.5.1 Value Serialization
Value serialization is accomplished by implementing interfaces that are di-
vided into three main modules: dse,dse.search, and dse.values. The
values module defines the key value types that can be serialized, which in-
clude arrays, values (primitives) and objects. Objects are similar to a JSON
map of string-based keys and arbitrary values. See Figure 6.23 for a class
diagram.
By default, the framework will use Java reflection to determine the prop-
erties of the objects being serialized and will attempt to create a Serialize-
dObject with a set of corresponding key-value pairs. Arrays are serialized
as instances of SerializedArray.
For classes that cannot be easily serialized using standard introspection,
the framework offers a ValueSerializer interface. The class being serialized
can offer an implementation of this interface that is capable of serializing and
deserializing the object. This is useful for instances where a property of a
class is defined as an interface, such as the CasePlan object that contains
a map of String-PropertyDefinition<T>interfaces. Without the Property-
Serializer, shown in part in Figure 6.22, deserialization would fail because
the default deserializer would not know which concrete class to use. Instead
the PropertySerializer will be able to use the data type and cardinality
60
values to determine the appropriate class to instantiate.
Figure 6.22: The PropertyDefinition-specific implementation of ValueSerial-
izer
61
Figure 6.23: Data serialization engine value type interfaces
6.5.2 Implementations
The DCMwA implementation has two DSE implementations: one Google
Gson-bsaed and another MongoDB-based. The Gson implementation is cur-
rently missing searching capabilities that were added after a remodel of the
dcm.executor module. Regardless, each connector implements the core in-
terfaces and allows for transparent serialization and deserialization of objects
to their respective forms.
62
Figure 6.24: Case data serialized into MongoDB
63
Chapter 7
Evaluation and Conclusions
Having reviewed workflow management, case management, combined pat-
terns, and the DCMwA implementation, this chapter will:
•Evaluate the project against the goals, identifying areas of success, and
future enhancement.
•Identify additional areas of future research.
•State the conclusions from the research.
7.1 Project Evaluation
As the framework was written completely from the ground up, it was evalu-
ated on the following criteria, as defined in section 6.1:
•Was it successful in completing the sample case solution following
GSM?
•Was it possible to build a case management solution using Akka and
MongoDB?
•Did it demonstrate parallelism, including object locking?
With the framework complete, a case solution similar to the following
was constructed and tested:
64
Figure 7.1: Alert Review CMMN Diagram
The testing involved both launching and completing the case, but launch-
ing multiple instances of the case simultaneously. The result was the frame-
work was able to successfully run many instances of the case through to
completion. No timings were taken, however, so a performance review was
not possible. This was due to several factors including:
•Part of the solution was to represent a human-centric review step. This
may take time and was represented as a random time delay in complet-
ing this task (Review Transaction)
•Each of the automatic tasks also included a random time delay element.
One of the key features to demonstrate was that asynchronous task
completion was possible, meaning that a task could be passed of to
an actor and then the actor could return its result at an arbitrary,
future point. This, again, was represented by the actor spawning a
thread with the arbitrary delay, using Thread.sleep(Random()) to
represent a delay.
65
Figure 7.2: DCMwA execution output with the cases correlated.
•The initial stage of the solution included two separate tasks. These
were launched at the start of the stage and were to run in parallel. This
was successful and the locking implemented was effective in ensuring
synchronous data access.
The framework was able to demonstrate parallel task execution with the
example code starting four cases simultaneously. Each case would then trig-
ger two evaluation tasks that could execute in parallel and update their
respective cases in a thread-safe manner. Figure 7.2 show an example out-
put with four cases being created and all four cases are being executed in
parallel.
Perhaps the most important criteria for judging the framework as a suc-
cess is in its future use. As the intersection of ACM, workflow management,
parallel programming, and data processing appears to hold promise, this
framework will allow for future development and research.
Despite the success, there are some issues with the framework as it is
currently implemented. These include the following:
There is an issue with how the actors pass messages. Specifically, actors
within Akka should pass read-only messages between themselves1. While the
majority of the inter-actor communication with this solution can be consid-
ered read only, the tasks and case objects are currently passed to the requester
1https://doc.akka.io/docs/akka/current/actors.html#messages-and-immutability
66
and allowed to be modified. This breaks the spirit of the actor model and
should be refactored to pass only the requested changes back. This could
allow for a looser locking mechanism than is currently implemented by al-
lowing a client to request changes be made and the engine itself determine
if the changes can apply and if so, persist them or pass back a “needs lock”
response and could result in greater performance.
The case data model needs to be expanded to include greater file object
and maybe broader data structures. A more broadly applicable model would
allow for access to tables of data or more abstract data types than the Date /
Time / Timestamp / Long / Double / String / Boolean data types currently
implemented.
7.2 Additional Areas of Research
One of the goals of this paper was to compare two processing methodologies,
workflow management and case management, through the lens of parallel
processing. This came from the recognition that ACM is a data-centric form
of process management and that workflow management is a form of parallel
task execution and processing.
With the comparison complete, the the following questions have ap-
peared:
•Are there capabilities and principles learned from BPM and workflow
management that can apply to parallel processing?
•Are the patterns and lessons learned in implementing parallel applica-
tions, specifically handling synchronization, relevant for workflow man-
agement?
•Can the data-centric nature of ACM be applied to data processing
scenarios?
•Are there places in data processing that having the ability to invoke or
include a human participant beneficial?
This paper has not answered these questions, but the DCMwA framework
can provide a starting point. It needs refinement and additional functionality,
but future research can build upon the foundation created.
67
Another area that should be researched is how skeletons can influence
and contribute to the union of the above technologies. Skeletons are a set of
parallel programming patterns and implementation frameworks that can help
a developer more rapidly implement a solution. Workflow management and
ACM frameworks and platforms also provide implementers with a platform
to build solutions. Perhaps some of the elements of skeletons can be merged
with a DCMwA or similar frameworks.
This paper did not review scientific workflow systems. A survey of cur-
rently available systems and the literature surrounding them should be con-
ducted to determine what they can offer.
7.3 Conclusions
With the development of solid workflow management patterns and the emer-
gence of advanced case management as a new data-centric methodology for
managing processes, the options for achieving a business goal are wider than
ever. They range from traditional workflow systems for straight-through,
repetitive processing to ACM for more knowledge intensive processes.
One key insight into workflow systems comes from Michael zur Muehlen’s
book Workflow-based Process Controlling. Foundation, Design, and Applica-
tion of Workflow-driven Process Information Systems. Specifically, he states:
[T]he aim of workflow management technology is the sepa-
ration of process logic from application logic in order to enable
flexible and highly configurable applications. [38]
The separation of the control from the application logic provides power
and flexibility. The underlying technology can handle providing work to the
resources and can execute the rules involved while the resources themselves
can complete the task provided.
Given that workflow can be viewed as a form of parallel task execution,
there is a strong possibility of advancements and alternate ways to approach
solving computing challenges.
68
List of Tables
4.1 Key Concepts and Definition . . . . . . . . . . . . . . . . . . . 24
4.2 Flynn’sTaxonomy ........................ 25
6.1 DCM Implementation Modules . . . . . . . . . . . . . . . . . 41
6.2 DSE Implementation Modules . . . . . . . . . . . . . . . . . . 41
6.3 Third Party Modules . . . . . . . . . . . . . . . . . . . . . . . 42
6.4 Key planning classes for DCMwA . . . . . . . . . . . . . . . . 44
6.5 Case plan object relationships . . . . . . . . . . . . . . . . . . 45
6.6 Stage plan object relationships . . . . . . . . . . . . . . . . . . 46
6.7 Milestone plan object relationships . . . . . . . . . . . . . . . 46
6.8 Properties of a property definition . . . . . . . . . . . . . . . . 47
6.9 DCMDataTypes......................... 47
6.10 DCM Property Cardinalities . . . . . . . . . . . . . . . . . . . 48
6.11 Currently implemented conditions . . . . . . . . . . . . . . . . 49
69
List of Figures
2.1 A BPMN activity diagram describing a business process . . . 9
2.2 Sequential and Parallel Tasks in BPMN . . . . . . . . . . . . . 11
2.3 WfMC Generic Structure [11] . . . . . . . . . . . . . . . . . . 13
2.4 The ICF Process Designer process definition tool. . . . . . . . 14
2.5 The jBPM process definition tool. . . . . . . . . . . . . . . . . 15
2.6 IBM Case Foundation worklist in ICN . . . . . . . . . . . . . 16
2.7 A work handler in ICN . . . . . . . . . . . . . . . . . . . . . . 16
2.8 jBPM Architecture . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 IBM FileNet Architecture . . . . . . . . . . . . . . . . . . . . 19
4.1 Parallel Split in BPMN . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Multiple Instance in BPMN . . . . . . . . . . . . . . . . . . . 26
4.3 Parallel merge in BPMN . . . . . . . . . . . . . . . . . . . . . 28
4.4 IBM Case Manager case details view with case files on the left
and case folder data on the right. . . . . . . . . . . . . . . . . 32
4.5 Defining conditions for a route in jBPM. . . . . . . . . . . . . 33
6.1 Module Relationship . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 dcm.core.............................. 43
6.3 dcm.planning class model . . . . . . . . . . . . . . . . . . . . 44
6.4 An empty case folder in CMMN . . . . . . . . . . . . . . . . . 45
6.5 Stages in CMMN (left to right: standard, discretionary, and
a stage with entry and exit conditions) . . . . . . . . . . . . . 46
6.6 Milestones in CMMN (left to right: standard, repeating, and
required).............................. 47
6.7 dcm.planning.properties class model . . . . . . . . . . . . . . . 48
6.8 Example of future property definition enhancements. . . . . . 48
6.9 Task types in CMMN (left-to-right: human non-blocking, hu-
man blocking, case, decision and process) . . . . . . . . . . . . 50
70
6.10 Task rule decorators in CMMN (manual, repetition and re-
quired)............................... 50
6.11dcm.executor ........................... 51
6.12dcm.engines ............................ 52
6.13dcm.actors............................. 54
6.14 Persistence actor request messages . . . . . . . . . . . . . . . . 55
6.15 Persistence actor response messages . . . . . . . . . . . . . . . 55
6.16 Lock actor message requests and responses. . . . . . . . . . . . 56
6.17Taskmessages........................... 57
6.18 Sample task executors . . . . . . . . . . . . . . . . . . . . . . 57
6.19 Case Creation Sequence . . . . . . . . . . . . . . . . . . . . . 58
6.20 Case Update Sequence . . . . . . . . . . . . . . . . . . . . . . 59
6.21 Data serialization engine core classes and interfaces . . . . . . 60
6.22 The PropertyDefinition-specific implementation of ValueSeri-
alizer................................ 61
6.23 Data serialization engine value type interfaces . . . . . . . . . 62
6.24 Case data serialized into MongoDB . . . . . . . . . . . . . . . 63
7.1 Alert Review CMMN Diagram . . . . . . . . . . . . . . . . . . 65
7.2 DCMwA execution output with the cases correlated. . . . . . 66
71
Acronyms
ACM Advanced Case Management. 4, 5, 20–22, 24, 27–31, 33, 38–40, 43,
66–68
BPM Business Process Management. 4, 7, 8, 67
BPMN Business Process Modeling Notation. 9, 11, 14, 28, 70
CMMN Case Manager Modeling Notation. 5, 20–22, 30, 31, 40, 41, 44–47,
49, 50, 65, 70, 71
COTS Commercial off-the shelf. 39
CRUD Create, Retrieve, Update, and Delete. 53
DCM Dynamic Case Management. 20
DCMwA Dynamic Case Management with Actors. 38–40, 42, 44, 46, 59,
62, 64, 66–69, 71
DSE Data Serialization Engine. 38, 39, 41, 54, 59, 62, 69
ECM Enterprise Content Management. 5
GSM Guard-Stage-Milestone. 20, 39–41, 64
ICF IBM Case Foundation. 5, 13–15, 17, 70
ICM IBM Case Manager. 5, 21, 22, 31, 39, 43
ICN IBM Content Navigator. 15, 16, 70
72
JSON JavaScript Object Notation. 40–42, 59, 60
MPMD Multiple Program Multiple Data. 25
NoSQL Not Only SQL. 38, 39
OMG The Object Management Group. 5, 9, 21
SIMD Single Instruction Multiple Data. 25
SPMD Single Program Multiple Data. 25, 26
UML Unified Modeling Language. 53, 54, 58
WfMC Workflow Management Coalition. 7, 12, 13, 70
WfMS Workflow Management System. 22, 43
XML eXtensible Markup Language. 41
73
Bibliography
[1] Wil MP van der Aalst and PJS Berens. “Beyond workflow manage-
ment: product-driven case handling”. In: Proceedings of the 2001 In-
ternational ACM SIGGROUP Conference on Supporting Group Work.
ACM, 2001, pp. 42–51.
[2] Gul A Agha et al. “A foundation for actor computation”. In: Journal
of Functional Programming 7.1 (1997), pp. 1–72.
[3] Marco Aldinucci and Marco Danelutto. “Skeleton-based parallel pro-
gramming: Functional and parallel semantics in a single shot”. In: Com-
puter Languages, Systems & Structures 33.3-4 (2007), pp. 179–192.
[4] Christopher Alexander. A pattern language: towns, buildings, construc-
tion. Oxford university press, 1977.
[5] Thomas H Davenport and Nitin Nohria. “Case management and the
integration of labor”. In: MIT Sloan Management Review 35.2 (1994).
[6] Claudio Di Ciccio, Andrea Marrella, and Alessandro Russo. “Knowledge-
intensive processes: characteristics, requirements and analysis of con-
temporary approaches”. In: Journal on Data Semantics 4.1 (2015),
pp. 29–57.
[7] Michael J Flynn. “Some computer organizations and their effective-
ness”. In: IEEE transactions on computers 100.9 (1972), pp. 948–960.
[8] Diimitrios Georgakopoulos, Mark Hornick, and Amit Sheth. “An overview
of workflow management: From process modeling to workflow automa-
tion infrastructure”. In: Distributed and parallel Databases 3.2 (1995),
pp. 119–153.
[9] Munish Gupta. Akka essentials. Packt Publishing Ltd, 2012.
74
[10] Carl Hewitt, Peter Bishop, and Richard Steiger. “Session 8 formalisms
for artificial intelligence a universal modular actor formalism for artifi-
cial intelligence”. In: Advance Papers of the Conference. Vol. 3. Stan-
ford Research Institute, 1973, p. 235.
[11] David Hollingsworth and UK Hampshire. “Workflow management coali-
tion: The workflow reference model”. In: Document Number TC00-1003
19 (1995).
[12] Richard Hull et al. “Introducing the guard-stage-milestone approach
for specifying business entity lifecycles”. In: International Workshop
on Web Services and Formal Methods. Springer, 2010, pp. 1–24.
[13] Richard Hull et al. “Business artifacts with guard-stage-milestone life-
cycles: managing artifact interactions with conditions and events”. In:
Proceedings of the 5th ACM international conference on Distributed
event-based system. ACM, 2011, pp. 51–62.
[14] Kurt Keutzer and Tim Mattson. “Our Pattern Language (OPL): A
design pattern language for engineering (parallel) software”. In: Para-
PLoP Workshop on Parallel Programming Patterns. Vol. 14. 2009.
[15] Kurt Keutzer et al. “A Design Pattern Language for Engineering (Par-
allel) Software: Merging the PLPP and OPL Projects”. In: Proceed-
ings of the 2010 Workshop on Parallel Programming Patterns. Para-
PLoP ’10. event-place: Carefree, Arizona, USA. New York, NY, USA:
ACM, 2010, 9:1–9:8. isbn: 978-1-4503-0127-5. doi:10.1145/1953611.
1953620.url:http://doi.acm.org/10.1145/1953611.1953620.
[16] Mike A Marin. “Introduction to the case management model and no-
tation (CMMN)”. In: arXiv preprint arXiv:1608.05011 (2016).
[17] Mike A Marin. “Exploring complexity metrics for artifact-centric busi-
ness process models”. PhD Thesis. 2017.
[18] Mike A. Marin and Matheus Hauder. “Case Management: a data set
of definitions”. In: CoRR abs/1507.04004 (2015). url:http://arxiv.
org/abs/1507.04004 (visited on 06/11/2019).
[19] Mike A. Marin and Matheus Hauder. “Case Management: a data set
of definitions”. In: CoRR abs/1507.04004 (2015). url:http://arxiv.
org/abs/1507.04004 (visited on 06/11/2019).
75
[20] Mike A Marin, Matheus Hauder, and Florian Matthes. “Case man-
agement: an evaluation of existing approaches for knowledge-intensive
processes”. In: International Conference on Business Process Manage-
ment. Springer, 2016, pp. 5–16.
[21] Berna L Massingill, Timothy G Mattson, Beverly A Sanders, et al.
“Patterns for parallel application programs”. In: Proc. of the 6th Pat-
tern Lang. of Prog.(PLoP 99) (1999).
[22] Inc. MongoDB. MongoDB Documentation.url:https://docs.mongodb.
com/manual/.
[23] Object Management Group. Business Process Modeling Notation. Jan.
2014. (Visited on 06/17/2019).
[24] Object Management Group. Case Management Model and Notation.
Dec. 2016. (Visited on 06/17/2019).
[25] Carl Adam Petri. “Kommunikation mit automaten”. PhD thesis. 1962.
[26] Nicholas Charles Russell. “Foundations of process-aware information
systems”. PhD Thesis. Queensland University of Technology, 2007.
[27] Nick Russell, Wil Van Der Aalst, and Arthur Ter Hofstede. “Workflow
exception patterns”. In: International Conference on Advanced Infor-
mation Systems Engineering. Springer, 2006, pp. 288–302.
[28] Nick Russell et al. “Workflow data patterns: Identification, represen-
tation and tool support”. In: International Conference on Conceptual
Modeling. Springer, 2005, pp. 353–368.
[29] Nick Russell et al. “Workflow resource patterns: Identification, repre-
sentation and tool support”. In: International Conference on Advanced
Information Systems Engineering. Springer, 2005, pp. 216–232.
[30] Nick Russell et al. “Workflow control-flow patterns: A revised view”.
In: BPM Center Report BPM-06-22, BPMcenter. org (2006), pp. 06–
22.
[31] Keith Swenson. Taming the unpredictable: real world adaptive case
management: case studies and practical guidance. Future Strategies
Inc., 2011.
[32] Wil MP Van der Aalst, Mathias Weske, and Dolf Gr¨unbauer. “Case
handling: a new paradigm for business process support”. In: Data &
Knowledge Engineering 53.2 (2005), pp. 129–162.
76
[33] Wil Van Der Aalst, Kees Max Van Hee, and Kees van Hee. Workflow
management: models, methods, and systems. MIT press, 2004.
[34] David A Watt. Programming language design concepts. John Wiley &
Sons, 2004.
[35] Roger W Weidel. WorkFlow White Paper. SoftBrands Manufacturing,
Colorado - internal report, 2002.
[36] Wei-Dong Zhu et al. IBM FileNet P8 Platform and Architecture. IBM
Redbooks, 2011.
[37] Wei-Dong Zhu et al. Advanced Case Management with IBM Case Man-
ager. Vol. Third Edition. IBM Redbooks, 2013.
[38] Michael Zur Muehlen. Workflow-based process controlling: foundation,
design, and application of workflow-driven process information systems.
Vol. 6. Advances in Information Systems and Management Science.
Logos Verlag, 2004.
77
Universitatea Babe¸s-Bolyai Cluj-Napoca
Facultatea de Matematic˘a ¸si Informatic˘a
Anexa 6
Statement of Academic Honesty
I hereby declare that the thesis “A Parallel Programming Driven Com-
parison Between Workflow Management and Advanced Case Management
Systems”, submitted to the Faculty of Mathematics and Computer Science,
Babe¸s-Bolyai University Cluj-Napoca in partial fulfillment of the require-
ments for the Master of Science degree in the domain Mathematics and In-
formatics, the study program High Performance Computing and Big Data
Analytics, is written by myself and was never before submitted to any other
faculty or higher learning institution in Romania or any other country.
I declare that all information sources I used, including the
ones I found on the Internet, are properly cited in the thesis as
bibliographical references. Text fragments cited “as is” or trans-
lated from other languages are written between quotes and are
referenced to the source. Reformulation using different words of a
certain text is also properly referenced. I understand plagiarism
constitutes an offence punishable by law.
I declare that all the results I present as coming from simulations and mea-
surements I performed, together with the procedures used to obtain them,
are real and indeed come from the respective simulations and measurements.
I understand that data faking is an offence punishable according to the Uni-
versity regulations.
Date Student’s signature
78
Universitatea Babe¸s-Bolyai Cluj-Napoca
Facultatea de Matematic˘a ¸si Informatic˘a
Anexa 7
Copyright c
2019, Michael Andrew Oland
All rights reserved.
The author hereby grants to Babe¸s-Bolyai University Cluj-Napoca permis-
sion to reproduce and to distribute publicly paper and electronic copies of
this thesis document in whole or in part.
79
