Wydział Elektrotechniki, Automatyki, Informatyki i ... · Akademia Górniczo-Hutnicza im....
Transcript of Wydział Elektrotechniki, Automatyki, Informatyki i ... · Akademia Górniczo-Hutnicza im....
Akademia Górniczo-Hutnicza
im. Stanisława Staszica w Krakowie
Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki
KATEDRA INFORMATYKI
PRACA MAGISTERSKA
PRZEMYSŁAW DADEL, MARIUSZ BALAWAJDER
ANALIZA I MONITOROWANIE PROCESÓW BIZNESOWYCHZGODNIE Z PARADYGMATEM SOA
PROMOTOR:
dr inz. Dominik Radziszowski
Kraków 2011
OSWIADCZENIE AUTORÓW PRACY
OSWIADCZAMY SWIADOMI ODPOWIEDZIALNOSCI KARNEJ ZA
POSWIADCZENIE NIEPRAWDY, ZE NINIEJSZA PRACE DYPLOMOWA
WYKONALISMY OSOBISCIE I SAMODZIELNIE (W ZAKRESIE
WYSZCZEGÓLNIONYM WE WSTEPIE) I ZE NIE KORZYSTALISMY ZE
ZRÓDEŁ INNYCH NIZ WYMIENIONE W PRACY.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PODPIS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PODPIS
AGH
University of Science and Technology in Krakow
Faculty of Electrical Engineering, Automatics, Computer Science and Electronics
DEPARTMENT OF COMPUTER SCIENCE
MASTER OF SCIENCE THESIS
PRZEMYSŁAW DADEL, MARIUSZ BALAWAJDER
SOA ORIENTED BUSINESS PROCESS MONITORING ANDANALYSIS
SUPERVISOR:
Dominik Radziszowski Ph.D. Eng.
Krakow 2011
First and foremost, we wish to express ourgratitude to our supervisor PhD. Eng. DominikRadziszowski for his vast intellectual support,thorough technical expertise and inspiring attitude.We would also like to thank our colleague MSc.Eng. Krzyszof Doroz whose initial contributionsto our research on business process monitoringgreatly helped to advance our work.Last but not least, we wish to thank ourfamilies and friends who continually supportedand encouraged us in our work.
The research presented in this paper was partially supported by the European Union in the scope of the
European Regional Development Fund program no. POIG.01.03.01-00-008/08.
Contents
1. Introduction .................................................................................................................................... 8
1.1. Motivation.............................................................................................................................. 8
1.2. Thesis Objectives................................................................................................................... 9
1.3. Document Structure............................................................................................................... 10
1.4. Individual Contributions........................................................................................................ 11
2. Problem Background ..................................................................................................................... 12
2.1. SOA Solution Stack (S3) ....................................................................................................... 12
2.2. Business Process Monitoring ................................................................................................ 14
2.3. BPEL Language..................................................................................................................... 15
2.4. Monitoring Solutions Evaluation........................................................................................... 16
2.4.1. BPEL Engines ............................................................................................................ 16
2.4.2. Enabling Monitoring for Business Process Engines .................................................. 21
3. Technology Overview..................................................................................................................... 24
3.1. OSGi and Spring Dynamic Modules ..................................................................................... 24
3.2. Enterprise Service Bus and SerivceMix ................................................................................ 25
3.2.1. ESB Architecture ....................................................................................................... 25
3.2.2. ServiceMix ................................................................................................................. 26
3.3. OSGi Management and Monitoring ...................................................................................... 28
3.3.1. OSGiMM Architecture .............................................................................................. 29
3.3.2. OSGiMM Domain...................................................................................................... 30
3.4. Event Processing.................................................................................................................... 30
3.4.1. Rule Processing with Drools Expert .......................................................................... 31
3.4.2. Complex Event Processing with Drools Fusion......................................................... 31
3.5. Eclipse Rich Client Platform ................................................................................................. 32
3.5.1. Eclipse RCP Architecture .......................................................................................... 33
4. System Architecture and Design................................................................................................... 35
4.1. Design Assumptions .............................................................................................................. 35
4.2. System Requirements ............................................................................................................ 36
5
CONTENTS 6
4.2.1. Functional Requirements ........................................................................................... 36
4.2.2. Non-functional Requirements .................................................................................... 40
4.3. High Level Architecture ........................................................................................................ 41
4.3.1. Main System Elements............................................................................................... 41
4.3.2. Monitoring Process .................................................................................................... 43
4.4. Communication Layer Extensions ........................................................................................ 44
4.4.1. Monitoring Domain Extensions ................................................................................. 44
4.4.2. BPM Subscription Extensions ................................................................................... 45
4.5. Architecture of Rule-based Event Processing ....................................................................... 48
4.5.1. Remote Event Processing........................................................................................... 48
4.5.2. Rule Registry.............................................................................................................. 49
4.6. Monitoring Console............................................................................................................... 51
4.6.1. Monitoring Console Core Elements........................................................................... 51
4.6.2. Monitoring Console Extension Points ....................................................................... 53
4.6.3. BPEL Monitoring Console Component..................................................................... 54
4.6.4. Rule-based Event Processing in Monitoring Console................................................ 54
5. Implementation .............................................................................................................................. 56
5.1. BPEL Monitoring Domain .................................................................................................... 56
5.1.1. BPM Container .......................................................................................................... 58
5.1.2. BPM Component........................................................................................................ 59
5.1.3. ApacheODE Engine Monitor..................................................................................... 59
5.1.4. BPM Rule Event Processor........................................................................................ 60
5.2. Events Hierarchy ................................................................................................................... 63
5.2.1. Topology Events......................................................................................................... 63
5.2.2. Monitoring Events...................................................................................................... 64
5.3. Subscription Implementation................................................................................................. 67
5.3.1. Topology Subscription ............................................................................................... 67
5.3.2. Monitoring Subscription ............................................................................................ 67
5.3.3. Subscription Topology Restrictions ........................................................................... 68
5.4. Monitoring Console............................................................................................................... 69
5.4.1. Core Elements ............................................................................................................ 69
5.4.2. Monitoring Project Navigator .................................................................................... 73
5.4.3. Console Extensibility Implementation....................................................................... 73
5.4.4. Realization of BPEL Monitoring Component ........................................................... 75
5.4.5. Local Event Processing .............................................................................................. 76
5.5. Rule-based Event Processing................................................................................................. 77
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
CONTENTS 7
5.5.1. Business Rule and Rule Registry Implementation..................................................... 77
5.5.2. Event Processing Engine Implementation ................................................................. 79
5.5.3. Drools Fusion Event Processing Engine .................................................................... 79
5.6. Integration Testing ................................................................................................................. 82
5.6.1. OSGi Testing Framework........................................................................................... 82
5.6.2. Example Integration Test Case................................................................................... 84
5.7. Business Process Monitoring Platform Modules .................................................................. 85
6. System Evaluation.......................................................................................................................... 88
6.1. Deployment Infrastructure..................................................................................................... 88
6.2. Functional Verification .......................................................................................................... 90
6.2.1. Process Monitoring Validation................................................................................... 90
6.2.2. Rule Processing Validation ........................................................................................ 96
6.2.3. Additional Features ....................................................................................................101
6.3. Performance Verification .......................................................................................................102
6.3.1. Description of the Test Processes...............................................................................102
6.3.2. Test Cases...................................................................................................................103
6.3.3. Performance Tests Summary......................................................................................107
6.4. Evaluation Summary .............................................................................................................108
7. Conclusions .....................................................................................................................................110
7.1. Work Summary......................................................................................................................110
7.2. Thesis Contributions..............................................................................................................111
7.3. Further Research....................................................................................................................111
Glossary ................................................................................................................................................113
Acronyms ..............................................................................................................................................114
Bibliography .........................................................................................................................................116
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
1. Introduction
The subject of the presented thesis is SOA Oriented Business Process Monitoring and Analysis.
This work discusses the problem of business process monitoring in the context and with the application
of the service orientation paradigm, proposes an architectural solution and describes the implementation
of the system for business process monitoring.
1.1. Motivation
According to the Workflow Management Coalition, a business process is a set of one or more linked
procedures or activities which collectively realise a business objective or policy goal, normally within
the context of an organisational structure defining functional roles and relationships [47].
Business processes can serve various purposes e.g. they can describe a document transition in an
office or a process of handling a credit request. As business processes usually express repetitive work,
automation of their management was a natural step in their development. Automation of a business
process, in whole or part, during which documents, information or tasks are passed from one participant
to another for action, according to a set of procedural rules is called a workflow [47].
Bussiness processes play vital role in Service Oriented Architecture (SOA) which is one of the most
important paradigms for implementing enterprise software systems [48]. The IBM SOA Solution Stack
(S3) model [3] places the business process layer near the top of the stack. In that layer, SOA supports
application construction by introducing a composite service which orchestrates the information flow
among a set of services and human actors. These composite services are called business processes. In the
non-SOA world, business processes are precieved as custom applications [48].
There are various notations for a usually declarative description of the business processes [33]. The
most notable are:
• BPMN - Business Process Modeling Notation - that describes a process in abstract terms,
• BPEL (Business Process Execution Language), BPELj (Business Process Execution Language for
Java), XPDL (XML Process Definition Language) or jPDL (Java Process Definition Language)
that can be executed in their respective execution environments.
Currently, the most widely supported [33] business process definition language is Business Process
Execution Language (BPEL) [5]. It has more than a dozen commercial and open-source implementations
of process execution engines.
8
1.2. Thesis Objectives 9
Existing BPEL execution environments are commonly provided with a set of tools facilitating
creation, deployment and management of BPEL processes. Even though each process definition tool
is dedicated to a particular process execution engine, they generate BPEL-compliant process definitions
which may be run on almost any BPEL engine.
In the area of business process monitoring and management the situation is more complex. Almost
all the engines provide basic business process monitoring and managements capabilities, exposed e.g.
via application GUIs (e.g. BPELMaestro by Parasoft, WebSphere by IBM) or exploiting vendor-specific
Application Programming Interface (API) (Oracle, ApacheODE, Glassfish). These solutions not only
are incompatible but also they expose only the basic information about the running process instances
and performed process activities. Rarely are filtering, data aggregation or bottleneck analysis supported,
even on the basic level. A number of implementations has been investigated in the context of the business
process monitoring and analysis (section 2.4). It has been found that the usability of custom monitoring
GUIs is insufficient.
Those solutions are often limited to parsing data provided by their own engines, they do not enable
correlations of subprocesses with the base processes and expose only simple query mechanisms based
on pull interfaces (if an API is available at all). Often, there is no direct support for the selection of
monitoring data, with all the efficiency drawbacks resulting from collection and storage of the unwanted
information.
As SOA orchestration processes are gaining importance, the existing monitoring and governance
tools for vendor-specific BPEL engines fail to uphold the pace [40]. The most common problem of the
existing monitoring tools is that they do not meet growing expectations. Additionally, the insight into
the process execution they provide may satisfy neither business users nor IT specialists. They tend to be
incomprehensible for the first group and insufficient for the second. Other frequently issued problems
include lack of portability and support for different engines implementations, inconvenient data access,
inflexibility and low information selectivity.
Available monitoring tools do not fully meet the stated expectations. It was necessary that the
monitoring approach for business processes had to be reconsidered and redesigned to address the needs
of target user groups. As a result of studies on the existing business process monitoring systems, detailed
functional requirements have been specified and they provide a foundation to a new conceptual design
and architectural solutions for business process monitoring.
1.2. Thesis Objectives
The work effort that was taken during this master thesis project can be summarized in two major
categories. The first objective was to provide Business Process Monitoring Platform that overcomes
the inadequacy of the existing tools as motivated in the previous section. The resulting system should
be a multi-vendor, distributed monitoring solution that is suitable for a wide range of users. The
proposed system would bridge the gap between the current business process monitoring tools providing
a cost effective solution as an alternative to commercial Business Activity Monitoring (BAM). The
platform should change the focus of process monitoring from measuring the low-level, process-specific
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
1.3. Document Structure 10
metrics of business process engines to the more business-oriented goals. The constructed tool would
allow business users with limited technical knowledge to trace business processes based on their state,
variables and other parameters. The entire solution should be completely transparent from the executed
business process point of view, so any modifications of the workflow would be obsolete. The key
characteristics of the tool would be: the intuitive graphic console that provides an aggregated process
view, filtering data mechanisms, notifications, business process analysis capabilities and the ease of use.
The core functionality of the system would be monitoring of business processes executed in various
implementations of orchestration engines.
The second objective of the project comes from the research context presented in the next chapter.
The solution that will be proposed, largely relies on the concepts and technologies developed as
a part of the IT-SOA project [2]. The discussed system will serve the purpose of verification and
testing of Adaptive SOA Solution Stack (AS3) components which are developed and promoted by
the aforementioned project. Business Process Monitoring Platform will mostly rely on the adaptive
integration layer [48] and the elements of the system presented in this thesis may be used to form the
adaptive business process layer. The presented monitoring solution, in its final version, will be distributed
together with Adaptive SOA Solution Stack Studio (AS3 Studio).
1.3. Document Structure
The first chapter comprises introduction and motivation of the presented work. In the ProblemBackground the context of the research conducted in this master thesis project is described. Then,
Technology Overview chapter describes a set of technical solutions used in the created Business Process
Monitoring Platform. In System Architecture and Design product requirements are specified and
system architecture and design considerations to satisfy them. Next, Implementation chapter elaborates
on how the most important system elements were realized. Further, in System Evaluation system is
assessed from the functional and performance point of view. Finally, in the last Conclusions chapter,
the work is summarized and further research directions are suggested. At the end, list of used acronyms,
glossary and bibliography are presented.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
1.4. Individual Contributions 11
1.4. Individual Contributions
This thesis is a result of the equal, joint effort of its authors. Though the individual contributions are
largely interleaving in this project, the work areas to which particular author primarily committed can be
distinguished. The summary of these individual inputs is presented in the table.
Work Part Author
1 Introduction Przemysław Dadel
2 Problem Background Przemysław Dadel
3 Technology Overview Mariusz Balwajder
4.1 Design Assumptions Przemysław Dadel
4.2 System Requirements Przemysław Dadel
4.3 High Level Architecture Przemysław Dadel
4.4 Communication Layer Extensions Mariusz Balwajder
4.5 Architecture of Rule-based Event Processing Przemysław Dadel
4.6 Monitoring Console Przemysław Dadel
5.1 BPEL Monitoring Domain Mariusz Balwajder
5.2 Events Hierarchy Mariusz Balwajder
5.3 Subscription Implementation Mariusz Balwajder
5.4 Monitoring Console Przemysław Dadel
5.5 Rule-based Event Processing Przemysław Dadel
5.6 Integration Testing Mariusz Balwajder
6 System Evaluation Mariusz Balwajder
7 Conclusions Przemysław Dadel
Table 1.1. Individual contributions
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2. Problem Background
This chapter describes the research background of the work presented in the thesis which is
necessary for understanding the proposed solutions. First, the topics discussed in this chapter concern
Adaptive SOA Solution Stack [48] (section 2.1) which defines the important concepts for business
process monitoring. Further, general remarks on business process monitoring are introduced (section 2.2)
and finally BPEL business process language is presented (section 2.3) with a short description and
comparison of the existing runtime environments and monitoring approaches (section 2.4).
2.1. SOA Solution Stack (S3)
Service orientation is a common approach in design and implementation of the modern IT Systems.
It offers great flexibility in realizing business processes and goals. In this approach the distributed
software is partitioned into units called services. A service is a functional abstraction for solving
particular problem that satisfies a set of good design practices [19]: reusability, loose coupling, autonomy,
discoverability, compossibility, etc. One of the key aspects of this approach is the focus on reusability and
return of investment. In service oriented world, there are dozens of ready-to-use services, implementing
well-defined functional pieces, which when you put them together, can provide a solution to the most
complex problems. SOA reduces cost, increases revenue, and enables rapid application delivery and
integration across organizations and siloed applications [3].
To facilitate the widespread use of SOA based solutions, a set of widely accepted architectural
guidelines, which would drive the construction of SOA compliant systems, was needed. For that purpose
an architectural template called SOA Solution Stack (S3) [3] was proposed. S3 recommends layered
architecture where each layer represents different concerns of the complex, distributed system. The
architecture is presented in figure 2.1. A more detailed description of the architecture layers can be
found in the referenced sources [3, 48].
While the presented model is highly generic, in the real SOA system the process of managing and
adjusting such systems may be highly complex. Even if S3 proposes a dedicated governance layer, the
conducted research [48] indicate that all the system layers need to cooperate to achieve the effective
management of all the stack.
The AS3 Studio [1] project introduces adaptability into the S3 as a mean to alleviate complexity of
the computing system. The proposed solution named as Adaptive SOA Solution Stack is inspired by the
idea of Autonomic Computing [23]. The solution aims to enable construction of the systems with better
12
2.1. SOA Solution Stack (S3) 13
Figure 2.1. SOA Solution Stack
utilization of IT infrastructures and more reliable Quality of Service (QoS) and Quality of Experience
(QoE).
AS3 proposes policy-driven system adaptation that not only can concentrate on the single layer
adaptation but also provides the means of cross layer adaptation. It is justified by the statement [48]:
S3 layers are not independent of one another and decisions made on a given layer may influence the
behavior of other layers. Any parameter set by lower layers can be considered as a constraint for the
adaptability strategies implemented on higher layers. AS3 not only does focus on adaptation strategies
but also on the problem of extending various S3 layers with adaptability mechanisms.
AS3 proposes a uniform pattern-based approach to adaptive S3 layers extensions, where in each layer
particular components constitute an adaptation loop with policy-driven management.
Moreover, AS3 Studio proposes a selection of software implementation technologies that can be
applied across S3 layers, providing interoperability of the adaptability extensions.
Figure 2.2. Adaptive SOA Solution Stack
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.2. Business Process Monitoring 14
Business Process Monitoring Platform in the context of Adaptive S3
To provide adaptation, system has to be properly monitored and the AS3 provides advanced solutions
for SOA systems monitoring [49]. Presented Business Process Monitoring Platform uses adaptive
integration layer of AS3 and follows the technology selection for adaptive SOA system. Business Process
Monitoring Platform can be perceived as a partial implementation of the adaptive mechanisms in the S3
business process layer. The adaptation effectors can be twofold. On one hand the system will provide
meaningful data concerning e.g. QoS, QoS or user defined Key Performance Indicators (KPI) that
can be analysed by non-technical users. The result may be an adjustment of the enterprise policy and
redeployment of a more optimal process. On the other hand, monitoring data collected in the business
process layer could be used to facilitate adaptation process in the lower layers. Those layers could
cooperate to improve various aspects of the SOA system that are affecting the business process layer.
2.2. Business Process Monitoring
As this thesis describes a particular solution for business process monitoring that focuses on BPEL
business processes, it is necessary to explain what Business Process Monitoring is, why monitoring is
important for service oriented systems and how one can benefit from having a well suited monitoring
solution.
As Service Oriented Architecture is gaining importance, more and more effort is put to manage
services and their environments effectively. Integrated Service Management is built, according to IBM
model [26], on 3 main pillars:
• Service Visibility,
• Service Control,
• Service Automation.
SOA application monitoring is aimed to provide and facilitate service visibility. For an service
oriented, enterprise-level solution it is vital to:
• be able to verify and track service calls and process execution,
• be aware of faulty situations and changes in environment,
• log service interactions for audit purpose,
• verify whether service level agreement conditions are met.
However, besides these generally obvious use cases for monitoring tools, it has to be realized that
business process engine which orchestrates process execution is a point where all service interaction
goes through. Using the information available at this point, more business specific knowledge about
the enterprise can be built. If we provide a monitoring tool with semantics of service interaction,
it can monitor user defined KPI (Key Performance Indicators) like income from using particular
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.3. BPEL Language 15
service, products that customers buy most often using our services, profiling information about service
performance and availability, find a common service interaction path reflecting customer habits etc. As
one can conceive, there is huge potential in building knowledge about business processes in an enterprise
provided that there is the right monitoring solution.
A good solution for Business Process Monitoring can play an important role in the development
of business intelligence and provide automated interpretation for actual business information. This high
level approach to Business Process Monitoring is often referred as Business Activity Monitoring (BAM).
Further, in the context of AS3 architecture, Business Process Monitoring is indispensable to provide
adaptation in the business process layer.
2.3. BPEL Language
One of the most popular standards for business process orchestration is XML-based Business Process
Execution Language (BPEL) which manages interaction of Web Services. The version 1.1 of the standard
was prepared by the consortium including BEA Systems, IBM, Microsoft, SAP and Siebel Systems
which was submitted submitted to OASIS for standardization. In 2007 OASIS introduced 2.0 version
that provides extensions to the previous versions. The official name of the standard is Web Services
Business Process Execution (WS-BPEL) and it refers to the naming convention of the Web Service
related technologies.
In the BPEL process specification there can be distinguished two parts:
• static - defines process communication partners (invoked Web Services),
• dynamic - defines interaction sequence that involves partners interaction.
BPEL business process uses Web Service mechanism to communicate with partners. The
constructions partnerLink and partnerLinkType declare respectively service which business
process remotely communicates with and that service Web Service Definition Language (WSDL)
interface.
Partners can exchange information using multiple links, each with well defined functionality. Both
synchronous and asynchronous Web Services communication is supported.
Business processes expressed in BPEL language consist of a set of activities that define business
process functionality. The most important activities are:
• invoke, receive, reply - used for invocation and message reception between partners,
• assign - process variable value modification,
• if, switch, while, repeatuntil, foreach - conditional expressions and loops,
• wait - time constrained waiting for a certain event,
• throw, catch for error notification and handling,
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 16
• sequence, flow for sequential and parallel activity execution.
For expression evaluation XPath standard [46] is used.
Traditional transaction handling is irrelevant in the environments where transactions between
interaction parties are long lasting [4]. In such situations a compensation mechanism can be applied.
BPEL provides support for compensation. Additionally, there exists UML Profile for Automated
Business Processes [24] that defines transformation of UML activity diagrams to BPEL process. It is
a step towards supporting the execution of UML diagrams.
There are various implementations that support BPEL v1.1 specification. Together with the execution
environments, basic monitoring tools and graphical editors for the process composition are often
supplied.
The WS-BPEL 2.0 introduces several improvements in comparison with the previous standard.
The changes concern syntax clean-up and disambiguation, better support of process variables e.g.
it’s easier to map process variables to WSDL massages. Additionally, new specification introduces
EXtensible Stylesheet Language Transformations (XSLT) Transformations support and validate
activity for schema validation. It also brings new structural flow activities, namely forEach,
supporting parallel loop with runtime specified number of iterations. There are noticeable improvements
in the area of error handling and compensation. Furthermore, BPEL 2.0 specification defines
extensionAssignOperation and extensionActivity to add respectively new assign and
other activity types. More detailed discussion of BPEL 2.0 features can be found in [13].
2.4. Monitoring Solutions Evaluation
In this section a brief overview of existing BPEL execution engines with regard to the monitoring
capabilities will be presented, then various approaches that were considered for building business process
monitoring solution will be discussed.
The information presented in this section is based on the internal university report for IT-SOA
project [31].
2.4.1. BPEL Engines
The following implementations have been investigated in the context of process monitoring and
management: BPEL Process Manager by Oracle, WebSphere by IBM, ActiveVOS by Active Endpoints,
LiquidBPM by Cardiff, BPELMaestro by Parasoft, bizZyme by Creative Science Systems, Biztalk by
Microsoft, ApacheODE by Apache and jBPM by JBoss.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 17
BPEL Process Manager by Oracle
Type Description
Process design Oracle BPEL Designer
Monitoring BPEL Console Java API – Oracle API
Documentation http://www.oracle.com/technology/products/
ias/bpel/index.html - extensive documentation with
step-by-step tutorials
Licence proprietary, free for noncommercial use
Supported application servers WebSphere, JBOSS, BEA WebLogic
Remarks no available source code, license do not allow for decompilation and
modification of the execution code
Table 2.1. BPEL Process Manager by Oracle
WebSphere by IBM
Type Description
Process design BPEL Modeler
Monitoring Premises Server, WebSphere Business Monitor (http:
//www-01.ibm.com/software/integration/
wbimonitor/) – proprietary solution, no API
Documentation http://www-01.ibm.com/software/integration/
wbimonitor , FAQ, training courses, red books
Licence commercial
Supported application servers WebSphere
Remarks no available source code, license do not allow for decompilation and
modification of the execution code
Table 2.2. WebSphere by IBM
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 18
ActiveVOS by Active Endpoints
Type Description
Process design advanced graphical editor for business process management
Monitoring build-in monitor - processes, tasks and statistics, no API
Documentation http://www.activevos.com/index.php
http://www.activevos.com/indepth/a_
startHere/c_activeVOSDemonstration/
ActiveVOSDemonstration.html
Licence commercial, free 30-day trial
Supported application servers JBoss, WebSphere, WebLogic, Tomcat
Remarks no available source code, license do not allow for decompilation and
modification of the execution code
Table 2.3. ActiveVOS by Active Endpoints
LiquidBPM by Cardiff
Type Description
Process design Cardiff LiquidBPM Studio
Monitoring build-in LiquidBPM Manager, no API
Documentation http://www.cardiff.com/products/liquidbpm_
sdk/features/LIQUIDBPM_COMPONENTS.html
Licence 30-day evaluation
Supported application servers not required
Remarks no available source code, license do not allow for decompilation and
modification of the execution code
Table 2.4. LiquidBPM by Cardiff
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 19
BPELMaestro by Parasoft
Type Description
Process design Eclipse platform plug-in
Monitoring build-in monitoring, no API
Documentation http://www.parasoft.com/jsp/products/home.
jsp?product=BPEL
Licence proprietary
Supported application servers not required
Remarks no available source code, license do not allow for decompilation and
modification of the execution code
Table 2.5. BPELMaestro by Parasoft
bizZyme by Creative Science Systems
Type Description
Process design Eclipse platform plug-in
Monitoring console API & logging, no documentation
Documentation http://www1.creativescience.com/Products/
bpel.shtmlhttp://www1.creativescience.com/
Products/bpelEngine.shtml
Licence commercial
Supported application servers not required
Remarks no available source code, license do not allow for decompilation and
modification of the execution code
Table 2.6. bizZyme by Creative Science Systems
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 20
Biztalk by Microsoft
Type Description
Process design Windows Workflow Foundation - VS2008, Visio
Monitoring
• BizTalk Server Administration Console
• Microsoft Operations Manager (MOM)
• Event Viewer
• Business Activity Monitoring (BAM)
• http://msdn.microsoft.com/en-us/library/
aa577454.aspx
• http://www.tech-faq.com/
monitoring-biztalk-server.shtml
Documentation www.microsoft.com/biztalk/en/us/default.aspx
www.microsoft.com/poland/biztalk/default.mspx
extensions: www.microsoft.com/poland/biztalk/
evaluation/adapter/default.mspx
Licence free 30-day trial version
Supported application servers .NET Platform
Remarks no available source code, license do not allow for decompilation and
modification of the execution code
Table 2.7. Biztalk by Microsoft
ApacheODE
Type Description
Process design web browser process designer http://mpathirage.com/
Monitoring monitoring console and API http://ode.apache.org/
user-guide.html#UserGuide-ManagementAPI
Documentation open source
Licence JEE compliant
Supported application servers access to the source code, can be instrumented
Remarks http://ode.apache.org/
Table 2.8. ApacheODE
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 21
jBPM by JBoss
Type Description
Process design Graphical Process Designer
Monitoring processes are launched by Process Virtual Machine, no dedicated
monitoring solution, available monitoring API and source code
Documentation http://docs.jboss.com/jbpm/bpel/v1.1/userguide/
http://www.jboss.org/jbossjbpm/jbpm_documentation/
Licence open source (CPL/LGPL)
Supported application servers JBoss
Remarks access to the source code, can be instrumented
Table 2.9. jBPM by JBoss
Though only a few BPEL platform were presented, large incompatibilities of monitoring can be
observed and providing an integrated monitoring solution will be a no easy task.
2.4.2. Enabling Monitoring for Business Process Engines
As presented above, the diversity of the business process execution engines is vast and it seems that
no uniform way of extracting business process execution monitoring data can be provided. This section
will list various methods for retrieving monitoring data from business process engines.
There can be distinguished two main approaches for that purpose:
• non intrusive - that use mechanisms exposed by the monitored engines,
• intrusive - that assume modification of the execution platform or the monitored process.
Data pulling
One of the presented BPEL engines - OpenESB - provides an API for monitoring and managing
deployed and executed business processes. The interface allows to get the following information:
• process and process instance identifiers,
• errors that occurred in process instances,
• process variable values,
• process, instances and process activities data,
• activities status and timestamps,
• number of activity iterations.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 22
The monitoring solution can be based on synchronous fetching of the exposed data. However, there is
a serious problem with the choice of data pulling frequency. On one hand, low sampling frequency can
lead to the loss of important information about the process progress, on the other hand, low data query
interval may badly affect system performance. Such an API is suitable for getting static information e.g.
about the process structure, but is not relevant for detailed process progress monitoring.
Custom event listeners
Some business process execution engines (e.g. OpenESB and ApacheODE) provide an interface
that allows to register custom event listeners that can be used for notification about process execution
changes. The resolution of the information provided by such interfaces varies from engine to engine, but
the generated events usually inform about:
1. start, stop and failure of the process,
2. process activity life-cycle status changes,
3. process variable value changes.
Moreover, these events may carry accurate timestamps and identifiers of the source processes or process
instances.
This solution has many advantages. It provides most of the necessary data and should not badly affect
business process engine performance. For the best results, it should be complemented by engine’s API
that allows to retrieve static information such as process definition files. However, the drawback is that
those custom event listeners have to be provided for different engine implementations and the produced
events have to be transformed to standardised format.
Business Process instrumentation
One of the simplest and the most intuitive means of collecting business process monitoring data is
modification of the business process in such a way that process itself provides necessary information. The
solution is based on the idea of adding monitoring logic to the process. For example, in BPEL process
there could be added invoke operations before each process step, that would call some web service
and send process progress information. The main disadvantage of this approach is that process has to be
modified. It can be done before process deployment to the engine, but it may be inconvenient in case of
huge number of processes and, additionally, it hardcodes in the business process the static information
about data collecting Web Services. Alternatively, process could be dynamically altered by monitoring
component by on-demand redeployment of the modified process by the means of engine’s API, but that
solution cannot be applied to every engine.
Finally, the most serious drawback is that business process execution could considerably slow
down and that the measurement information may be insufficiently accurate due to necessity to invoke
additional code. Another disadvantage is that all the additional code will be also visible in the business
process editors and viewers and it can make the instrumented process illegible.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
2.4. Monitoring Solutions Evaluation 23
Execution environment instrumentation
The most advanced yet the most flexible solution is the modification of the execution environment
that would generate events on process execution progress and asynchronously forward them for the
further analysis. The events would carry the following information:
• executed operations timestamps,
• process, instance and activity identifiers,
• activity type and activity specific information e.g. web service identifier
• activity lifecycle data.
Asynchronously generated events can be propagated and published using Message Oriented Middleware
(MOM) to achieve better scalability.
This solution would require either static modification of the source code of the engine or using
dedicated instrumentation tool.
The advantages of this approach are as follows:
• business process code does not have to be modified,
• increased accuracy of the collected data in case of the well defined instrumentation points,
• software decomposition for components responsible for collecting data and data propagation what
reduces time for providing implementation for the specific execution environment.
The more detailed description and implementation of this solution can be found in the referenced
work [16].
None of the presented approaches can be applied to every business process platform. It is believed that
the most promising is a hybrid solution. Each process engine type could be provided with a dedicated
agent or monitor that would extract monitoring data in an engine specific way and propagate them in
form of standardised events using Message Oriented Middleware (MOM). This concept is adopted in the
system presented in this thesis.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3. Technology Overview
This chapter describes the selection of the most important technologies used to construct the system
discussed in the thesis. The right choice of the software solutions and components was crucial for rapid
and elegant construction of the presented system. The diversity of the software components is so vast that
the most essential building blocks of the core system elements were already available and required only
minor adjustments or providing well defined extensions. This allowed the system developers to focus
primarily on the system functionality.
3.1. OSGi and Spring Dynamic Modules
OSGi [35], previously known as Open Services Gateway initiative, is a dynamic module system
and service platform for Java. The OSGi platform provides a highly customizable software integration
framework that allows applications to be built from reusable and collaborative components called OSGi
(OSGi) bundles. Bundles not only can be deployed, swapped or modified during runtime, but also their
dependencies and even the system architecture can be modified without application restart. Platform
provides a service-oriented architecture that minimize the coupling between components and enables
bundles to dynamically discover each other. Due to OGSi’s service orientation it is often called a SOA
platform in Java Virtual Machine, but the recent remote OSGi standard [45] extensions allow the OSGi
runtime to span beyond a single virtual machine.
The Spring Dynamic Modules (Spring DM) for OSGi Service Platform [12] framework is aimed to
introduce the application of Spring framework [42] to OSGi development. OSGi and Spring DM based
Java application features various benefits such as:
• seamless Spring framework integration,
• ability to modify structure of a running system,
• dynamic bundle discovery, adding, update and removal,
• OSGi integration,
• low coupling between components.
The application of Spring DM greatly clarifies the construction of OSGi based system that heavily relies
on the OSGi services by eliminating a repetitive code for service registration and tracking. Besides, it
24
3.2. Enterprise Service Bus and SerivceMix 25
allows for simple product reconfiguration and extension by declaratively exporting the new or modified
services.
3.2. Enterprise Service Bus and SerivceMix
Enterprise System Bus (ESB) is a popular term that may be understood differently depending on
the context [39]. ESB most commonly may refer to an architectural pattern (3.2.1) or a product offering
integration functionality (3.2.2).
3.2.1. ESB Architecture
ESB is described [11] as a middleware software architecture based on the open standards that
provides fundamental services for achieving complex application interoperability. ESB facilitates
information exchange between applications that are built with various technologies and work in the
distributed environment. It is achieved through the integration services that are responsible for message
transformations and intelligent event routing. ESB enables effective implementation of SOA including
service orchestration, management, monitoring, messaging support, security, multiple communication
protocol support. ESB should be used to integrate communication between message providers and
message consumers in the result enabling service reusability and decreasing business costs of enterprise.
Owing to the flexible design, services can be modified, reconfigured, extended, migrated or swapped
during runtime without requirement of restarting business systems.
In the heterogeneous, distributed systems there are many reasons to consider application of ESB. The
most important [43] are:
• reduced time of delivering product on market,
• seamless integration between most of standard protocols (Java Message Service (JMS), File
Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Transmission Control Protocol
(TCP) etc.),
• reduced maintainability costs,
• higher reliability,
• support for heterogeneous environments,
• reliable communication,
• transparent message transformation,
• efficient message routing,
• centrally administration despite distributed system nature,
• support for incremental application deployment.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.2. Enterprise Service Bus and SerivceMix 26
Applications built without Enterprise Integration Pattern (EAI) or ESB are often based on
point-to-point communication (figure 3.1).
Figure 3.1. Point-to-point based integration
This approach is in many cases a common way of distinct applications integration. The result is the
high coupling between applications. In the worst case, the applications are highly likely to use different,
incompatible communication protocols which need to be supported and translated. For example, when
Cobol application needs data from Supply Chain Management (SCM) and Enterprise Resource Planning
(ERP) System (SCM and ERP system uses different communication protocols) then it is necessary to
implement data conversion for each format. Actually, almost for every relationship between components
a custom transformation may need to be implemented. Adding new components to a system increases
cost, makes maintainability harder and less efficient.
Generally, ESB provides an abstraction layer on top of various of message oriented systems (MOM).
As shown in figure 3.2 all services communicate in the same fashion with ESB which translates messages
to appropriate format and forwards them to the respective receivers.
3.2.2. ServiceMix
As described in the ServiceMix documentation [10]:
ServiceMix is a complete and professional integration platform powered by OSGi.
It provides an enterprise ready, powerful ESB. Thanks to OSGi, ServiceMix is a highly
configurable platform and allows you to extend it very easily.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.2. Enterprise Service Bus and SerivceMix 27
Figure 3.2. ESB based integration
ServiceMix architecture is presented in figure 3.3 and consists of two major layers:
• Micro Kernel ,
• Technology layer.
Figure 3.3. ServiceMix overview
Micro Kernel is a lightweight runtime environment that extends OSGi based on Apache Felix Karaf
[6] with powerful features for handling and managing OSGi bundles and enabling deployment of various
components and applications.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.3. OSGi Management and Monitoring 28
The key features of SerivceMix are as follows:
• Hot deployment of OSGi and Java Business Integration (JBI) bundles,
• Dynamic configuration of services with ConfigurationAdmin OSGi service,
• Integrated Logging System based on SLF4j [38] logging facade,
• Provisioning of libraries or applications through a number of various ways,
• ServiceMix can be integrated with the operating system as a system service,
• Shell can be extended with extra features depending on the installed bundles,
• Remote ServiceMix shell access through Secure Shell (SSH),
• Java Authentication and Authorization Service (JAAS) based security framework.
The technology layer provides complex integration with a large set of technologies used in
enterprise systems such as JBI, JMS, Enterprise JavaBean (EJB), Spring, Java API for XML (JAX-WS),
Representational State Transfer (REST), Service Component Architecture (SCA) and many more. All
the mentioned technologies can be integrated together due to using Normalized Message Router which
is responsible for message transformation.
3.3. OSGi Management and Monitoring
OSGi Management and Monitoring (OSGiMM) [49] is a comprehensive ESB management and
monitoring framework built atop of OSGi containers federation. Monitoring configuration is defined by
user-specified scenarios that can be dynamically installed and even concurrently modified during system
runtime in the distributed environment. The designed system provides selective monitoring capabilities
that enable monitoring of only interesting system elements. Moreover, there are mechanisms dedicated
to selective reaction for lifecycle changes in monitored elements which are supported by embedded
complex event processor which is particularly useful in large, distributed applications.
OSGiMM provides monitoring features for ESB based on OSGi containers federated over Message
Oriented Middleware (MOM). Functionality is realized by set of OSGi bundles that need to be deployed
on all containers within the federation.
After initial system configuration, management and topology monitoring becomes seamlessly
available for the user. Elements of the federation form an abstract dynamic structure called topology.
The highest level of this structure are OSGi containers that can contain various topology elements
depending on domain implementation. For example for OSGi domain, containers report bundles with
their state altogether as their children. On the other hand ESB domain encompasses Service Assemblies
instead of bundles.
One of most important aspects of OSGiMM is that it does not require any changes in existing code.
All features are transparent for working system.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.3. OSGi Management and Monitoring 29
The following citation from OSGiMM Overview [37] states that most important benefits of OSGiMM
are:
• declarativity - the User specifies a monitoring scenario where parameters that need to be monitored
and topology elements are provided. Scenario is specified declaratively and can be exported to
distributed repository for the purpose of future usage.
• dynamism - monitoring scenarios can be activated at any time and activation does not enforce
stopping applications that are to be monitored. Activation triggers realization of on-demand
instrumentation.
• selectivity - it is assured that instrumentation is triggered only in locations which are important
for particular monitoring scenario, therefore the overhead caused by monitoring is restricted to the
minimum.
• self-configuration - when federation changes, e.g. new container is added, some services are
undeployed. It is assured that monitoring scenario realization is maintained.
• flow aggregation - when there are multiple Users which want to perform the same monitoring or
management activities, the data flow related to the task is aggregated in order to reduce the cost of
data transmission.
3.3.1. OSGiMM Architecture
The OSGiMM architecture is shown in figure 3.4.
Figure 3.4. OSGiMM Architecture
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.4. Event Processing 30
Architecture elements have the following meaning:
• Monitoring Scenario represents abstract monitoring goals defined by monitoring configuration.
There can be any number of independently managed monitoring scenario instances installed in
system.
• Instrumentation layer is responsible for discovering topology, container state and monitor service
activity.
• Data Collection layer defines methods of collecting and distribution of monitoring data.
• Data Processing layer calculates differentiated statistics connected to monitoring data with
Complex Event Processing (CEP) engine.
• Data Presentation layer is designed to show underlying layers status summary.
3.3.2. OSGiMM Domain
A domain is a collection of interconnected components and resources interacting to reach a common
goal that is a subject of monitoring. It is a system partitioning concept introduced by OSGiMM, used to
separate concerns of monitoring of various aspects of SOA-based system. It offers the following features:
• component separation between domains that ensures that any modifications within domain do not
have impact on the others.
• virtual communication channels dedicated to specific topology within domain,
• remote OSGi services management within domain separating services registered in different
domains.
At the moment there are three implemented domains that can exist simultaneously within ESB
Communication Layer: ESB, SCA and BPEL (which is a subject of extension in this thesis).
To introduce a new OSGiMM domain topology of the elements that constitute that domain and
events that can be exchanged within the particular elements have to be defined. Additionally, new domain
requires domain specific elements to be deployed in the container(topology, monitoring and management
agents) which are responsible for monitoring and management process of a given domain.
3.4. Event Processing
According to “Event Processing in Action” [20] event processing is computing that performs
operations on events. Common event processing operations include reading, creating, transforming and
filtering events. In the presented system, event processing is based on Drools Expert and Drools Fusion
solutions.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.4. Event Processing 31
3.4.1. Rule Processing with Drools Expert
Drools Expert is a Business Rule Management System (BRMS) that combines rule-based paradigm
with object-oriented programming to provide decision support and flow control altogether in order to
enrich business applications functionality. Rule processing is based on an efficient pattern matching
solution called Rete [15] algorithm. Efficiency of the Rete algorithm does not depend on the number of
deployed rules. As a result, it makes solution ideally crafted for processing in search large number of
patterns simultaneously. Pattern matching is a process of confronting the fact base confronted with the
deployed rules. When the rule is matched, differentiated actions described in the rule are executed, that
optionally may contribute to the fact base.
Figure 3.5. High level view of a rule engine
The successful inference process is based on two separate input categories: rules and facts. As shown
in figure 3.5, the user-created rules are kept within Production Memory which cannot be modified during
inference process. Facts on the other hand are stored in Working Memory and can be modified by
inserting new facts or as a result of rule execution. Pattern Matcher is responsible for matching rules
and facts with Rete algorithm. The Agenda orchestrates execution order of conflicting rules (rules are
conflicting with each other when they are true for the same fact assertion) with Conflict Resolution [28]
strategy.
3.4.2. Complex Event Processing with Drools Fusion
Complex Event Processing (CEP) is a concept introduced for extensive and efficient online
data stream processing. Nowadays, companies must be able to store and process huge amounts of
differentiated data, especially in search of patterns what may be a difficult problem. To address this
challenge, the new generation of software shifts focus from data related processing to on-line event
processing. In this approach, instead of data, system stores queries that are executed on the incoming
events. As a result, amount of information that needs to be stored is reduced. CEP enables detection of
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.5. Eclipse Rich Client Platform 32
complex patterns such as event relationships, specific event field values, their correlation and many more,
including time based relationships of event-driven processes.
Drools Fusion is a module which extends rule-processing platform with CEP capabilities. Its
functionality was derived from common characteristics of CEP processing such as [29]:
• high amount of events is obsolete, only small number is meaningful,
• events are immutable,
• rules must react to the event pattern detection,
• events have temporal relationships,
• system is concentrated on analyzing events altogether with their relations between data streams,
• event aggregation is often performed.
Based on this high-level CEP characteristics, a module with the following functionality was defined:
• events are evaluated in their domain context,
• enables stream event processing,
• timing window support,
• reactive rules,
• unified clock within session,
• event garbage collection.
These attributes make Drools Fusion an efficient and comprehensive solution not only for basic pattern
detection but also for more complex, domain specific analysis of the event producing system.
3.5. Eclipse Rich Client Platform
The Eclipse Rich Client Platform (Eclipse RCP) is a Java based framework accelerating
development and deployment of desktop and embedded rich client applications. RCP strongly relies
on modularity infrastructure of underlying lightweight OSGi Equinox [17] container. Sophisticated
provisioning infrastructure provides huge extensibility of the programming model, Eclipse RCP provides
comprehensive extensions dedicated to developing enterprise multilingual GUI, help assistants, complex
wizard helpers and many others. Eclipse RCP not only does define visual layer but also development
standards for underlying layers making Eclipse RCP one of the best rich client frameworks for Java.
RCP is a standard that is used by many industries around all the world, from NASA, IBM through
World Health Organization to Adobe which adapted Eclipse RCP as a basis for its own products.
The main advantages of Eclipse RCP are:
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.5. Eclipse Rich Client Platform 33
• it is an open and extensible platform,
• provides multilingual support,
• ensures behaviour consistency between various operating systems,
• features native look and feel,
• has active community and multiple-vendor support.
3.5.1. Eclipse RCP Architecture
Figure 3.6. Eclipse RCP Architecture
Eclipse RCP architecture (figure 3.6) consists of following the core elements:
• EquinoxEquinox [17] is Eclipse implementation of OSGi framework compliant with the newest OSGi
specification. It enables an application to be composed from a flexible set of small elements
called plugins or bundles. Equinox defines standards for an application lifecycle model, execution
environment, modules and OSGi services management. Moreover, it provides standard set of APIs
and services in order to reduce the amount of developer work.
• Core platformThe intention of Core Platform developers was to create a runtime engine that manages platform
base and eclipse plugins. It is responsible for defining detailed bundles structure, starting main
application, maintaining registered plugins list and managing extension points. Moreover, the
core platform gives standardized logging utilities, extensive debugging support, security privileges
control and impressive concurrency support.
• Standard Widget ToolkitStandard Widget Toolkit (SWT) [18] is a standardized graphical toolkit used by Eclipse which
was originally developed by IBM. The main goal of SWT is providing common and standardized
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
3.5. Eclipse Rich Client Platform 34
graphical interface that can be executed on various operating systems and environments without
need to modify the source code of ported application. SWT claims to have higher performance and
lower resource requirements than Swing. The native look and feel was also added to standardize
look between platforms.
• JFaceJFace is a toolkit supporting various programming tasks connected to GUI development based on
model-view-controller pattern. For example, JFace provides standardized set of viewers, actions,
image registries, standard dialog windows and so on.
• Eclipse IDE WorkbenchEclipse IDE Workbench provides standard UI environment with perspectives, views, workspace,
editors and projects management.
There are several additional arguments in favour using Eclipse RCP in the constructed monitoring
system. Most importantly Monitoring Console is a part of AS3 Studio which is based on Eclipse RCP.
Moreover, Eclipse RCP is OSGi based which gives all OSGi advantages and allows to share components
with other Business Process Monitoring Platform elements. Finally, as Eclipse RCP provides common
visual component, behaviour and user interface concepts which are widely used in various applications,
most notably in Eclipse IDE. Using that platform decreases development overhead for providing UI
application and facilitates shorter product adoption as users are familiar with the UI platform.
This chapter outlined the major technologies that are the foundation of the presented system. Without
good understanding of the available software components, the system development would be much more
burdensome. The choice of the applied software technologies was partly defined by the fact that Business
Process Monitoring Platform is a part of AS3 Studio. It had to be taken into consideration when selecting
other technologies and designing the system architecture.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4. System Architecture and Design
In this chapter, architecture and design considerations of the Business Process Monitoring
Platform are discussed . First, the assumptions and system requirements that directed the system design
are introduced. Then, a general view of the system architecture is presented. Finally, the selected
system elements’ architecture is more completely described. The discussed topics are: Communication
Layer Extensions, BPM Engine Monitor, Architecture of Rule-based Event Processing and Monitoring
Console.
4.1. Design Assumptions
The proposed monitoring approach leverages the fact that business process(in this case BPEL
process) definition is more than a simple blueprint for orchestrating process components. It
contains process variables and structured activities that have business names and meanings. Such
meta-information, combined with process execution monitoring data, could be effectively presented to
non-technical business users, enabling validation of process execution from the business perspective.
An additional vital assumption that can help to construct functional business process
monitoring solution comes from investigating how business process execution platforms are deployed
in an enterprise infrastructure. It is unlikely that business process engines are standalone components,
but more often they constitute a larger service oriented infrastructure. The consequence is that,
there will be multiple business process components, often heterogeneous, which may form some
interaction topology. Comprehensive business process monitoring solution not only should facilitate
single component behaviour monitoring, but, more importantly, should allow to take a wider look on
business process interaction in the entire SOA environment.
With aforementioned remarks on business process monitoring, it seems clear that an integrated
solution, which allows to monitor business process environment from both business and technical
perspective, is highly desirable. At best, such a solution should also be extensible to adjust to changing
and growing needs in SOA based systems and integrate with other components for SOA solution
stack monitoring. Importantly, monitoring solutions for SOA and, in that case, for monitoring business
processes, should follow the service orientation paradigm and be built upon compliant technology
stack that form SOA-based systems. This approach not only does alleviate integration of monitoring
components with the monitored system, as SOA paradigm encourages loose coupling and autonomy,
but also releases us from the problem of technology impedance mismatch that may occur on the joint
35
4.2. System Requirements 36
between conceptually different technologies. AS3 Studio is a good example of such a system built atop
Enterprise System Bus which is a spine of many SOA solutions. Business Process Monitoring Platform is
a part of AS3 Studio, thus it follows these principles.
Though this thesis focuses on BPEL business processes, other business process formal notations and
their execution platform share many concepts and, by design, Business Process Monitoring Platform is
not limited to BPEL processes monitoring only.
4.2. System Requirements
In this section, the most important functional and non-functional requirements for the designed
system are characterized.
4.2.1. Functional Requirements
This work part presents functional system requirements that describe what functions the designed
system will provide for the users. The list of requirements is followed by the specification of the most
important system use cases.
Required System Functions
The designed system will provide the following functionality:
• System will allow to monitor business process execution in various execution platforms, primarily
focusing on BPEL processes.
• System will allow to dynamically detect business process platforms and deployed business
processes in the provided environment.
• System will provide configuration data and runtime status of business process related components.
• System will allow to browse and visualise discovered business processes.
• System will allow to selectively choose interesting processes and set them for execution
monitoring.
• System will notify and list executed process instances and dynamically visualise process execution
paths.
• System will provide status information concerning entire process and particular process steps
(activities).
• System will provide statistics concerning execution time of processes and process elements.
• System will allow to persist monitoring configuration and results.
• System will allows to conveniently filter out unnecessary pieces of information.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.2. System Requirements 37
• System will provide access to business process variable values and history of the value changes
during process execution.
• System will offer abilities to monitor and analyse the business process execution from business
prospective, namely will allow to detect the following process execution situations:
– process variable values that meet the defined criteria e.g threshold value, frequency, absence
etc,
– status changes of process instances and activities,
– correlated execution of process and process activities in various processes,
– time dependencies between processes,
– process changes that satisfy the defined time constraints or occur in the specifies time
window,
– combination of all the above.
• System will provide GUI application that offers business process monitoring functions.
Main Use Cases
The diagrams 4.1 and 4.2 presents general system use cases from the perspective of two system target
users: IT specialist and business analyst.
IT Specialist
Business processinfrastructure discovery
Performance analysisof business process execution
Configuration of business processmonitoring components
Business processvisualization
Defined business processconditions tracking
«include»
«include»
Figure 4.1. IT specialist use case diagram
Name: Business process infrastructure discovery
Actor: IT specialist
Initial conditions: There exists infrastructure with business process execution engines and components
for business process analysis
Success condition: IT specialist listed available components, their structure and relevant information.
Main Scenario:
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.2. System Requirements 38
Business Analyst
Business process discovery
Business processvisualization
Business processvariable tracking
Defined business processconditions tracking
«include»
Figure 4.2. Business analyst use case diagram
1. IT specialist connects Monitoring Console to monitored infrastructure.
2. IT specialist opens a view that displays business process related elements available in the
infrastructure.
3. IT specialist can list processes deployed in execution engines and configuration of discovered
modules.
Name: Business process visualization
Actor: Business Analyst, IT Specialist
Initial conditions: Business process is discovered. Monitoring Console can receive process execution
progress data from process execution engine.
Success condition: Business process was executed. Monitoring Console was notified on process
execution progress. Execution path was visualized in Monitoring Console and continuously updated
with process progress.
Main Scenario:
1. User list available business processes.
2. User sets selected process to monitoring mode.
3. Process is being executed.
4. User can see a new process execution instance of the selected process.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.2. System Requirements 39
5. User opens a graphical viewer that show process structure with dynamically updated process
activities that were executed for that process instance.
6. User is provided with a list of steps and changes that occurred during process execution.
Name: Business process conditions tracking
Actor: Business Analyst, IT Specialist
Initial conditions: Business process is discovered. Monitoring Console can receive process execution
progress data.
Success condition: User was notified when the described conditions of business process execution where
met.
Main Scenario:
1. User selects interesting business processes.
2. User describes interesting state of business process execution(or correlated execution of many
processes)
3. User configures system to monitor selected processed for the described conditions.
4. Process is executed and the described conditions are met.
5. User is notified that and by which process the conditions were satisfied.
Name: Performance analysis of business process execution
Actor: IT specialist
Initial conditions: IT specialist can execute Business process visualization and Tracking of the definedbusiness process conditions use cases.
Success condition: IT specialist obtained process execution performance metric result.
Main Scenario:
1. IT specialist executes uses case Business process visualization.
2. IT specialist can see, in dedicated viewer, processing time for instances and process activities.
Alternative Scenario:
1. IT specialist defines process execution conditions that test performance (e.g average time between
process start and end).
2. User executes use case Business process conditions tracking with created conditions.
Name: Business process variable tracking
Actor: Business analyst
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.2. System Requirements 40
Initial conditions: Business analyst discovered business process, knows its variables and can execute
and Business process conditions tracking use case.
Success condition: Business analyst informed when variable value meets the stated conditions.
Main Scenario:
1. Business analyst defines variable conditions that should be checked.
2. Business analyst executes use case Business process conditions tracking with created conditions.
4.2.2. Non-functional Requirements
Non-functional requirements mainly come from the external systems which Business Process
Monitoring Platform has to cooperate with. These requirements impact the architecture of the presented
system.
Main non-functional requirements are:
• System has to use OSGiMM even driven communication for monitoring purpose.
• System has to extend OSGiMM mechanism to suit business process monitoring and efficiently
manage the transmitted data.
• Main infrastructure nodes that have to be discovered by the system are defined by OSGiMM.
• System uses possibly the least intrusive way to extract monitoring data from business
process platforms.
• System is extensible for new business process platforms, the system architecture and implemented
components should facilitate creation of the system extensions
• Business Process Monitoring Platform is a part of AS3 Studio and has to follow implementation
and branding policies of that product.
• System uses Eclipse RCP for construction of user interface as the rest of the AS3 Studio.
• System user interface has to be intuitive and provide necessary helpers, templates and hints for
efficient business process monitoring.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.3. High Level Architecture 41
4.3. High Level Architecture
In this section general system architecture is presented to provide better system understanding before
moving to the more detailed system elements description.
The proposed monitoring solution abandons the popular concept of extending business process
engines with a dedicated monitoring console. Instead, it exploits a data bus architecture which enables
different, multi-vendor engines to be connected by exchanging well defined messages through dedicated
connectors.
To satisfy requirements for the Business Process Monitoring Platform, especially the one concerning
its distribution, extensibility and availability it has been decided to build the system based on ESB
supported by OSGiMM as a common, standard mechanism for discovery and management of federated
ESB systems components. The more detailed description of both ESB and OSGiMM can be found in the
respective sections 3.2 and 3.3.
The designed system is an event based solution where execution of each business process element
brings a piece of information allowing to create a trace of orchestrated process execution. These pieces
of information are events based on the standardized Common Base Event (CBE) model [25]. Effective
distribution of the events across the system is facilitated by OSGiMM.
As for the component model used to organize the system, all application modules are OSGi bundles
deployed in the distributed environment based on ServiceMix or, in case of GUI Monitoring Console, in
Equinox OSGi container.
4.3.1. Main System Elements
The core elements of the Business Process Monitoring Platform presented in figure 4.3 are:
• ESB with OSGiMM - the element that will provide seamless integration of system components,
their discovery as well as the communication layer with the required functionality (chapter 3.3),
• Monitoring Domain - a specification of hierarchical component types that can be discovered
and monitored. The business process monitoring domain is called BPEL Domain. Runtime
configuration of BPEL Domain elements form BPEL Domain Monitoring Topology, referred
as BPM topology or simply topology. Monitoring Domain consists mainly of business
process engines with their respective sensors - BPM Engine Monitors, business processes,
independent event processing components - BPM Rule Event Processors and infrastructure nodes
these elements are deployed on.
• Monitoring Console - GUI system element that enables configuration of the monitoring system
and presents key system functions to the user.
Business Process Monitoring Platform was designed with service orientation principles in mind -
with loosely coupled elements integrated with Enterprise System Bus. The big picture is that there are two
types of clients connected using ESB. These clients are event sources, mainly business process engine
specific monitors (BPM Engine Monitors), on the one side and event consumers, e.g. Monitoring
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.3. High Level Architecture 42
Consoles, on the other side. BPM Rule Event Processors are hybrids of these two client types, they
intercepts the flow on events from other event sources to Monitoring Console for the purpose of event
processing. Each element of the system can be perceived as a service with interfaces expressed in terms
of produced and consumed events. When event consumer becomes available via ESB it declares, using
OSGiMM mechanisms, which events and from what BPEL Domain Monitoring Topology fragment
should it receive. OSGiMM mechanism for subscribing for system events, which was adapted to BPEL
Domain (section 3.3) is presented in section 4.4 and section 5.3.
Figure 4.3. Business Process Monitoring Platform -High Level Architecture
Advanced implementation of ESB uses event type and topology shape information to intelligently
route events to interested subscribers complying to the imposed restrictions on accepted events. Such a
communication layer greatly enables building large scale, highly configurable and filterable events driven
systems like the presented monitoring solution. Communication mechanisms provided by ServiceMiximplementation of ESB together with OSGiMM is later referred as ESB Communication Layer.
Each monitored business process engine is equipped with a dedicated monitor that generates
standardized events notifying on the executed process changes. ESB Communication Layer is responsible
for propagation of events and filtering them out if no subscriber is interested in a particular kind of event.
Monitoring Console is a user centric GUI application which subscribes to ESB Communication
Layer for the events concerning selected BPEL Domain Monitoring Topology elements, mainly business
processes. Upon event reception it dynamically visualizes the process progress and updates the process
statistics.
An alternative route for events before reaching Monitoring Console is to be processed by BPM Rule
Event Processor. BPM Rule Event Processor processes the events from other system elements using user
supplied rules. When the rule conditions are matched, it generates events to the monitoring system. The
rules can be quite complex and may refer to semantics of the executed business process and time-based
dependencies of events.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.3. High Level Architecture 43
4.3.2. Monitoring Process
Figure 4.4. Monitoring Process
To get better understanding of the way the monitoring framework works, generic monitoring scenario
(figure 4.4) is presented.
First, as business processes, their execution platforms and other business process related components
exist in some undisclosed infrastructure, the primary function of Business Process Monitoring Platform is
the discovery of those elements and their connection topology. Monitoring Console can display topology
structure and provide information about particular topology elements.
Then, when the possible data sources are known, Monitoring Console can be configured to monitor
interesting topology elements. The user selects topology fragment and Monitoring Console subscribes
to the system for changes in the selected topology elements. In the subscribed state, particular topology
fragment is monitored and console collects events concerning mainly topology changes and execution of
business processes.
When the process instance is executed, Monitoring Console can visualize each process instance
progress by dynamically highlighting completed process elements on the base process model view. The
detailed progress status and collected events are available for analysis and process statistics can be viewed
on the provided charts.
Finally, the user may create rules for detecting more business specific conditions in the executed
process and configure rule-based event processors, that are available in the topology, to test exchanged
events against these rules. Alternatively, those rules can be used to analyse collected events with
Monitoring Console’s build-in event processor. Events generated when the user’s rules are matched,
can be viewed and filtered in a dedicated viewer. This rule-based event processing allows to build more
business specific knowledge of the executed processes.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.4. Communication Layer Extensions 44
4.4. Communication Layer Extensions
This section describes ESB Communication Layer enhancements for business process monitoring.
The main concepts that are subject of extension and implementation are: the monitoring domain (4.4.1)
and event subscriptions (4.4.2).
4.4.1. Monitoring Domain Extensions
Monitoring Domain defined by OSGiMM is a collection of components and resources interacting to
realise a goal of business process monitoring. OSGiMM uses the domain concept to separate concerns
of SOA system monitoring. For the purpose of business process monitoring a new domain called BPEL
Domain has been introduced. (BPEL name refers to the early stage of the research and implementation,
where only the BPEL processes where subject of the research interest). The specification of the new
domain comprises event types that are exchanged in the domain, the domain topology definition and
implementation of the domain specific agents existing on each infrastructure node.
Business Process Monitoring Events
For the propagation of business process monitoring data in the presented system there will be
introduced two event categories carried by OSGiMM’s CBEs:
• Business processes with all dependent entities such as XML definition files deployed in business
process engine, business process execution history and information about those data changes
belongs to topology category.
• Monitoring category concerns information related to the process execution state change, the
variable value change, web service calls, evaluation failures and exceptions. Monitoring data
enables the console to recreate the business process execution path for the purpose of business
process visualization and analysis.
Monitoring and topology data are propagated across the system in form of atomic pieces of
information called monitoring and topology events. Detailed classification of the topology and
monitoring events is described in section 5.2.
Domain Structure
In OSGiMM, the concrete domain structure is defined by that domain’s implementers. The domain
structure used for the propose of business process monitoring is aimed to reflect potential deployment
of business process related elements in the adaptive SOA infrastructure. There exist elements that are
deployed per infrastructure node - BPM Containers and per business process execution environment -
BPM Engine Monitor or BPM Rule Event Processor.
The components that constitute BPEL domain are:
1. BPM Container - which is created per deployment of OSGiMM on each infrastructure node,
2. Business process execution engines and their respective BPM Engine Monitors,
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.4. Communication Layer Extensions 45
3. Deployed business processes,
4. BPM Rule Event Processors with their rule configurations.
The hierarchy of BPEL domain elements is presented in figure 4.5.
Figure 4.5. BPEL domain hierarchy
BPM Engine Monitor
BPM Engine Monitor is the one of the most important elements of BPEL Domain topology. It
provides a bridge between the process execution environment and the monitoring system. The main
responsibilities of BPM Engine Monitor are:
• enabling business process monitoring by generating events on process execution progress,
• contributing to the domain topology by providing a list of processes deployed in the monitored
engine.
4.4.2. BPM Subscription Extensions
OSGiMM’s subscription concept is similar to the publish/subscribe approach commonly used by
JMS [14]. First, the system endpoints, from which data is going to be collected, need to be defined, then
subscription is registered in ESB Communication Layer and, in effect, the data generated by publishers
is automatically propagated to interested subscribers.
OSGiMM offers developers a differentiated set of subscriptions which falls into two categories:
• Topology Subscription which defines target topology and collects topology change information.
• Monitoring Subscription that defines topology targets of the subscription and creates channels for
propagating monitoring data.
Both of these categories have to be extended to suit the purpose of business process monitoring. The
roles of these two subscription types in Business Process Monitoring Platformare described later in this
section.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.4. Communication Layer Extensions 46
Figure 4.6 presents the standard approach, where a monitoring tool registers custom listeners for each
process engines and then, it is flooded by the monitoring data from all the processes.
Figure 4.6. Traditional monitoring of business processes
On the contrary, figure 4.7 presents an example of a well structured BPEL Domain Monitoring
Topology that is managed by OSGiMM that allows to subscribe selectively for monitoring data from
interesting topology fragment.
Topology Subscription
Topology subscription is used to gather information about topology elements state changes,
specifically when a new container, component, business process are deployed. When such a change
occurs in the topology, relevant topology events are passed to receivers (mainly Monitoring Console)
through the channel created by receiver’s topology subscription. In the presented system, topology
subscriptions are further differentiated on the basis how detailed topology data they will provide. Most
often, only component identifier, type and children list is needed to present a general topology view,
however for more exhaustive element analysis, detailed descriptions of the topology elements have to be
send. For both of these cases, specific topology subscriptions are introduced for more efficient utilization
of ESB Communication Layer resources.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.4. Communication Layer Extensions 47
Figure 4.7. BPM Domain Monitoring Topology with selective subscriptions
Rarely does user is interested in monitoring of the entire topology. Topology subscription is extended
with a convenient mechanism of restricting its topology scope. This allows to precisely define which
topology elements are subject to topology monitoring.
Monitoring Subscription
Monitoring Subscriptions are used to create main informative channels that carry events concerning
the process execution and rule-based event processing. Similarly to topology subscriptions, monitoring
ones can be also restricted to some topology fragment.
There are two categories of the monitoring subscriptions:
• Process Subscription that allows to perform monitoring of business processes contained within
specified topology.
• Rule Monitoring Subscription that configures BPM Rule Event Processor to collect events from
other components and send the processing results to the subscribers.
This section explained how existing mechanisms for event driven communication, which are
provided by OSGiMM, can be extended to monitor a new aspect of the adaptive SOA system, namely
business processes. Extensible nature of OSGiMM allowed to introduce the new monitoring domain
which structure, events and subscriptions correspond to the nature of monitored elements.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.5. Architecture of Rule-based Event Processing 48
4.5. Architecture of Rule-based Event Processing
The presented business process monitoring system is also targeted for more business specific process
data analysis. To meet this requirement, the system design includes the application of rule-based event
processing which is supposed to provide expressive and flexible means of business process execution
analysis. The user should be able to provide business rules that describe a certain state of the process
execution. Rules can be used to discover e.g.:
• process execution failures and delays,
• rare and unused process execution paths,
• correlated executions of the processes, instances and activities,
• process variable values that satisfy the defined conditions,
• aggregated occurrences of all these conditions over a given period of time (e.g. average variable
values, frequent process activity failures).
These discovery features highly depend on the adopted event processing engine capabilities. The
presented monitoring framework does not impose the format of the rules nor concrete event processing
engine implementation. Ultimately, the system can support various rule-based event engines and their
respective rule types. Noteworthy, the application of CEP (section 3.4.2) processors is highly suitable for
the purpose of business process monitoring and presented system will use Drools Fusion [29] CEP event
processing engine as a reference solution.
4.5.1. Remote Event Processing
In the presented Business Process Monitoring Platform architecture, BPM Rule Event Processors are
BPM Components that exist in BPEL Domain. Various event processors may be deployed and distributed
across the nodes of the Monitoring Topology. Each event processor can be configured by providing
user-defined Rule Monitoring Definitions that consist of:
1. a set of business rules that are used to process incoming events,
2. definition of the topology fragment from which events will be collected.
BPM Rule Event Processor can be provided with many Rule Monitoring Definitions. For each
definition, the event processor subscribes to ESB Communication Layer for events from the given
topology fragment. The incoming events are processed by the Event processing engine and RuleMachted
monitoring events are generated and sent to the registered subscribers. Rule Monitoring Definition and
the events processor are topology elements and the user may use available mechanisms to subscribe for
events from a concrete Rule Monitoring Definition in the same fashion as for events from a business
process. Monitoring Console will provide a convenient interface to facilitate rule-based monitoring (see
section 4.6.4).
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.5. Architecture of Rule-based Event Processing 49
Figure 4.8. Rule-based event processing
RuleMatched events are also the monitoring events and they could be further processed by other
event processors. The user may define chains of event processors that filter, analyse and process incoming
events. The general architecture of the solution is presented in figure 4.9.
An application of rule-based event processing in business process monitoring with the proposed
architecture can bring many advantages:
1. Monitoring Console is released from the burden of event processing and becomes more
lightweight.
2. The number of events sent through ESB Communication Layer may be significantly reduced and
scalability of the platform is improved. Shared Rule Monitoring Definitions that gather and analyse
data from the topology fragment may be defined and many subscribers can use them as event
sources. ESB Communication Layer guarantees that events are not unnecessarily duplicated.
3. Event processors can work independently from Monitoring Console and one can implement event
subscribers that collect monitoring data from them for later offline analysis.
4. The user can precisely define what state of the business process execution is particularly interesting
and receive only important events.
4.5.2. Rule Registry
BPM Rule Event Processor can be simultaneously used by many Monitoring Consoles. When one
Monitoring Console creates Rule Monitoring Definition, other consoles need an access to the used rule
definitions. Additionally, different rules with the same name may exit in the system, thus rule coherence
problems may occur when one user uses modified versions of the rule with the same name. To allow rules
sharing between components of Business Process Monitoring Platform and manage rules consistency,
Rule Registry has been introduced. It serves as distributed repository of Business Rules. Each Business
Rule is identified by Business Rule Description that consist of a rule name, description, revision number
and checksum.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.5. Architecture of Rule-based Event Processing 50
Figure 4.9. Business process monitoring enhanced with rule-based event processing
Prior to being used by other remote components, a rule has to be deployed to the Rule Registry. The
rule identifier is given a revision number that differentiates that rule from all the other rules with the same
name but a different content.
Within the monitoring system only the rule identifiers are exchanged between the system components
and, when needed, the remote components fetch the respective rule definitions from the Rule Registry.
Rules deployed to Rule Registry are immutable and deploying a modified rule to the registry returns
the identifier with increased revision number. This behaviour is necessary because various elements of
the system can use different versions of the rule at the same time and the user allows has to have clear
information which rule version is used by the particular system element.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.6. Monitoring Console 51
4.6. Monitoring Console
This section covers the architectural decisions and design of Monitoring Console - a user centric
application for business process monitoring.
The primary architectural decision concerning Monitoring Console is that the application is based on
Eclipse Rich Client Platform, described in section 3.5.
Initially, it was supposed to support BPEL processes only, but later the system was redesigned to be
open for other business process environments and components associated with business process analysis
(e.g rule-based event processing). As a result, the extensible architecture of Business Process Monitoring
Console was proposed which is presented in figure 4.10.
Figure 4.10. Monitoring Console components
4.6.1. Monitoring Console Core Elements
Monitoring Console core elements is a set of modules that define key Monitoring Console’s features.
The role of each element is briefly described in this subsection.
AS3 Studio Integration Elements
Monitoring Console can be launched as a part of AS3 Studio and they share common elements, such
as connector to ESB Communication Layer. Another point of integration is following and contributing
to AS3 Studio extension points concerning consistent naming and common menus.
Communication & Console Subscription Management
ESB Communication Layer provides ability to subscribe for specified events from some topology
fragment by registering a custom listener. Taking into consideration that Monitoring Console should:
1. be suitable for both offline and online monitoring,
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.6. Monitoring Console 52
2. allow to create and modify subscriptions conveniently,
3. which are persistent between ESB Communication Layer disconnection times,
the communication component was designed that handles and enhances OSGiMM subscription
mechanisms for the purpose of business process monitoring and, additionally, hides details of
subscription management. Implementation description can be found in section 5.4.1.
Topology Management
Topology Management is a vital component of Business Process Monitoring Platform. It consists of
the three base elements:
1. Topology Builder Service - provides an API to query for topology elements and is responsible for
notifications about topology changes.
2. Topology Viewer - visualises hierarchy of available BPEL Domain topology elements, allows to
create monitoring project based on selected topology elements.
3. Topology Editor - visual editor for creating topology constrains restricting the scope of process
monitoring.
Monitoring Project Management
It was a very important issue to determine how the user will interact with Monitoring Console during
the monitoring process. Monitoring Console should allow a user to perform simultaneously independent
process monitoring with different configurations and to persist monitoring results. It was decided that,
similarly to many monitoring environments and integrated studios, monitoring will be organized into
projects named BPM Monitoring Projects. Such a solution is facilitated by the Eclipse RCP platform
which provides framework for creating projects and storing project resources.
The BPM Monitoring Project is responsible for providing the following features:
• enables declaration of the monitored topology fragment during project creation and supports its
adjustment after the project is created,
• persists project configuration together with monitored topology shape definition,
• displays topology elements highlighting topology active elements,
• persists all topology elements that matched topology shape definition for offline analysis,
• persists topology events and monitoring events (e.g. for processes, instances and Rule Monitoring
Definitions),
• persists process related documents e.g. process definition files,
• is extensible by project extensions allowing to store additional resources e.g. Business Rules.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.6. Monitoring Console 53
Monitoring Navigator is a visual component that displays available projects and their structure. It
provides extension points for registering actions that can be performed on the project elements. The
custom component for displaying monitoring structure is required because, unlike standard Eclipse
project, BPM Monitoring Project lists mainly virtual (not existing as eclipse workspace resource)
elements and standard actions provided by Eclipse project viewer are not relevant and they would dim
simplicity of actions used for business process monitoring.
Common Elements & Helpers
This is a set of modules that provide commonly used elements in the Monitoring Console and helpers
that facilitate use of Eclipse RCP Framework. The most notable elements are:
• visual components for displaying various type of data: events, rules,
• interfaces and abstract classes of common modules that are extended by concrete modules,
• shared implementations of Eclipse RCP interfaces,
• helper convenience methods to use Eclipse RCP e.g. accessing selections, opening editors,
• helper methods for accessing elements provided by Monitoring Console e.g. access to system
services or monitoring workspace elements.
4.6.2. Monitoring Console Extension Points
Supporting new BPM Components
Initially Monitoring Console was designed to support only BPEL Processes, but with time new
monitorable elements were added e.g BPM Rule Event Processor and there are attempts to introduce
jPDL [30] process support. As a result, monitoring framework was redesigned to be easily extended with
new process monitoring related modules.
Support for new business process execution environments and other event sources can be added to
Business Process Monitoring Platform by creation of the new BPM Components that are added to BPEL
Domain and are display in the Topology View. Such components would normally be custom BPM Engine
Monitors or BPM Rule Event Processors.
However, when creating a monitoring project, different component types may require to be handled
differently e.g.:
1. for BPEL Component process definitions files need to be stored and children process instances
have to be listed,
2. for Event Processor Component Rule Monitoring Definitions and collected RuleMatched events
have to be persisted,
3. each component may require different labels and icons (custom Eclipse RCP LabelProvider),
4. each component may have different children structure (custom Eclipse RCP
ContentProvider).
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.6. Monitoring Console 54
To meet these conditions Monitoring Console provides extension points for new BPM Components based
on OSGi services. More details can be found in section 5.4.3.
Supporting additional resources
There is also a requirement for the monitoring project to be able to store and display additional
resources of various types e.g business rules. Mechanism based on Eclipse RCP extension points
providing project extension functionality is described in section 5.4.3.
4.6.3. BPEL Monitoring Console Component
The presented system component is aimed to provide BPEL process monitoring capabilities for
Monitoring Console. BPEL monitoring component is integrated with the console by the extension
mechanism described in section 4.6.2.
BPEL monitoring component enables inclusion of BPEL related topology elements in the monitoring
project:
1. BPM Engine Monitors,
2. BPEL Processes (with their definitions and collected monitoring events),
3. BPEL Process instances.
BPEL monitoring component provides Monitoring Console with:
1. ability to open BPEL monitoring elements in dedicated editors and viewers,
2. ability to subscribe for specified BPEL process monitoring events,
3. BPM Engine Monitor viewer providing engine’s statistics and summary information,
4. process and instance viewers displaying visual representation of the process and providing a list of
collected events,
5. a process instance viewer displaying executed processes activities and dynamically changing with
incoming events,
6. viewers providing aggregated list of processes, instances and instance activities for each element.
4.6.4. Rule-based Event Processing in Monitoring Console
Monitoring Console is extended with a group of modules that facilitate rule-based event processing
using both independent BPM Rule Event Processor and Monitoring Console’s build-in event processors.
Rule-based Event Processing modules the following topology elements to be included in the monitoring
project:
1. BPM Rule Event Processors,
2. Rule Monitoring Definitions.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
4.6. Monitoring Console 55
Monitoring Console is provided with:
1. ability to open rule monitoring elements in dedicated editors or viewers,
2. BPM Rule Event Processor viewer that allows to list, create, remove, enable and disable Rule
Monitoring Definitions,
3. Rule Monitoring Definition viewer which lists RuleMatched events matched by given business
rules in the selected topology scope,
4. Rule Registry viewer that lists rules deployed to the remote Rule Registry,
5. project extension for managing local rule resources,
6. wizards and templates for creating new rules,
7. ability to deploy local rules and download them from Rule Registry,
8. custom rule editors,
9. ability to locally analyse collected events with Monitoring Console’s build-in event processing
engine.
Apart from event analysis, an additional motivation for enabling in-console event processing was to allow
the user to test the rules before they are deployed to the remote event processor. It should greatly improve
process of creating and testing new rules and reduces risk that rules will fail in distributed environment.
In this chapter, architectural concepts and decisions that lead to the implementation of Business
Process Monitoring Platform were discussed. It was underlined that a good solution for the problem of
comprehensive business process monitoring requires advanced architecture and careful design. It was
presented how the existing software component can be extended and what new elements need to be
implemented to provide the required system functionality.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5. Implementation
This chapter is indented to describe Business Process Monitoring Platform implementation. Though
the system has good module-responsibility decomposition, the number of components is considerable
and, at times, their internal structure may be quite complex. As a result, detailed description of every
system elements is not provided, but only the most important or particularly interesting implementation
fragments are covered.
The chapter has been divided into the following sections:
• BPEL Monitoring Domain covering implementation of BPEL Monitoring Domain,
• Events Hierarchy presenting event model used in the presented system,
• Subscription Implementation illustrating how OSGiMM subscriptions were integrated,
• Monitoring Console focusing on Eclipse RCP-based monitoring console,
• Rule-based Event Processing where implementation details of this system element are revealed,
• Integration Testing presenting solution that do not constitute directly Business Process
Monitoring Platform, but was crucial for building of the more mature and stable system.
5.1. BPEL Monitoring Domain
This section outlines the construction of the elements that form BPEL Domain Monitoring Topology.
First, the hierarchy of the elements that may exist in the domain is presented, then more information is
given on existing topology elements.
BPEL Domain topology elements form tree-like structure and topology class structure follows
composite design pattern presented in figure 5.1. ITopologyElement is an interface which all the
topology elements need to implement, and its implementations will provide:
name - which is a simple element name (for example monitoring engine name, deployed process name,
etc.).
path - which is used to uniquely identify topology elements. The path consists of topology element
predecessors in the tree structure,
56
5.1. BPEL Monitoring Domain 57
list of children - which is a list of ITopologyElement children of the element, it enables creation
of the tree-like structures,
Such a solution greatly simplified implementation and enabled code to be more generic by treating all
topology elements in an uniform manner.
ITopologyElement
+getChildren(): List<? extends ITopologyElement>+getPath(): List<String>+getName(): String
BPMContainer
BPMComponent
EventProcessorEngineMonitor
BusinessProcessDescription RuleMonitoringDefinition
Figure 5.1. Topology elements class diagram
The provided topology element are as follows:
• BPM Container is a topology element that manages instances of various BPM Component. By
design, there is one-to-one correspondence of BPM Container and ServiceMix instances.
• BPM Component is an abstract, generic domain element that represents functional components
that can deployed in the BPM Container. Currently implemented BPM Component types are BPM
Rule Event Processor and BPM Engine Monitor.
• BPM Engine Monitor gathers monitoring data related to the deployed business processes
execution.
• BPM Rule Event Processor represents entity responsible for various types of monitoring event
processing.
• Business Process Description corresponds to a process deployed in a business process execution
engine.
• Rule Monitoring Definition represents configuration of BPM Rule Event Processor.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.1. BPEL Monitoring Domain 58
1List<String> bpelTopologyStr = bbAgent.retrieveDomainTopology("BPEL");
2for (String bpelContainerStr : bpelTopologyStr) {
3BPMContainer newBpm = (BPMContainer) ApiJAXBBpel.getInstance().
4unmarshallContainer(bpmContainerStr);
5}
6}
Listing 5.1. Retrieving topology state
The current domain topology state can be retrieved from OSGiMM backbone agent using the
following code snippet (listing 5.1):
The construction of the main BPEL Domain elements is described in the following sections.
5.1.1. BPM Container
BPM Container is a topology component which is responsible for management of the
OSGiMM subscriptions and OSGiMM remote listeners in BPEL Domain. BPM Container is available on
each business process monitoring enabled instance of ServiceMix. It controls and provides access to the
ESB Communication Layer for various BPM Components running within the same ServiceMix instance.
Within ServiceMix instance, it is capable to dynamically discover BPM Components. When a new
component is found by ComponentServiceTracker, BPM Container automatically forwards all
the relevant, active subscriptions to the newly registered BPM Component. Additionally, BPM Container
provides statistics collection mechanism related to subscription events. Example implementations of
BPM Component are ApacheODE Engine Monitor (BPM Engine Monitor) and BPM Rule Event
Processor which are further described in section 5.1.3 and section 5.1.4
Implementation remarks
Class diagram presented in figure 5.2 presents building elements that form BPM Container.
According to OSGiMM guidelines, domain’s agents that are responsible for processing
subscriptions and providing domain topology structure have to be implemented. In BPEL Domain,
BPMMonitoringAgent and BPMTopologyAgent serve that purpose. They are implemented
according to OSGiMM developer guide [36].
When subscription is registered in the system, registerMs method is invoked
on BPMMonitoringAgent or BPMToplogyAgent depending on type of the
subscription. BPM Container uses TopologySubscriptionProcessor or
MonitoringSubscriptionProcessor to verify whether that container matches the target
topology of the subscription. If the condition is satisfied, subscription is added to BPM Container’s
SubscriptionRegistry and ignored otherwise. In the next step, BPM Container processes all
the registered BPM Components trying to match target topology of the subscription against the BPM
Component’s partial topology. If the BPM Component is within the scope of the target topology, BPM
Container registers the subscription in that particular BPM Component.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.1. BPEL Monitoring Domain 59
ComponentTopologyTracker
BPMMonitoringAgent
MsAgent
+registerMs(MsInstance,MsDefinition,MsEventListener)+unregisterMs(MsInstance)
TopologyAgent
+getAgentDomain(): Set<String>+getDomainTopology(): String+registerMs(MsInstance,MsDefinition,TopologyEventListener)+unregisterMs(MsInstance)
BPMTopologyAgent
TopologySubscriptionProcessor
+registerTs(MsInstance,BPMContainerTopologySubscription,TopologyEventListener topologyEventListener)+unregisterTs(MsInstance )
MonitoringSubscriptionProcessor
+registerMS(MsInstance,BPMMonitoringSubscription,MsEventListener)+unregisterMS(MsInstance)
1
1
1
1
Figure 5.2. BPM Container - Class Diagram
5.1.2. BPM Component
BPM Component is a generic monitoring domain element that represents common functionality of
the components deployed in BPM Container. It contains base classes that can be used to implement BPM
Component with:
• one-way communication (e.g. BPM Engine Monitor), that can only receive subscriptions and send
events to the subscribers,
• two-way communication (e.g. BPM Rule Event Processor), which, additionally, can register their
own subscriptions in the ESB Communication Layer.
BPM Component registration in the BPM Container is based on the OSGi service tracking
mechanisms. BPM Component manifest itself in the system by implementing IBPMComponent
interface and exporting IBPMComponent OSGi service.
The next sections in this chapter talk about two main implementations of BPM Components:
ApacheODE Engine Monitor and BPM Rule Event Processor.
5.1.3. ApacheODE Engine Monitor
ApacheODE Engine Monitor is ApacheODE’s [7] dedicated implementation of BPM Engine
Monitor. One of the main design guidelines for monitoring business process execution engine, is
transparency of the engine monitor. For ApacheODE, there is neither need to instrument the executed
process nor to modify execution engine. Data is collected using two channels exposed by the
ApacheODE:
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.1. BPEL Monitoring Domain 60
• custom implementation of BPELEventListener that is registered in the engine,
which collects execution events [8] and sends them using JMS to ApacheODE Engine
Monitor. These events are received by InstanceEventSubscriber and then passed to
MsEventConverterProcessor which is responsible for transforming ApacheODE events
to the standardized event format described in section 5.2. The converted events are sent by
ApacheODE Engine Monitor to the registered subscribers,
• ManagementAPI [9] that allows to retrieve information about the deployed processes.
ProcessDeploymentTopologyListener periodically pools WSQueryProcessor
which in turn invokes ApacheODE’s ManagementAPI web service that returns a list of
deployed processes. If the list content was changed (e.g. process was added or removed)
ProcessDeploymentTopologyListener triggers an event informing subscribers about
the topology change.
ApacheOde
EventListener
ManagementAPI
ApacheOde Engine Monitor
AbstractBPMAgent
InstanceEventSubscriber
WSQueryProcessor
MsEventConverterProcessor
ProcessDeploymentTopologyListener
ApacheOdeEngineMonitor
Figure 5.3. ApacheODE Engine Monitor - Class Diagram
5.1.4. BPM Rule Event Processor
BPM Rule Event Processor is a BPM Component that provides event processing capabilities. Unlike
BPM Engine Monitor, BPM Rule Event Processor is both an event subscriber and an event source. It
shares BPM Engine Monitor code for handling incoming subscriptions and Monitoring Console-like
mechanism for creating ones to BPEL Domain.
BPM Rule Event Processor provides the implementation of the following functionality:
1. Rule Monitoring Definition registration in BPEL Domain - upon definition registration, Rule
Monitoring Definition is added to monitoring topology as an element of BPM Rule Event
Processor and a respective topology update event is generated.
2. Rule Monitoring Definition activation/deactivation - by default, registered definitions are disabled.
On request, the definition is activated which results in:
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.1. BPEL Monitoring Domain 61
(a) creation of the subscription to topology fragment described in the Rule Monitoring
Definition,
(b) instantiation of the event processing engine that will process events using Business Rule
defined in Rule Monitoring Definition.
On the definition deactivation, subscription is destroyed and event processing engine is disposed.
3. For each Rule Monitoring Definition a separate event processing engine instance is created. BPM
Rule Event Processor listens for RuleMatched events that are generated by these instances and
sends them to registered subscribers using ESB Communication Layer.
The class structure of the BPM Rule Event Processor is pictured in figure 5.4. Sequence diagrams with
Rule Monitoring Definition registration and activation are presented in figure 5.5 and figure 5.6.
Reference implementation of BPM Rule Event Processor uses Drools Fusion event processing
engine, but other solutions that can follow event processing engine contract can be used. Implementation
details of the event processing engine can be found in section 5.5.2.
BusinessRule+content: String+businessRuleDescription: BusinessRuleDescription
«toplogyElement»RuleMonitoringDefinition
+name: String+creator: String+description: String+ruleIdList: List<BusinessRuleDescription>+topology: TopologyDefinition
AbstractTwoWayBPMAgent
IRuleRegistry
+addRule(businessRule:BusinessRule)+removeRule(businessRuleDescription)+getRule(businessRuleDescription): BusinessRule+getRules(): Collection<BusinessRuleDescription>
BusinessRuleDescription
+id: String+contentHash: String+version: String+ruleType: RuleType
BPMEventProcessor
«topologyElement»IBPMEventProcessor
+addRuleMonitoring(ruleMonitoringDefinition)+removeRuleMonitoringDefinition(ruleMonitoringDefinition)+enableRuleMonitoring(ruleMonitoringDefinition)+disableRuleMonitoring(ruleMonitoringDefinition)
IEventProcessingEngine
+addRule (rule:BusinessRule)+removeRule(rule:BusinessRuleDescription)+processEvent(event:MonitoringEvent)+addRuleMatchEventListener(listener:EventListener)+getEngineType(): EngineType
1
1
Figure 5.4. BPM Event Processor - Class Diagram
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.1. BPEL Monitoring Domain 62
:Monitoring Console rmd:Rule Monitoring Definition :EventProcessor :IEventProcessingEngine :ESB Communication Layer
registerRMD
RuleMonitoringDeployedEvent
rmdRuleMonitoringDeployedEvent
enableRMD
«create»epe
addRules(rmd)
subscribeToTopology(rmd)
RuleMonitoringEnabledEvent
RuleMonitoringEnabledEvent
Figure 5.5. Rule Monitoring Definition registration and activation - Sequence Diagram
:Monitoring Console ep:EventProcessor el:RuleMsEventListener epe:IEventProcessingEngine :ESB Communication Layer
RuleMonitoringDeployedEvent
enableRuleMonitoringDefinition
create engine and add rules
epe
createMonitoringEventListener(rmd,epe)
«create»
el
elsubscribeToTopology(el,rmd)
MonitoringEvent
processEvent(me)
RuleMatchedEvent
RuleMatchedEvent
RuleMatchedEvent
Figure 5.6. Event processor - monitoring event processing - Sequence Diagram
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.2. Events Hierarchy 63
5.2. Events Hierarchy
Each change or progress in the business process execution brings a piece of information that allows
to create a trace of the orchestrated process. BPM Engine Monitors, dedicated to the concrete business
process execution engines, convert these pieces of information to events based on Common Base Event
(CBE) standard. These events are the key elements in the system construction and their structure and
carried data define Business Process Monitoring Platform capabilities.
Events used in the system fall into the two categories described in the subsequent sections: Topology
Events (section 5.2.1) and Monitoring Events (section 5.2.2).
5.2.1. Topology Events
Topology events reflect the changes in number and state of BPM Containers, BPM Components,
monitored engines, deployed Business Processes, Rule Monitoring Definitions and other topology
elements. Topology event type characterises a change in the system and the data carried by the event
allows to identify the affected system element, provides that element description and other necessary
data to get the required view of the system state.
Event type Description
TopologyBPEL Base class for all the topology events
ComponentLifecycleEv Abstract class grouping events connected to BPM
Component lifecycle changes
ComponentStartedEv Event is sent after instance of BPM Component
was started. Event is automatically generated by
BPM Container after discovery of new BPM
Component
ComponentStoppedEv Event is sent after instance of BPM Component
was stopped
Process(Un)DeployedEv Event informs about fact of (un)deploying new
business process
RuleMonitoringDefinition(Un)DeployedEv Event informs that new Rule Monitoring
Definition was (un)deployed
RuleMonitoringDefinition{Enabled,Disabled}Ev Event informs that new rule monitoring
configuration was {enabled,disabled}
Table 5.1. Topology events description
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.2. Events Hierarchy 64
TopologyBPEL
ComponentLifecycleEv
RuleMonitoringDefinitionDisabledEv RuleMonitoringDefinitionEnalbedEv
RuleMonitoringDefinitionDeployedEv RuleMonitoringDefinitionUndeployedEv
ProcessDeployedEv ProcessUndeployedEv
ComponentStartedEv ComponentStoppedEv
Figure 5.7. Topology Events - Class Diagram
5.2.2. Monitoring Events
Monitoring events carry the most essential pieces of information about process execution which
enable Monitoring Console to maintain the up-to-date state of the process execution. Events may notify
about process start, end, execution of process activity, process variable changes and rules matched
in BPM Rule Event Processor. Presented event hierarchy is based on the modified events used by
ApacheODE BPEL execution engine [8]. This hierarchy is supposed to be generic enough to support
other business process platforms.
Event type Description
MonitoringEv Base class for all the monitoring events
ProcessEv Abstract class for all events related to the business
process execution
Correlation(No)MatchEv Matching correlation has (not) been found
ProcessInstanceEv Abstract class for the events related to business
process execution
ProcessInstanceStartedEv Process execution is started
ProcessCompletionEv Process execution is completed
ProcessInstanceStateChangeEv The state of a process instance has changed
CorrelationMatchEv Matching correlation has been found upon
reception of a message
NewProcessInstanceEv New process instance is created
ProcessTerminationEv Process instance is terminated
ScopeEv Abstract class for the scope events
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.2. Events Hierarchy 65
Event type Description
ActivityEv Abstract class for the activity events
ActivityEnabledEv An activity is enabled
ActivityExecStartEv An activity execution is started
ActivityExecEndEv An activity execution is terminated
ActivityDisabledEv An activity is disabled
ActivityFailureEv An activity failed
CompensationHandlerRegisteredEv A compensation handler is registered for a scope
CorrelationSetEv A correlation set value has been initialized
ExpressionEvaluationEv An abstract class for the expression evaluation
events
ExpressionEvaluationSuccessEv Expression evaluation succeeded
ExpressionEvaluationFailedEv Expression evaluation failed
ScopeStartEv A scope is started
ScopeCompletionEv A scope is completed
ScopeFaultEv A fault has been produced in a scope
VariableEv An abstract class for the variable events
VariableModificationEv Value of a variable has been modified
VariableReadEv Value of a variable has been read
RuleMatchedEv An event produced by BPM Rule Event Processor
to inform that business rule was matched
Table 5.3. Monitoring events description
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.2. Events Hierarchy 66
MonitoringEv
ProcessInstanceEv
ProcessInstanceStartedEv ProcessInstanceStateChangeEv
ProcessMessageExchangeEv ProcessTerminationEv
ProcessCompletionEv
ScopeEv
ScopeStartedEv VariableEvVariableReadEv
VariableModificationEv
ScopeCompletionEv CorrelationSetEv
ScopeFaultEv ExpressionEvaluationEvExpressionEvaluationSuccessEv
ExpressionEvaluationFailedEv
CompensationHandlerEv PartnerLinkEv
ActivityEv
ActivityDisabledEv ActivityFailureEv
ActivityExecStartEv ActivityExecEndEv
ActivityEnabledEv
Figure 5.8. Monitoring Events - Class Diagram
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.3. Subscription Implementation 67
5.3. Subscription Implementation
As described in section 4.4.2 subscriptions are divided into two categories: topology subscriptionand monitoring subscription. Their details are described in this work part.
5.3.1. Topology Subscription
Topology subscription is used to create data channels in the ESB Communication Layer that are used
to propagate topology events. Business Process Monitoring Platform uses differentiated set topology
subscriptions aimed to provide selective and effective use of communication layer resources. Description
of these subscriptions follows.
BPM Topology Subscription is a base topology subscription used within BPEL domain. Topology
Subscriptions that do not extend this base class are automatically ignored. BPM Topology
subscription can define target topology shape by using topology restrictions described in section
5.3.3
Global Topology Subscription is used to connect to a global virtual channel that gathers information
about all topology changes within domain. When a topology change occurs an appropriate event
is triggered and sent to all registered receivers. By design, events sent within channel created
by Global Topology Subscription should have relatively small size. For example, when a new
business process is deployed then the event notifying on that topology change will contain only
a deployed process name, deployment time stamp and unique topology path and will not provide
business process definition. Motivation for this approach is reduction of the network traffic as in
the considerably vast topology only a few business processes may be a subject of monitoring. The
same approach is used for Rule Monitoring Definitions.
Detailed Topology Subscription complements functionality of the Global Topology Subscription.
Detailed Topology Subscription allows to get detailed data concerning specific topology fragment
elements. For example, it can be used to get Business Process definitions or Rule Monitoring
Definitions when they are needed. When a target topology change occurs, an event containing
detailed topology change is triggered.
5.3.2. Monitoring Subscription
Monitoring subscriptions create data channels used for monitoring events propagation. They use the
same mechanisms as topology subscriptions for monitoring scope restriction, but they are differentiated
with the regard to the carried information types, not their granularity.
BPMMonitoringSubscription is a base class of monitoring subscriptions used within BPEL domain.
All subscriptions have to inherit from BPMMonitoringSubscription otherwise they are
ignored.
BPMProcessSubscription allows to subscribe to monitor a given subset of business processes.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.3. Subscription Implementation 68
BPMRuleMonitoringSubscription is used to configure BPM Rule Event Processor to collect events
from the defined topology fragment which should be processed by the rule-based event processing
engine with a given set of rules.
5.3.3. Subscription Topology Restrictions
All the subscriptions are dedicated to a specific topology. Topology restriction is used to filter out a
subset of the entire topology. The mechanism is based on the hierarchical set of pattern-based restrictions
that refers to various topology elements and types. The restriction class hierarchy is shown in figure 5.9.
Each topology restriction consists of a list of patterns that can be:
• positive - they include matched elements to the topology fragment,
• negative - they exclude matched elements from the monitoring scope, they have priority over
positive patterns.
GenericRestriction+patterns: List<Pattern>
ComponentRestriction
ContainerRestriction
ProcessRestriction
RuleRestriction
Pattern+pattern: String+property: String+positive: boolean+enabled: boolean
Figure 5.9. Topology restrictions - Class Diagram
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 69
5.4. Monitoring Console
In this section the implementation of Monitoring Console which is a major and the largest element of
the Business Process Monitoring Platform is presented. Monitoring Console implementation is based on
Eclipse RCP modularity, leverages Eclipse RCP extension point mechanism and intensively uses OSGi
service platform together with Spring DM. Such an approach provides decreased coupling between
modules and almost out-of-box mechanisms for creating extensible implementation. Component
description follows the same order as in the architecture description (section 4.6) but omits less
interesting components.
5.4.1. Core Elements
In this work part, the implementation of the core Monitoring Console’s elements is presented.
Subscription Management
Subscription management in Monitoring Console was implemented according to the requirements
described in section 4.6.1. The class structure of this console element is presented in figure 5.10. The
roles of the most important classes are then specified.
Figure 5.10. Console Communicator - Class Diagram
Console Subscription hides complexity of creating, enabling, updating and disabling
OSGiMM subscriptions. The subscription definition (MsDefinition) and custom event
listeners are provided by concrete ConsoleSubscription implementations. Particularly
PartialTopologySubscription enables changing the topology fragment that is monitored
with that subscription, regardless that low-level OSGiMM subscriptions are immutable.
Console Communicator aggregates console subscriptions and manages their lifecycle depending
on ESB Communication Layer state. It is also responsible for registration of Local
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 70
:System :ConsoleSubscription :ConsoleCommunicator LocalMonitoringSubscriber :ESB Communication Layer
newaddSubscription
subscriberegisterMs
new
lms1registerLocalSubscriber(lms1)
SUBSCRIBEDsetSubscriptionState(SUBSCRIBED)
subscriptionStateChange(SUBSCRIBED)
Create SubscriptionCreate Subscription Creating subscription and subscribing.
Figure 5.11. Console Subscription - creation and subscription - Class Diagram
Monitoring Subscribers in OSGiMM, changing Console Subscription state to “unsubscribed”
on communication disconnection and triggering console subscription update(resubscription) on
communication connection.
Console Local Monitoring Subscriber is created by Console Subscription and is responsible for
the event reception from OSGiMM, their initial processing and forwarding events to Console
Subscription. Each subscriber is associated with one subscription definition(MsDefinition)
and changing the subscription definition requires to register new subscriber and to unregister the
old one.
Figures 5.11 and 5.12 present sequence diagrams illustrating basic Console Subscription mechanisms.
Topology View
Topology View component provides a graphical viewer for displaying the topology structure. It also
registers console-wide service TopologyBuilderService that provides other components with the
current topology, filters the topology elements to match the given restrictions and notifies on the topology
changes (figure 5.13). Topology service uses Console Subscriptions to register for the topology events.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 71
:System :ConsoleSubscription :ConsoleCommunicator LocalMonitoringSubscriber :ESB Communication Layer
DISCONNECTEDsetSubscriptionState(UNSUBSCRIBED)
subscriptionStateChange(UNSUBSCRIBED)
CONNECTEDupdate
subscribe()
new
lms2registerLocalSubscriber(lms2)
unregisterLocalSubscriber(lms1)
SUBSCRIBEDsetSubscriptionState(SUBSCRIBED)
subscriptionStateChange(SUBSCRIBED)
ReconnectReconnect Handling communication layer reconnection.
Figure 5.12. Console Subscription - handling reconnection - Class Diagram
TopologyListener
+onTopologyElementChange(te:ITopologyElement)
TopologyViewerRCP viewer that displays topology tree
+display()
TopologyBuilderService
+getTopology()+getTopology(topologyRestriction)+addTopologyListener(topologyListener)+removeTopologyListener(listener)
«osgi:service»TopologyBuilderServiceImpl
osgi:import
Figure 5.13. Topology Viewer and Topology Service - Class Diagram
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 72
Monitoring Workbench and Project Management
The concept of business process monitoring specific project was described in section 4.6.1. As for
its implementation, the presented class diagram (figure 5.14) describes the structure and relations of the
classes. The role of each class is also briefly described.
GenericStructureNode
+getParent()+getChildren()+fireNodeChange(node,changeType)+addChangeListener()+removeChangeListener()
ParentType:ChildrenType: MonitoringWorkbenchElement
+getName()+getWorkbenchPath()+remove()+getElementByName()
MonitoringStructureNode
MonitoringWorkbenchRoot
«osgi:service»MonitoringWorkbench
+createProject()+getChildren()
BPMMonitoringProject
+ts: TopologySubscription+topolgy: BPMTopology+subscribe()
BPMContainterElement
+container: BPMContainer
BPMComponentElement
+component: BPMComonent+getBPMComponentType(): BPMComponentType
ContreteComponentProjectNode
ProjectTopologyElement
+isInTopology()+markInTopology()+markOutTopology()
Figure 5.14. Monitoring Workbench - Class Diagram
GenericStructureNode is a template class providing composite pattern [22] implementation
for elements used in Monitoring Console. Additional enhancement is that each
GenericStructureNode can generate events when the node changes. Those events are
propagated to registered listeners and upward in the composite tree. Each node update is
identified by the changed node and change type (ADD, REMOVE, UPDATE, LABEL_UPDATE,
REFRESH). Such a solution greatly simplifies propagation and handling of changes in the
Monitoring Console which may be caused by incoming monitoring events or by users actions.
This mechanism is mainly utilized to synchronize various Eclipse RCP viewers with the
monitoring project state.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 73
MonitoringStructureNode extends GenericStructureNode and implements
MonitoringWorbenchElement which provide workbench-wide identification of projects
and their elements. Each MonitoringWorbenchElement has a URL-like path and provides a
method to get child element by its name. This idea was also used to enable associating viewer
filters with project elements and save them as customized user views.
MonitoringWorbenchRoot implements MonitoringWorbench and provides access to all
monitoring workbench elements in the console and ability to create new monitoring projects. It
is also responsible for creating project resources in Eclipse workbench and loading saved projects
when console is started. MonitoringWorbenchRoot is registered as an OSGi service and available
console-wide.
BPMMonitoringProject main responsibility is storing business process monitoring project data:
1. monitored topology and resources associated with topology elements,
2. topology subscription definition which defines the topology fragment that is monitored in
that project.
The monitoring project structure reflects the monitored topology shape. The main difference with
Topology Viewer is that it displays both online topology elements and those elements which
currently are not in the topology (they were undeployed or the console is working offline). The
monitoring project subscribes for topology events using console subscription and dynamically
updates its structure to the monitored topology.
The monitoring project can also store various resources that are handled using ProjectExtension
mechanism (section 5.4.3).
Topology specific elements BPMContainerElement and BPMComponentElement are
workbench representation of the respective topology elements. BPMComponentElement
is an abstract class, a concrete implementation is dependent on BPM Component type and it is
provided via Monitoring Console extension point described in section 5.4.3.
5.4.2. Monitoring Project Navigator
Monitoring Project Navigator is a visual element that displays monitoring projects and
provides actions that can be performed on the project elements. Monitoring Project Navigator
implementation is based on Eclipse RCP CommonNavigator. Navigator’s ContentProviders
and LabelProviders have been implemented, but for BPMComponentElement those providers
are supplied as extensions. For managing and opening project elements, context menus and double-click
handlers are provided via Eclipse RCP extension points.
5.4.3. Console Extensibility Implementation
This section describes the implementation details of the console extensibility introduced in
section 4.6.2.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 74
Supporting new BPM Components
To provide support for a new BPM Component, the following Monitoring Console’s contributions
have to be provided and exported as the OSGi services:
1. ComponentModelContribution that provides custom implementation of
BPMComponentElement project element,
2. ComponentContentContribution that provides custom BPM Component children
structure,
3. ComponentLabelContribution that provides labels and icons for BPM Component and its
children.
Monitoring Console registers OSGi services trackers to discover these custom contributions. They
can be exported in OSGi bundles’ activators or defined declaratively in a Spring context file. The class
structure of this system element is presented in figure 5.15.
Figure 5.15. Supporting new BPM Components in Monitoring Console - Class Diagram
Supporting additional resources
Monitoring Console defines an extension point that allows to extend Business Process Monitoring
(BPM) monitoring project by defining new resource categories that can be stored in that project
and providing custom content and label providers for those resources. Project extensions are defined
declaratively in Eclipse RCP plugin.xml file as in the example (listing 5.2).
For a new project extension, the following contributions have to be provided:
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 75
1<extension
2point="pl.edu.agh.bpm.monitor.project.extension">
3<projectExtension
4extensionID="pl.edu.agh.bpm.monitor.rulemonitoring"
5extensionFactory=
6"pl.edu.agh.bpm.monitor.rulemonitoring.extension.RuleMonitoringProjectExtension"
7labelProvider="pl.edu.agh.bpm.monitor.rulemonitoring.extension.RuleExtenstionLabelProvider">
8</projectExtension>
9</extension>
Listing 5.2. Example project extension declaration in plugin.xml
1. ProjectExtension that serves as a factory to create ProjectExtensionInstance for
a given monitoring project, ProjectExtensionInstance creates the project structure that
is required for the particular project extension and lists the project extension specific elements,
2. ILabelProvider - provides labels and icons for the project extension and its elements.
This extension mechanism is used to store business rule files in the monitoring project. Another
potential application could be supporting BAM report files that are generated on the basis of the collected
data, but this functionality is out of scope of this work.
5.4.4. Realization of BPEL Monitoring Component
BPEL Monitoring Component provides Monitoring Console extensions for handling BPEL BPM
Engine Monitors and BPEL business processes. BPM Engine Monitor is a topology element that is
associated with BPEL execution engine that generates process monitoring events.
For each monitored BPEL BPM Engine Monitor, BPELEngineMonitorElement is created in
the monitoring project. It has the following structure:
1. BPELEngineMonitorElement consists of ProcesModel elements that are created for
the BusinessProcessDescription children of BPM Engine Monitor. ProcessModel
element is responsible for storing business process related documents. It also provides an object
model of BPEL process (supported by org.eclipse.bpel Eclipse plugins). ProcessModel allows
to create subscription for the corresponding business process, receive monitoring events, store
them in workspace and to analyse.
2. ProcessModel contains InstanceModels objects which describe instances of the executed
process. The instance models are not stored in the workspace, but they are dynamically created on
the basis of the collected events. Processing of the instance monitoring events is delegated to an
InstanceModel object that updated its state on a new event reception.
3. InstanceModel state consists of the execution states of the particular process activities together
with the information about their start and finish/failure time.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.4. Monitoring Console 76
Process instance activities are not visible in Monitoring Navigator, but they are displayed in a separate
ActivityXView viewer. It displays information about the executed activities aggregated for a given
instance, process, engine or project level.
Activity identification
It was necessary to ensure unique identification of the business process activities to properly associate
activity monitoring events(5.2.2) with the process model and visual representation elements. In a BPEL
process XML document, activity nodes can have a name attribute, but it is not mandatory and it is not
guaranteed to be unique for the process. To uniquely identify activities XPath expression [46] are used.
They are computed for each process activity XML element. The activity monitoring event contains XPath
field that refers to the corresponding process activity.
BPEL Process Execution Visualization
One of the most important requirements for the Monitoring Console was online visualization of
the process instance execution. To achieve this functionality, a graphical component that could display
BPEL processes was needed. As Monitoring Console is built on Eclipse RCP, it was decided that BPEL
editor distributed as a part of BPEL Designer Project (http://www.eclipse.org/bpel/) will
be incorporated in Monitoring Console. Basically, an editor is used to statically visualize monitored
process by opening *.bpel document. For the dynamic process instance execution path visualization,
it was needed to adjust BPEL Editor by extending BPELEditor class. ExtenedBPELEditor
implementation of BPELEditor was created with the additional functionality:
• Most importantly, when ExtenedBPELEditor is opened for an InstanceModel, it registers
listeners for the process instance state. In the provided implementation, the editor holds mapping
between each process activity and its visual representation. Each activity is identified by XPath and
process instance model provides an API to query for the activity state by a given XPath. When the
activity state changes for a process instance, the editor updates displayed process by highlighting
executed activities. The way of updating editor state in presented in listing 5.3.
• Additional pages were added to the ExtenedBPELEditor such as ActivityXView or ChartView
with statistic information. As a result, ExtenedBPELEditor provides comprehensive
information about the process execution.
5.4.5. Local Event Processing
The Monitoring Console rule-based event processing component allows to locally process events
with build-in event processing engines. It also defines an extension point for plugging various event
processing engine implementation. By default, Drools Fusion CEP processor [29] is supported by this
extension mechanism. To facilitate the event processing, the monitoring event viewer’s context menu is
extended with a command which sends events to the selected, local event processor. Consequently, the
local business rules can also be deployed to the local event processing engines.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.5. Rule-based Event Processing 77
1
2public void loadXpaths() {
3GraphicalViewer graphViewer = this.fDesignViewer.getGraphicalViewer();
4
5for (Object v : graphViewer.getEditPartRegistry().keySet()) {
6if (v instanceof ExtensibleElement) {
7Element element = ((ExtensibleElementImpl) v).getElement();
8String path = element.getAttribute("xpath");
9EditPart p = (EditPart) graphViewer.getEditPartRegistry().get(v);
10registry.put(path, p);
11}
12}
13}
14
15public void updateColor() {
16if (getEditorInput() instanceof InstanceEditorInput) {
17InstanceActivityNode node = ((InstanceEditorInput) getEditorInput()).getRootNode();
18final InstanceState state = node.getModel().getState();
19graphViewer.getControl().getDisplay().asyncExec(new Runnable() {
20public void run() {
21for (String xpath : registry.keySet()) {
22ActivityState acState = state.getActivityState(xpath);
23final EditPart editPart = registry.get(xpath);
24if (acState.getExecutionState() == ExecutionState.COMPLETED) {
25changePartColor(editPart, COLOR_GREEN);
26} else {
27changePartColor(editPart, COLOR_GRAY);
28}
29}
30}
31});
32}
33}
34
35public void onStructureChange(StructureNode node, StructureChange change) {
36if (node instanceof InstanceModel && change == StructureChange.UPDATE) {
37updateColor();
38}
39}
Listing 5.3. Extended BPEL Editor
5.5. Rule-based Event Processing
The section 4.5 (Architecture of Rule-based Event Processing) described the general architecture for
rule-based event processing. In this section it is presented how particular system elements: Rule Registry
and Event Processor based on Drools Fusion, were constructed.
5.5.1. Business Rule and Rule Registry Implementation
In this work part, Business Rule and distributed Business Rule repository - Rule Registry are
described.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.5. Rule-based Event Processing 78
Business Rule
In the monitoring framework, BusinessRule is an entity that warps the rule content.
BussinesRule has the discriminator field to differentiate various rules types. The monitoring
framework does not impose restrictions on the format of rule content, the discriminator field is used
to prevent BusinessRule from being deployed to the incompatible event processing engine.
Rule Registry
Rule Registry is a component that is responsible for comprehensive rule management. It is available
for all monitoring consoles in the BPEL Domain as a remote OSGi service.
IRuleRegistry
+addRule(BusinessRule): BusinessRuleDescription+removeRule(BusinessRuleDescription): void+getRule(BusinessRuleDescription): BusinessRule+getRules(): Collection<BusinessRuleDescription>
BusinessRuleDescription
+name+description+contentHash+ruleType+version
BusinessRule+ruleDescription+type+content
1
1
Figure 5.16. Rule Registry - Class Diagram
The Rule Registry class diagram is shown in figure 5.16. The main method of the registry are the
following:
addRule adds a rule to the persistent storage. First, it is checked if there is already stored an identical
rule. If true, then existing BusinessRuleDescription is returned. If a rule with the same
name and ruleType was deployed earlier, or a record with that name and type does not exists, then
a new BusinessRuleDescription is created with an increased revision number or zero in
case of the completely new business rule.
removeRule removes a rule with given BusinessRuleDescription. If that rule does not exist,
the exception is thrown.
getRule returns BusinessRule for a given BusinessRuleDescription. If that rule does not
exist, the exception is thrown.
getRules returns the collection containing all the available BusinessRuleDescriptions.
The Rule Registry storage is based on EHCache [44]. This not only does enable convenient persistent
storage but also provides advanced caching behaviour. Thank to the underlying cache layer, there is no
need to keep all the business rules in memory, but they can be loaded on demand. It highly improves
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.5. Rule-based Event Processing 79
scalability of application. The number of rules cached in the memory can be adjusted in the configuration
files.
5.5.2. Event Processing Engine Implementation
The event processing engines are responsible for event processing capabilities of the BPM Rule
Event Processors. As various event processing solutions exist, particularly CEP oriented, which could
be plugged to the presented system, an API, which was general enough to support different event
processor implementations, had to be provided. The class diagram of of the proposed API is presented
in figure 5.17.
IEventProcessingEngine
+addRule (rule:BusinessRule)+removeRule(rule:BusinessRule)+processEvent(event:MonitoringEvent)+addRuleMatchEventListener(listener:EventListener)+getEngineType(): EngineType
IEventProcessingEngineFactory
+getNewInstance(): IEventProcessingEngine+getEngineType(): EngineType
creates
DroolsEngineFactory FusionEventProcessingEngine
Figure 5.17. Event processing engine - Class Diagram
The most important guidelines for IEventProcessingEngine implementation are:
• instances of IEventProcessingEngine should be lightweight as BPM Rule Event Processor
implementation (section 5.1.4) creates an event processing engine for each enabled Rule
Monitoring Definition,
• IEventProcessingEngine should effectively manage memory and make sure that events
that are deprecated are not stored by the event processing engine,
• Business Rule consistency and syntax should be checked on the rule deployment to avoid runtime
exception during event processing,
• IEventProcessingEngine should process incoming events and generate RuleMatched
events asynchronously so that the event source is not blocked by the event processing engine.
5.5.3. Drools Fusion Event Processing Engine
According to the guidelines in the previous section, the reference event processing engine based on
Droools Fusion was implemented. It leveraged the following features of Drools Fusion:
• utilization of Drools DRL rules syntax that allows to precisely describe the interesting system
conditions,
• support for events garbage collection - old events that are no longer needed for processing are
discarded,
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.5. Rule-based Event Processing 80
• support for detection of advanced time relationships between events, including missing event
detection, delays, aggregated occurrence in a given sliding window.
During Fusion engine initialization (listing 5.4), KnowledgeBaseConfiguration is set to
EventProcessingOption.STREAM) thus enabling the stream event processing. Later, the stateful
knowledge base session is created. Finally, the rule activation listener, described later, is registered.
Listing 5.5 presents how the incoming events are inserted into Drools knowledge session.
1KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
2config.setOption(EventProcessingOption.STREAM);
3knowledgeBase = KnowledgeBaseFactory.newKnowledgeBase(config);
4
5session = knowledgeBase.newStatefulKnowledgeSession();
6session.addEventListener(this);
Listing 5.4. Drools Fusion configuration
1public void processEvent(MonitoringEv event) {
2session.insert(event);
3session.fireAllRules();
4}
Listing 5.5. A new event processing
Required drools rule structure
Drools Fusion event processing engine uses the standard drools rule syntax. However, the Drools
rules used in our system have to follow a certain rule pattern to integrate with Business Process
Monitoring Platform. It is presented in listing 5.6.
The presented rule pattern contains:
1. global RuleResultManager result variable which is used for returning the result from rule
activation to the monitoring system.
2. global VariableValue variable variable which provides a helper method for extracting values
from VariableModificationEv .
3. declaration that MonitoringEvents should be treated as an event by Drools Fusion and
specification which field contains the event timestamp.
Returning values from rule execution
In the presented rule processing solution it is assumed that RuleMatched event can carry some
additional information set during the rule activation. The basic data carried by Rule Matched event
contains:
• Business Rule Description identifying the matched rule,
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.5. Rule-based Event Processing 81
1package rules;
2
3import pl.edu.agh.as3.sensors.backbone.api.ms.msdata.*;
4import pl.edu.agh.as3.sensors.backbone.api.bpm.cep.VariableValue;
5
6#declare any global variables here
7global pl.edu.agh.as3.sensors.bacrkbone.api.bpm.cep.VariableExtractor variable
8global pl.edu.agh.bpm.ruleprocessor.RuleResultManager result
9
10declare ConcreteEventType
11@role( event )
12@timestamp ( timestamp )
13end
14
15rule "rule name"
16when
17#condition description
18then
19#actions taken
20end
Listing 5.6. Drools rule pattern used by Business Process Monitoring Platform
• the description field with the user’s comment set during the rule activation,
• severity of the situation detected by the rule.
To return values from Drools Fusion rule activation, global helper RuleResultManager is used.
It serves as a map indexed with rule activation object. That object is accessible via rule global drools
variable (listing 5.7).
1
2rule "sample rule"
3when
4#condition description
5then
6result.setDescription(drools, "User comment");
7result.setSeverity(drools, 5 );
8end
Listing 5.7. Returning results from a Drools rule
Generating Rule Matched events
The rule activation listener registered for a Drools session is used to detect which Drools rule was
activated. Custom implementation of that listener is responsible for associating Drools rule with Business
Rule and generating Rule Matched event (listing 5.8).
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.6. Integration Testing 82
1public void afterActivationFired(org.drools.event.rule.AfterActivationFiredEvent event) {
2Activation activation = event.getActivation();
3Result result = resultManager.getAndRemoveResult(activation);
4String id = getDroolsRuleID(activation.getRule());
5BusinessRuleDescription brd = droolsRuleToBusinessRuleMap.get(id);
6RuleMatchedEv ruleMatchedEv = createMatchedEv(activation, brd, result);
7//notify on rule matched event
8listenerSupport.onEvent(ruleMatchedEv);
9}
Listing 5.8. RuleMatched event generation
Drools Fusion engine performance tuning.
Drools Fusion provides some performance tuning options. One option worth considering, when
performing a lot of of expensive rule evaluation (e.g. extracting business processvariable values form
events), is enabling multithreaded evaluation. It can be achieved by setting properties as in listing 5.9.
1drools.multithreadEvaluation = <true|false>
2drools.maxThreads = <-1|1..n>
Listing 5.9. Enabling multithreaded evaluation
5.6. Integration Testing
The presented system is largely based on many new technologies that sometimes lack comprehensive
testing and maturity. Additionally, the system is OSGi-based and its modules can be dynamically added
and removed which adds more dynamics to the application. All of this contributed to the fact that the
system development was quite complex at start. With no appropriate testing framework, it was hard
to develop the system that by constant verification would allow to promptly and precisely detect and
solve arising problems concerning the system implementation or diagnose 3rd-party components failures.
While initially struggling with the manual system testing, with time a more advanced approach for the
automatic integration testing was introduced. This solution for the integration testing of components
using ESB Communication Layer is presented in this section.
The integration testing is supposed to answer the question how a selected set of modules interacts
and is crucial to ensure functional correctness of the integrated system.
5.6.1. OSGi Testing Framework
In the OSGi environment there are a lot of bundles cooperating in various ways such as: interleaving
dependencies, shared services, exchanged messages, extending other bundles classpath and others. For
all the mentioned reasons, mocking of the entire component surrounding with its behaviour could be
a complicated and exhaustive task (complex behaviours, time dependencies, lack of documentation).
While, the unit tests as suitable for testing small functional elements, they are inconvenient and
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.6. Integration Testing 83
inappropriate for OSGi bundles. To fully test the OSGi bundles, the OSGi integration tests should be
performed in the OSGi runtime environment.
The presented system implementation greatly relies on Spring DM [41] which already provide Spring
OSGi testing framework that has many advantages such as:
• automatic bundle manifest generation,
• maven dependency resolver,
• JUnit 3 support,
• integration with Spring Dynamic Modules.
Figure 5.18. OSGi framework testing elements
However, this framework needed to be extended with several improvements required for the
presented system. The default classpath resolver was designed in a Maven-like fashion [12] and the
integration tests required that OSGi modules have to be specified as Maven dependencies. Unfortunately,
it is inconsistent with how Eclipse RPC manages OSGi modules. To solve this issue, the custom classpath
resolver based on the one available in Open Financial Market Platform (OFMP) [34] was introduced.
Now, it is able to resolve not only Maven dependencies, but also the ones stored in the Eclipse Target
Platform [27]. Target Platform is a directory where Eclipse OSGi plugins with their dependencies
are stored. Moreover, OSGi bundles can also be build on-the-fly from the projects stored in Eclipse
workspace (provided by OFMP [34]).
By default, Spring OSGi testing framework uses Equinox OSGi container with no preconfigured
dependencies. Here, the next modification was needed. Equinox was substituted by ServiceMix, as AS3
Studio’s ESB Communication Layer runs natively in ServiceMix. Before running the test, ServiceMix
need to be preconfigured and around 70 bundles required ServiceMix functioning need to be preloaded.
Additionally, as most of dependencies of the implemented bundles share common dependencies (mainly
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.6. Integration Testing 84
to OSGiMM), all of them are loaded by default. These features are based on ServiceMix testing support
classes [21] which are adopted for the presented system testing.
To summarize, the following features were added or incorporated:
• the custom classpath resolver that resolves dependencies from the Target Platform and Eclipse
workspace instead of Maven repository,
• workspace plugins can be built on the fly to make development faster,
• ServiceMix is instantiated instead of Equinox from the unit test level,
• easy configuration of the required bundles,
• manifest generation improvements,
• added test timeout (missing in JUnit 3).
5.6.2. Example Integration Test Case
The integration test presented in listing 5.10 is a simple demonstration of the created
solution. First, ServiceMix instance is started with all the preconfigured bundles, then
apacheOdeEngineMonitor, BPMComponent and BPMContainer bundles are loaded and, finally,
testMonitoringSensorBundleShouldBeStarted method is executed. The test method verifies if
apacheOdeEngineMonitor bundle is started. If that bundle is started, it is known that there are no
missing dependencies, all required files are available and Spring configurations are correct.
1
2import org.apache.servicemix.platform.testing.support.AbstractIntegrationTest;
3
4public class MonitoringAgentIntegrationTest extends AbstractIntegrationTest {
5
6@Override
7protected String[] getTestBundlesNames() {
8return new String[] { "apacheOdeEngineMonitor, 0.0.1",
9"BPMComponent, 0.0.1", "BPMContainter, 0.0.1" };
10}
11
12public void testMonitoringSensorBundleShouldBeStarted() throws Exception {
13checkBundleStarted("apacheOdeEngineMonitor");
14}
15}
Listing 5.10. Example integration test
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.7. Business Process Monitoring Platform Modules 85
5.7. Business Process Monitoring Platform Modules
This section provides a list of OSGi modules that form the implemented system. Additionally, a short
description of the functionality provided by each module is provided.
Monitoring Domain Components and Rule Registry
Bundle Description
sensors.backbone.api-bpel monitoring and topology events, subscription
definitions and helper classes for managing events
and subscriptions
pl.edu.agh.bpm.BPMContainter implementation of the BPM Container
pl.edu.agh.bpm.BPMComponent common, abstract implementation of the BPM
Component
pl.edu.agh.bpm.BPMEventProcessor generic implementation of BPM Rule Event
Processor
pl.edu.agh.bpm.ApacheOdeEngineMonitor implementation of BPM Engine Monitor for
ApacheODE
pl.edu.agh.bpm.RuleRegistry implementation of distributed Rule Registry
BPM Rule Event Processing Engines
Bundle Description
pl.edu.agh.bpm.DroolsRuleProcessor event processing engine used by BPM Rule Event
Processor that uses Drools Fusion
org.drools.eclipse.bpm Drools modules adjusted for Business Process
Monitoring Platform
Monitoring Console Core Modules
Bundle Description
pl.edu.agh.bpm.monitor.charts chart support for business process statistics
pl.edu.agh.bpm.common common elements used across all bundles
pl.edu.agh.bpm.monitor.common common product visual elements and Eclipse RCP
helpers
pl.edu.agh.bpm.monitor.model object model of the monitoring project and topology
elements managed by Monitoring Console
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.7. Business Process Monitoring Platform Modules 86
Bundle Description
pl.edu.agh.bpm.monitor.ui main application bundle, starts the application,
provides core visual elements
pl.edu.agh.bpm.monitor.dependencies aggregated common dependencies of other
Monitoring Console bundles
pl.edu.agh.bpm.monitor.navigator Monitoring Project Navigator that handles creation
and management of the monitoring projects
pl.edu.agh.bpm.monitor.processtree bundle is responsible for the aggregated
visualisation of executed process activities
pl.edu.agh.bpm.monitor.resources management of the monitoring information stored in
Eclipse RCP workspace
pl.edu.agh.bpm.monitor.runtime bundle start runtime dependencies of the Monitoring
Console
pl.edu.agh.bpm.monitor.common.api application interfaces implemented by various
Monitoring Console’a modules
pl.edu.agh.bpm.monitor.component-api API for extending Monitoring Console with support
for new BPM Components
pl.edu.agh.bpm.monitor.bpcomponent.common common, abstract implementation of component-api
pl.edu.agh.bpm.monitor.project-api API for accessing monitoring project elements
across Monitoring Console
pl.edu.agh.bpm.monitor.project-extension extension point for creating monitoring project
extensions
pl.edu.agh.bpm.monitor.topology modules for topology visualisation and querying for
topology elements
Monitoring Console OSGiMM Communication Support
Bundle Description
sensors.backbone.client.communicator-api API for managing Console Subscriptions, provides
common subscription’s implementation
sensors.backbone.client.communicator-impl communicator-api implementation, handles
subscription management in the OSGiMM layer
sensors.backbone.client.pde.connector handles connection, disconnection and status
information of OSGiMM
Console BPEL Monitoring
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
5.7. Business Process Monitoring Platform Modules 87
Bundle Description
org.eclipse.bpel a set of eclipse plugins that support BPEL
visualisation and provides BPEL process object
model
pl.edu.agh.bpm.eclipse.bpel virtual bundle that aggregates org.eclipse.bpel
dependencies
pl.edu.agh.bpm.monitor.bpel-component bundle is responsible for including and monitoring
BPEL BPM Engine Monitors and BPEL processes
in the monitoring project
Console Rule Processing
Bundle Description
pl.edu.agh.bpm.monitor.rulemonitoring.common common elements used by Monitoring Console in
rule-based event processing
pl.edu.agh.bpm.monitor.rulemonitoring-drools drools rule editor, rule templates and Drools Event
processing engine adjusted for business process
monitoring
pl.edu.agh.bpm.monitor.rulemonitoring rule monitoring components: wizards, resources,
viewers
pl.edu.agh.bpm.monitor.ruleregistry visual component for managing create, read and
update operation on Rule Registry
pl.edu.agh.bpm.monitor.rules-processor bundle is responsible for including and monitoring
BPM Rule Event Processors and Rule Monitoring
Definitions in the monitoring project
This chapter has described the implementation of the selected Business Process Monitoring
Platform modules. It has been presented how the system requirements were realised using the
implemented and available software components. The system is supposed to provide the required
functions and characteristics which is validated in the next chapter. Apart from providing expected
functionality, one of the major implementation policies has been the system extensibility that was
facilitated by a suitable selection of the applied technologies. The resulting software is open for versatile
extensions that can empower its business process monitoring and analysis capabilities.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6. System Evaluation
In this chapter, the functional and performance aspects of the presented Business Process Monitoring
Platform are placed under scrutiny. A set of test case scenarios was designed and used with the aim to
cover the major functional requirements and to prove the system scalability. First, the chapter covers
the distributed infrastructure which was used for testing. Then, the functional and performance tests are
presented with a description of the test scenarios and results of the conducted tests. Finally, a summary
of the system evaluation is presented.
6.1. Deployment Infrastructure
The system presented in this thesis is dedicated to work in highly distributed environments where
scalability and efficiency are important aspects of the monitoring process. The deployment infrastructure
presented in figure 6.1 was set up to verify and underline the functional and performance characteristics
of the system.
There are three virtualization servers which run KVM-QEMU [32] based virtualized systems: Ubuntu
Server 11.04, Windows XP and/or Solaris 10u8.
• Virtualization Server 1 is SUN x6440 with 4x16 cores, 16GB RAM
– Slackware 13.37 - 2 instances
• Virtualization Server 2 is Intel Core i5 processor with 8GB of RAM
– Ubuntu Server 11.04 - 4 instances
• Virtualization Server 3 is Inel Core i5 processor with 4GB of RAM
– Ubuntu Server 11.04 - 3 instances
Virtualization server 1 and 2 are connected by 100Mbit Ethernet working with almost full bandwidth
available. Virtualization server 3 is linked to 1 and 2 over VPN connection with speed reduced by order
of magnitude compared to 100Mbit Ethernet.
The test environment characteristics:
• Each virtual machine runs single ServiceMix instance.
88
6.1. Deployment Infrastructure 89
Figure 6.1. Deployment Infrastructure
• BPEL engine(ApacheODE) and its respective BPM Engine Monitors were deployed in each
ServiceMix container.
• Monitoring Console runs on a personal computer under Ubuntu 10.04.
• Each of ApacheODE instances has an identical set of the deployed processes:
– CreditApp (figure 6.36)
– ScoringService (figure 6.37)
– HelloWorld2
– HelloWorkd2-RPC
– Ping
– Pong
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 90
6.2. Functional Verification
This section features the functional verification of Business Process Monitoring Platform by
illustrating common product usage scenarios. The system functionality is proved by presenting user steps
for achieving the desired effects and application screenshots referring to most of that steps are included.
The specified test cases cover the most important aspects of the system.
6.2.1. Process Monitoring Validation
The first scenario was designed to show the primary application functionality - business process
execution monitoring. The particular steps of a typical monitoring scenario with the respective
application screenshots are as follows:
• Launching ServiceMix instance with deployed business processes (6.2).
• Starting Monitoring Console (6.3).
• Connecting Monitoring Console to OSGiMM backbone (6.4).
• Creation of BPM Monitoring Project and selecting interesting topology elements(6.5, 6.6, 6.7,
6.8).
• Enabling process monitoring subscription (6.9, 6.10).
• Execution of CreditApp process instance (6.12).
• Listing executed process instances (6.13).
• Viewing process instance execution path (6.14)
• Browsing collected process instance events (6.15).
• Viewing Activity Summary (6.17).
• Browsing process charts (6.16).
Figure 6.2. ServiceMix started
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 91
Figure 6.3. Monitoring Console started
Figure 6.4. Connecting to ESB Communication Layer
Figure 6.5. Creation of the new BPM Monitoring Project
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 92
Figure 6.6. New project wizard - project name selection
Figure 6.7. New project wizard - project configuration setup
Figure 6.8. New project wizard - monitored topology selection
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 93
Figure 6.9. Monitoring Console - monitoring project is created
Figure 6.10. Subscribing for the selected
process
Figure 6.11. Monitoring Console is
subscribed for a given process
Figure 6.12. Process instance execution
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 94
Figure 6.13. Executed process instances
Figure 6.14. Execution path of the monitored process
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 95
Figure 6.15. Monitoring events collected
Figure 6.16. Process activities summary
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 96
Figure 6.17. Activity execution charts
6.2.2. Rule Processing Validation
This scenario is aimed to present an advanced rule-based analysis of the specified BPEL process. It
was executed directly after the first one, without the modifying console state.
• Creating business rule (6.18, 6.19, 6.20, 6.21).
• Editing rule created from template (6.22).
• Deploying rule to Rule Registry (6.23).
• Browsing Rule Registry (6.24).
• Creating new Rule Monitoring Definition (6.25, 6.26, 6.27, 6.28).
• Enabling Rule Monitoring Definition(6.29).
• Starting CreditApp process instance (6.30).
• Browsing events generated by Rule Engine (6.31).
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 97
Figure 6.18. New rule wizard
Figure 6.19. Business Rule wizard - name and description
Figure 6.20. Business Rule wizard - rule template selection
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 98
Figure 6.21. Business Rule wizard - target project selection
Figure 6.22. Drools rule editor
Figure 6.23. Deployment of the business rule to Rule Registry
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 99
Figure 6.24. Browsing Rule Registry
Figure 6.25. Creation of the Rule Monitoring Definition
Figure 6.26. Rule Monitoring Definition - basic configuration
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 100
Figure 6.27. Rule Monitoring Definition - business rule selection
Figure 6.28. Rule Monitoring Definition - target topology selection
Figure 6.29. Rule Monitoring Definition activation
Figure 6.30. Process instance execution
Figure 6.31. Events generated by BPM Rule Event Processor
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.2. Functional Verification 101
6.2.3. Additional Features
Monitoring Console offers additional features such as:
• Console Summary View (6.32)
• Container Summary View (6.33)
• Engine Monitor Summary View (6.34)
• JMX Management (6.35)
Figure 6.32. Console Summary View
Figure 6.33. Container Summary View
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.3. Performance Verification 102
Figure 6.34. Engine Monitor Summary View
Figure 6.35. ServiceMix components management via JMX
6.3. Performance Verification
This section contains introduction, detailed description and results of performance verification of the
presented system. The tests were performed using the deployment infrastructure described in section 6.1.
The monitoring scenarios follow the generic application usage description illustrated in section 4.3.2.
6.3.1. Description of the Test Processes
The CreditApp application process shown in figure 6.36 is a business process that is a simplified
representation of business steps taken to decide whether a credit should be granted or denied for a specific
client. In the first, initialisation step of the process, the application gathers user input such as name,
requested credit value and debtor’s country of origin. Later, the application assigns the client to a personal
or business category by checking the requested credit value. Depending on this assignment, in the next
step, the credit is scored by a bank with a simple or a complex criteria evaluator. If the credit is a
personal one, then scoring is made in place by checking the requested credit value. Otherwise, the credit
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.3. Performance Verification 103
decision is delegated to external business process called ScoringService (figure 6.37), which is used to
evaluate credit profitability for the bank. In the first step ScoringService receives a web service call from
CreditApp. Then, the credit request is evaluated and the result representing the score of the requested
credit is returned to CreditApp. Depending on the score, the credit request is approved or denied and this
result is returned as a result of the entire process execution.
Figure 6.36. CreditApp Business Process
6.3.2. Test Cases
Test 1
This test case is designed to emphasise scalability of the system by presenting how the system
preforms depending on the number of active Monitoring Consoles. First, one console is attached to
the monitoring infrastructure, then a number of consoles is increased adding one per iteration. Before
starting a new console, CreditApp business process is executed on a single ServiceMix instance. The
monitoring scenario uses subscriptions restricted to a subset of the entire topology which select only
CreditApp and ScoringService processes deployed in Krakow, Gdansk and Warszawa nodes.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.3. Performance Verification 104
Figure 6.37. ScoringService Business Process
ServiceMix Topology events Monitoring events
Krakow 6 206
Gdansk 6 103
Warszawa 6 0
Table 6.1. Generated events summary for 1 console
The steps listed below are repeated for one, two, three and finally four active instances of Monitoring
Console.
1. Start monitoring console.
2. Create monitoring project.
3. Subscribe for CreditApp and ScoringService.
4. Execute CreditApp process 3 times on randomly selected monitored engine.
The tables (6.1 - 6.4) present the number of topology and monitoring events transmitted in the system
depending on the number of monitoring consoles.
Table 6.1 contains the events summary for a single console instance. There are 309 generated
monitoring events (103 per process instance) and 6 topology events. CreditApp and ScoringService
ServiceMix Topology events Monitoring events
Krakow 12 0
Gdansk 12 309
Warszawa 12 0
Table 6.2. Generated events summary for 2 consoles
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.3. Performance Verification 105
ServiceMix Topology events Monitoring events
Krakow 18 206
Gdansk 18 0
Warszawa 18 103
Table 6.3. Generated events summary for 3 consoles
ServiceMix Topology events Monitoring events
Krakow 24 103
Gdansk 24 103
Warszawa 24 103
Table 6.4. Generated events summary for 4 consoles
process definitions were sent from each of the monitored execution engines. It is required as process
definitions may be slightly different between the execution engines. Tables 6.2, 6.3 and 6.4 shows that
the number of generated monitoring events is constant and does not change with the number of receivers
while the topology events count grows linearly with added monitoring consoles.
The number of generated monitoring events is independent from a number of monitoring consoles
due to the intelligent subscription management provided by ESB Communication Layer. The linear
growth of the topology events is caused by the fact that the process definitions need to be sent separately
to each instance of Monitoring Console that is the expected behaviour. The business process definitions
can be relatively large objects and they are not propagated in the topology as described in section 5.3.1.
They are sent on demand by creating special topology subscription, just after subscription creation. As
the console instances become active in different moments of time, they are unable to use this same
subscription.
A summary of generated events is shown in figure 6.38.
Test 2
The following test case is designed to compare standard event collecting with the application of
rule-based event processing.
The aim of this scenario is to perform process data-mining for information concerning a credit
approval for user “Mark” (CreditApp business process). Using the method described in previous test
case, all the execution events can be collected and later processed and analysed manually. Monitoring
Console allows to visualize the execution path of the process instance and it can be easily observed
whether the credit was accepted in a particular process instance. However, to get the information about
who applied for the credit one must browse VariableModificationEv events. This may be appropriate for
a one off analysis, but it is easy to overlook important information and this approach is not suitable for a
large scale analysis. Moreover, for this well-defined monitoring goal, the amount of collected irrelevant
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.3. Performance Verification 106
Figure 6.38. CreditApp Business Process
data is relatively high which will be presented in this section. An easier and a more efficient solution is
the application of BPM Rule Event Processor (section 4.5) and creation a business rule that is able to
detect the required behaviour - in this case - credit approval. Data generated by BPM Engine Monitor
will be examined by BPM Rule Event Processor running within the same container, so the result events
are propagated only locally and overhead connected with information forwarding is negligible.
Regular monitoring was performed according ot the specification below:
• Start Monitoring Console.
• Create monitoring project.
• Subscribe for CreditApp and ScoringService.
• Start CreditApp process.
• Manually process events in search for activity connected to credit approval.
Rule monitoring:
• Start Monitoring Console.
• Create monitoring project.
• Create business rule (listing 6.1) that verifies if credit was approved.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.3. Performance Verification 107
1rule "Mark credit approved"
2when
3v : VariableModificationEv( $pi : processInstanceId )
4a: VariableValue( value == "Mark" ) from
5variable.getVariableValue( v, "/message/body/CreditAppRequest/name")
6r: ActivityExecEndEv( processInstanceId == $pi, activityName == "approve" )
7then
8result.setDescription(drools, "Mark Credit Approved");
9result.setSeverity(drools, 2 );
10end
Listing 6.1. Credit approval detection
• Deploy rule to Rule Registry.
• Create Rule Monitoring Definition and deploy it to the selected BPM Rule Event Processor.
• Start CreditApp process.
• Verify if new RuleMatchedEv were generated.
The rule used in this test case (listing 6.1) is tried against all the events generated during the process
execution. If during the process execution, the two conditions for the same process instance are found:
• event that is an instance of VariableModificationEv which carries CreditAppRequest variable and
this variable’s field denoted by the given XPath is equal to “Mark”,
• successful completion of an activity with name set to ”approve”
then new RuleMatched event is generated with description ’Mark Credit Approved’ and severity set to
’2’.
Results
The performed test proved that rule-based event processing allows to greatly reduce the amount of
data sent over the network. Instead of 103 events (during regular process monitoring) only one event
was generated by BPM Rule Event Processor and send to Monitoring Console. The data redundancy was
strongly reduced and it can be seen that detailed data about the process execution are not always required.
Figure 6.39 presents comparison between regular and rule-based event processing monitoring. Detailed
amount of generated events is available in table 6.5.
6.3.3. Performance Tests Summary
the test cases presented in this section proved that the system can work effectively in the distributed
environment. The applied solutions for event propagation serve their purpose and positively impact on the
generated network traffic. The system events are promptly transmitted to the Monitoring Consoles and
scalability of the system is achieved. The advanced model of the rule-based event processing allows for
even more efficient and expressive business process monitoring, that not only does minimises transferred
data but also emphasises important aspects of business process execution.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.4. Evaluation Summary 108
Instance Count Standard process monitoring Rule-based Event Processing
1 103 1
2 206 2
3 309 3
4 412 4
5 515 5
6 618 6
7 721 7
8 824 8
9 927 9
10 1030 10
11 1133 11
Table 6.5. Generated events summary with and without rule-based event processing
Figure 6.39. Number of generated events for two monitoring use cases
6.4. Evaluation Summary
The performed tests proved that the application is capable to work in a distributed and heterogeneous
environment. It is able to discover engines, deployed processes and monitor their execution. Complete
process execution data can be collected and analysed. Business Process Monitoring Platform is suitable
for simple monitoring cases as well as it can scale for larger distributed systems with sophisticated
models of data processing such as rule-based event processing. Though the presented scenarios are quite
simple, more advanced configuration, e.g chained event processing components that monitor complex
time-based interaction of multiple business processes, can be imagined. Monitoring Console greatly
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
6.4. Evaluation Summary 109
facilitates executing of the monitoring scenarios and provides a comprehensive toolbox for monitoring
and analysing business processes.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
7. Conclusions
In this final chapter, conclusive remarks on the presented work in the area of Business Process
Monitoring in the SOA environment are presented. At the beginning, a brief work summary is provided,
then the thesis contributions to the problem of business process monitoring and IT-SOA project are
highlighted. Finally, possible research directions that may be based on or inspired by this work are
suggested.
7.1. Work Summary
This work has presented a new approach to the problem of the Business Process Monitoring. As the
result of the master thesis project, an architecture and a ready-to-use product for providing visibility of
the business processes running in the SOA environment was created.
The investigation of various business process platforms lead to the conclusion that it is not possible to
uniformly provide monitoring capabilities for all the business process platforms. Instead, the specification
of the event driven system was defined, where the business process platform specific adapters - BPM
Engine Monitors hide the differences between the particular implementations of the process orchestration
engines. BPM Engine Monitors are generating events reflecting the business process engine state, and
the presented system takes care of their distribution and presentation.
Although, the current system implementation is dedicated to the BPEL, which is one of the most
common specifications of formal business process description and execution, the created system may
be perceived as an extensible framework that can support other business process languages and their
execution platforms.
The generic business process event model can be applied to other process-like execution engines
or any other execution platforms that follow the concept of workflow-based, declarative description
of component interaction. The only thing that has to be done is ensuring that the platform generates
events based on the presented model and contributes to the well defined Business Process Monitoring
Platform extensions.
The resulting system is an example of an event driven solution that leverages the innovative
mechanisms provided by AS3, namely it uses efficient integration and communication that reduces
data duplication, provides directed subscriptions to the specific infrastructure elements and allows for
dynamic discovery of the business process infrastructure.
110
7.2. Thesis Contributions 111
As planned, Business Process Monitoring Platform provides the insight into business
process deployment and execution that may be exploited by both IT specialists and business oriented
users. The system functionality is placed closely to BAM solutions, with powerful mechanism for
business activity monitoring supported by rule-based event processing. The scope of the project did
not include investigation of all the potential benefits that Business Process Monitoring Platformcreates
and presents only the simple use cases, but the system features allow to realise most of ideas for a good
business process monitoring solutions, that were presented in the section 2.2, such as SLA monitoring or
discovery of customers habits.
7.2. Thesis Contributions
The thesis contributions comply mostly with the objectives clearly set in the first chapter, but there
are also certain achievements that were realised additionally to the main goals of the thesis.
The fist objective is satisfied by creating Business Process Monitoring Platform, summarized in the
previous section, and contributing to the research in the area of business process monitoring. The work
already motivated others to provide support for the new type of business processes - Business Process
Modeling Notation (BPMN).
In the context of the IT-SOA project, this thesis brings noticeable influence on the AS3
implementation. The construction of the presented business process monitoring solution served the
purpose of functional and performance verification of AS3 Studio’s adaptive integration layer. The issues
and functionality requests reported during the development helped to increase stability and maturity of
the AS3 Studio and OSGiMM.
Another, vital contribution of this thesis is investigation and setting up the development environment
for OSGi based applications especially for Eclipse RCP applications. The system developers struggled
with automation of the system builds and automatic testing, but finally a flexible build and testing system
solution was forged. The way that the system code is structured and the product is built is out of the
scope of this thesis. It is purely technical and can be analysed in the system sources. However, the testing
framework enhancements, which were discussed in the implementation chapter, can help many OSGi
and Eclipse RCP system developers.
7.3. Further Research
The field of business process monitoring is brimming with challenges. This thesis presents only a tip
of the iceberg of the variety of the problems. When the technical aspects of the system implementation
are discussed, there is always space for improvement in performance, communication layer efficiency,
transmitted data filtration and selectivity. From the business point of view, visualization and statistics
elements could also be greatly extended. For a greater product ease of use, stronger relationship of the
process model, its semantics and monitoring rules could be introduced. The idea is that the user would
semantically tag the process elements that are the source of the important data, the system would hint
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
7.3. Further Research 112
typical KPI that could be monitored at that point and the monitoring rules suitable for that process would
be automatically generated.
Another interesting direction of the system development is adding the support for new engines and
business process notations. Ideally, the standardised notation such as BPMN should be used .
It could also be compelling to test this monitoring approach in a real business environment and
investigate benefits of using this software.
In the context of AS3 Studio, it would be vital to close the automated adaptation loop in the layer of
the business processes. It would be interesting to create the solution that would adjust business processes,
so that they realise theirs business goal most effectively. The monitoring and analysis part of such a
solution is ready, now system effectors have to be investigated and created.
It may be still unclear, if the languages such as BPEL will gain wider attention, but monitoring and
analytic solutions for overseeing enterprise performance are indispensable in modern business. In the
thesis authors’ opinion, if Business Process Monitoring Platform was supported and developed further,
it could mark its influence in the market of business process monitoring solutions.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
Glossary
BPEL Domain is a specification of hierarchical component types related to business process execution,
monitoring and analysis that can be discovered and monitored. 41, 42, 46, 48, 56, 58, 60, 78
BPM Engine Monitor is one of the most important elements of BPEL Domain topology that provides
bridge between process execution environment and monitoring system. It is responsible for
generating events on process execution progress and contributing to the domain topology by listing
processes deployed in the monitored engine. 41, 44, 45, 53, 54, 57–60, 63, 75, 85, 87, 89, 106, 110
BPM Rule Event Processor is a BPM Component responsible for rule-based event processing, it
accepts Rule Monitoring Definitions and generates RuleMatched events. 41, 42, 44, 45, 47–49,
53–55, 57–61, 64, 65, 68, 79, 85, 87, 106, 107, 113
Business Rule wraps definition of engine specific rule used for event processing. It has type
discriminator that allows to correlate rules with event processing engines. 61, 77, 79
ESB Communication Layer is a common name for communication mechanisms provided by
ServiceMix implementation of Enterprise System Bus together with OSGiMM. 30, 42, 44–46,
48, 49, 51, 52, 58, 59, 61, 67, 69, 82, 83, 105
Event processing engine is a concrete implementation of a component used by Rule Event Processor
to handle specific Business Rule type. 48, 87
Monitoring Topology is a runtime configuration of BPEL Domain elements deployed in a SOA
infrastructure. It may be referred as BPEL Domain Monitoring Topology, BPM topology or
simply topology. 42, 46, 48, 56
Rule Monitoring Definition is a topology element of BPEL Domain. Rule Monitoring Definitions are
deployed to BPM Rule Event Processors and consists of set of rules and topology scope for which
these rules are applied. Rule Monitoring Definition is Monitoring Event source which Monitoring
Console can subscribe for. 48, 49, 52–55, 57, 60–63, 67, 79, 87, 113
113
Acronyms
API Application Programming Interface. 9, 17, 19–22, 52, 79, 86
AS3 Adaptive SOA Solution Stack. 10, 13–15, 110, 111
AS3 Studio Adaptive SOA Solution Stack Studio. 10, 12, 13, 34, 36, 40, 51, 83, 111, 112
BAM Business Activity Monitoring. 9, 15, 75, 111
BPEL Business Process Execution Language. 8, 9, 15, 16, 21, 36, 44, 75, 76, 96, 110
BPM Business Process Monitoring. 74
BPMN Business Process Modeling Notation. 111, 112
BRMS Business Rule Management System. 31
CBE Common Base Event. 41, 44, 63
CEP Complex Event Processing. 30–32, 48
EAI Enterprise Integration Pattern. 26
Eclipse RCP Eclipse Rich Client Platform. 32–34, 40, 85, 86, 111
EJB Enterprise JavaBean. 28
ERP Enterprise Resource Planning. 26
ESB Enterprise System Bus. 25, 26, 28, 41, 42
FTP File Transfer Protocol. 25
HTTP Hypertext Transfer Protocol. 25
JAAS Java Authentication and Authorization Service. 28
JAX-WS Java API for XML. 28
JBI Java Business Integration. 28
114
Acronyms 115
JMS Java Message Service. 25, 28, 45, 60
KPI Key Performance Indicators. 14, 112
MOM Message Oriented Middleware. 23, 26, 28
OSGi OSGi. 24, 27, 28, 30, 32, 33, 85, 111
OSGiMM OSGi Management and Monitoring. 28, 29, 46, 47, 84, 86
QoE Quality of Experience. 13
QoS Quality of Service. 13, 14
REST Representational State Transfer. 28
S3 SOA Solution Stack. 8, 12–14
SCA Service Component Architecture. 28
SCM Supply Chain Management. 26
SOA Service Oriented Architecture. 8, 14, 25, 35, 110
SSH Secure Shell. 28
SWT Standard Widget Toolkit. 33
TCP Transmission Control Protocol. 25
WSDL Web Service Definition Language. 15, 16
XSLT EXtensible Stylesheet Language Transformations. 16
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
Bibliography
[1] AGH University of Science and Technology. AS3-Studio. https://www.soa.edu.pl/
AS3-Studio/.
[2] AGH University of Science and Technology. IT-SOA: Nowe technologie informacyjne dla
elektronicznej gospodarki i społeczenstwa informacyjnego oparte na paradygmacie SOA. https:
//www.soa.edu.pl.
[3] A. Ali, Zhang-Jie, E. Michael, A. Abdul, and C. Kishore. S3: A Service-Oriented Reference
Architecture. IT Professional, 9:10–17, May 2007.
[4] G. Alonso, C. Hagen, D. Agrawal, A. El Abbadi, and C. Mohan. Enhancing the fault tolerance of
workflow management systems. Concurrency, IEEE, 8(3):74 –81, jul-sep 2000.
[5] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller,
D. Smith, S. Systems, S. Thatte, I. Trickovic, and S. Weerawarana. Business Process Execution
Language for Web Services, version 1.1. Technical report, IBM, BEA Systems, Microsoft, SAP
AG, Siebel Systems, May 2003. http://www.ibm.com/developerworks/library/
specification/ws-bpel/.
[6] Apache Foundation. Apache Karaf. http://karaf.apache.org/.
[7] Apache Foundation. ApacheODE. http://ode.apache.org/.
[8] Apache Foundation. ApacheODE Execution Events. http://ode.apache.org/
ode-execution-events.html.
[9] Apache Foundation. ApacheODE Management API. http://ode.apache.org/
management-api.html.
[10] Apache Foundation. ServiceMix 4.3.0 Documentation. http://servicemix.apache.org/
documentation.html.
[11] D. Chappell. Enterprise Service Bus. O’Reily, 2004.
[12] A. Colyer, H. Hildebrand, C. Leau, and A. Piper. Spring Dynamic Modules Reference
Guide. Spring Source. http://static.springsource.org/osgi/docs/1.2.1/
reference/html/.
116
BIBLIOGRAPHY 117
[13] M. Das, A. Yiu, and K. Kand. A Close Look at BPEL 2.0. SOA World Magazine, October 2007.
http://soa.sys-con.com/node/434430.
[14] N. Deakin. JSR-000914 JavaTM Message Service (JMS) API. Technical report, Sun Microsystems.
http://jcp.org/aboutJava/communityprocess/final/jsr914/index.html.
[15] R. B. Doorenbos. Production Matching for Large Learning Systems. PhD thesis, Computer
Science Department, Carnegie Mellon University, Pittsburgh, PA, January 1995. http://
reports-archive.adm.cs.cmu.edu/anon/1995/CMU-CS-95-113.pdf.
[16] T. Duszka and J. Janczak. Badanie wydajnosci systemów o architekturze SOA. Master’s thesis,
AGH University of Science and Technology, 2008.
[17] Eclipse Foundation. Equinox. http://www.eclipse.org/equinox/.
[18] Eclipse Foundation. SWT: The Standard Widget Toolkit. http://www.eclipse.org/swt/.
[19] T. Erl. SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series
from Thomas Erl). Prentice Hall PTR, Upper Saddle River, NJ, USA, 2007.
[20] O. Etzion and P. Niblett. Event Processing in Action. Manning, 2011.
[21] Fuse Source. ServiceMix Integration Testing Classes. http://fusesource.com/
docs/esb/4.4/apidoc/nmr/org/apache/servicemix/platform/testing/
support/package-tree.html.
[22] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addison-Wesley, 1995. http:
//www.amazon.co.uk/exec/obidos/ASIN/0201633612/citeulike-21.
[23] A. G. Ganek and T. A. Corbi. The dawning of the autonomic computing era. IBM Syst. J., 42:5–18,
January 2003.
[24] T. Gardner. UML Modelling of Automated Business. In Proceedings of the First European
Workshop on Object Orientation and Web Services at ECOOP, 2003.
[25] IBM. Common Base Event. http://www.ibm.com/developerworks/library/
specification/ws-cbe/.
[26] IBM. Integrated Service Management. http://www.ibm.com/ibm/
servicemanagement/us/en/getting-started.html.
[27] IBM. Target Platform. http://publib.boulder.ibm.com/infocenter/ratdevz/
v8r0/index.jsp?topic=/org.eclipse.pde.doc.user/concepts/target.
htm.
[28] JBoss Community. Drools Conflict Resolution. http://legacy.drools.codehaus.org/
Conflict+Resolution.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
BIBLIOGRAPHY 118
[29] JBoss Community. Drools Fusion User Guide. http://docs.jboss.org/drools/
release/5.2.0.M2/drools-fusion-docs/html_single/index.html.
[30] JBoss Community. JBoss jBPM - Workflow in Java. http://docs.jboss.org/jbpm/v3.
2/userguide/html_single/#jpdl.
[31] Z. Krzysztof. Raport z prac wykonanych w ramach zadania OB7-2: Opracowanie systemu
monitorowania aplikacji SOA. Technical report, AGH University of Science and Technology, 2009.
[32] KVM. Kernel Based Virtual Machine. http://www.linux-kvm.org/page/Main_Page.
[33] T. Masternak, M. Psiuk, D. Radziszowski, T. Szydlo, R. Szymacha, K. Zielinski, and D. Zmuda.
ESB - Modern SOA Infrastructure. 2010.
[34] Open Financial Market Platform. Open Financial Market Platform. http://www.eclipse.
org/ofmp/.
[35] OSGi Alliance. OSGi Technology. http://www.osgi.org/About/Technology.
[36] M. Psiuk. OSGiMM Developer Guide. AGH University of Science and Technology. https:
//www.soa.edu.pl/AS3-Studio/?q=node/37.
[37] M. Psiuk. OSGiMM Overview. AGH University of Science and Technology. https://www.
soa.edu.pl/AS3-Studio/?q=node/38.
[38] Quality Open Software. Simple Logging Facade. http://www.slf4j.org/.
[39] T. Rademarkers and J. Dirksen. Open Source ESBs in Action. Manning, 2010.
[40] D. Radziszowski, M. Balawajder, P. Dadel, and K. Doroz. AS3 - BPEL monitoring framework, the
new approach to Business Process Monitoring. 2010.
[41] Spring Source. Spring Dynamic Modules Reference Guide. http://static.
springsource.org/osgi/docs/1.2.1/reference/html/testing.html.
[42] Spring Source. Spring Framework Reference Documentation. http://static.
springsource.org/spring/docs/3.1.0.M1/spring-framework-reference/
html/.
[43] R. Ten-Hove. Enterprise Service Bus. http://blogs.oracle.com/rtenhove/entry/
what_is_enterprise_service_bus.
[44] Terracota Inc. Ehcache Standalone and General Contents. http://ehcache.org/
documentation/index.html.
[45] The OSGi Alliance. OSGi Service Platform Core Specification, Release 4, Version 4.3. Technical
report, The OSGi Alliance, April 2011.
[46] W3Schools. XPath Tutorial. http://www.w3schools.com/xpath/default.asp.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis
BIBLIOGRAPHY 119
[47] Workflow Management Coalition. Workflow management coalition, terminology
and glossary, Feb 99. http://www.wfmc.org/Download-document/
TC-1011-Term-Glossary-V3.html.
[48] K. Zielinski, T. Szydło, R. Szymacha, J. Kosinski, J. Kosinska, and M. Jarzab. Adaptive SOA
Solution Stack. Services Computing, IEEE Transactions on, PP(99):1, 2011.
[49] D. Zmuda, M. Psiuk, and K. Zielinski. Dynamic monitoring framework for the SOA execution
environment. Procedia Computer Science, 1(1):125 – 133, 2010. ICCS 2010.
P. Dadel, M. Balawajder SOA Oriented Business Process Monitoring and Analysis