Wydział Elektrotechniki, Automatyki, Informatyki i ... · Akademia Górniczo-Hutnicza im....

120
Akademia Górniczo-Hutnicza im. Stanislawa Staszica w Krakowie Wydzial Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA I NFORMATYKI P RACA MAGISTERSKA P RZEMYSLAW DADEL ,MARIUSZ BALAWAJDER A NALIZA I MONITOROWANIE P ROCESÓW B IZNESOWYCH Z GODNIE Z PARADYGMATEM SOA P ROMOTOR: dr in˙ z. Dominik Radziszowski Kraków 2011

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