MASARYK UNIVERSITYFACULTY OF INFORMATICS

}w !"#$%&'()+,-./012345

Declaration

Hereby I declare, that this paper is my original authorial work, which I have worked out bymy own. All sources, references and literature used or excerpted during elaboration of thiswork are properly cited and listed in complete reference to the due source.

Advisor: RNDr. Jan Pavlovic

ii

Acknowledgement

I would like to thank my advisor RNDr. Jan Pavlovic for motivation to write about thistopic. I also appreciate consulting and good advice from developers of SUN Microsystems,namely Gabriel Badescu and Ricardo Rocha.

My thanks also belong toWolfgang Schmidt and Stephan Pfeiffer fromX-integrate GMBHin Kln, Germany where I wrote most of the thesis during my internship, which was veryilluminative in integration and SOA related topics.

iii

Abstract

This document explains Business Activity Monitoring (BAM), its role in Business ProcessManagement Systems (BPMS) and context of Service Oriented Architecture (SOA) whereit is used. It discusses the role and purpose of process oriented solutions in enterprise sys-tems and service orchestration in context of enterprise integration. One chapter is relatedto Common Event Processing (CEP) in BAM context. The document also describes the de-velopment of monitoring solutions from business goals definitions to a deployable monitormodel. Later I propose generic architecture of BAM engine, that can be used for developingBAM solutions namely on Open Source platforms. A part of the thesis is also a prototype ofBAM engine, implementing the proposed architecture. The paper also discusses the state ofthe arts of BAM in Commercial and Open Source world.

iv

Keywords

BAM, SOA, BPMS, CEP, monitoring, Business Acticity Monitoring, BAM prototype, Opensource BAM

v

Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation & Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Goals of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Trends in SW engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Integration of IT in Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Processes & flat hierarchies in workflow . . . . . . . . . . . . . . . . . . . . . . 3

1.6.1 Flat organization structure . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6.2 Business process as a know-how . . . . . . . . . . . . . . . . . . . . . . 4

2 SOA overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 SOA - evolution not revolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Service definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Why SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Dependency and loose coupling . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Easy maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Segregation of service consumers/provider . . . . . . . . . . . . . . . . 62.2.4 Leverage of legacy systems . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Focus of SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Enterprise integration and SOA layers . . . . . . . . . . . . . . . . . . . . . . . 72.5 SOA technologies - Web services and XML messaging . . . . . . . . . . . . . . 7

2.5.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.3 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Services Orchestration and Choreography . . . . . . . . . . . . . . . . . . . . . 92.6.1 Choreography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.2 Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 Integration with SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7.1 Service Hub scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7.2 Service Bus scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7.2.1 Role of JBI standard . . . . . . . . . . . . . . . . . . . . . . . . 102.7.2.2 JBI components as containers . . . . . . . . . . . . . . . . . . . 12

3 BPMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1 Processes as conductors of services . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Process lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.4 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Roles in BPM solution development . . . . . . . . . . . . . . . . . . . . . . . . 143.3.1 Business architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

vi

3.3.2 BPM specialist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.3 BPM administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.4 Business user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4.1 Inputs, outputs and variables . . . . . . . . . . . . . . . . . . . . . . . . 173.4.2 Process structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.5 BPMS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.1 Modeling tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.2 Process Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.3 Business Activity Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Intermezzo: Common Event Processing and Query languages . . . . . . . . . . . 194.1 Communication as a flow of events . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Event processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Event processing query languages . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.1 CQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3.2 EQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 BAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.1 Business process optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Business Process measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.1 Monitoring item instance . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.2 Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.3 KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.4 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.5 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.6 Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.7 Monitoring scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.8 Business situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3 Monitor model development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3.1 KPI definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3.2 Metrics definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3.3 Interactions and business situations . . . . . . . . . . . . . . . . . . . . 24

5.4 BAM results visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.4.1 Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.4.1.1 Process instance data tables . . . . . . . . . . . . . . . . . . . . 255.4.1.2 Gauges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.4.1.3 OLAP-like analysis . . . . . . . . . . . . . . . . . . . . . . . . 26

5.5 BAM vs. technical monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.6 BAM in non process enabled environment . . . . . . . . . . . . . . . . . . . . . 275.7 BAM reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.7.1 Document flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.7.1.1 Design time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.7.1.2 Run time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

5.7.1.3 Post runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.7.2 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.7.2.1 Modeling tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.7.2.2 BAM core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.7.2.3 CEP engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.7.2.4 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.7.2.5 Long term data mining BI tools . . . . . . . . . . . . . . . . . 31

5.8 Prototype design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.8.1 Prototype goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.8.2 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.8.3 Prototype use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.8.4 Prototype components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.8.4.1 BAM core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.8.4.2 Web frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.8.4.3 Event emitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.8.5 Prototype usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.8.6 How to run the prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1 State of the arts in BAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

viii

Chapter 1

Introduction

In this chapter I will introduce my work, mention the context in which I decided to writethis thesis, as well as my motivation for this topic. Second part of this chapter is related tothe document structure. It should give you some hints, how to read this document. Thirdpart introduces goals of the thesis. In fourth part I will review some milestones of softwareengineering in the context of my topic. Fifth part describes relationship between businessand information technologies that seems to be very important these days. At the end of thechapter I will discuss workflow approaches, especially the process oriented one.

1.1 Motivation & Context

First of all, I would like to mention the circumstances that motivated me to focus my thesison Business Processes, particularly on Business Activity Monitoring.

Since my first few years at the Masaryk University when I acquired an overview oversoftware engineering, I considered Information Systems the most interesting. InformationSystems compared to other commodity software are developed more systematically, withemphasis on architecture and planning. As low level technologies in hastily evolving worldof software are thrown away every two years and replaced with new ones, software archi-tecture is maturing like wine and it is building on top of previous knowledge.

Our Faculty of Informatics providing freedom in the choice of optional courses, allowedme to go from basic software technologies through architecture oriented courses to BPMrelated ones. There are also enough of fundamentally oriented courses necessary to under-stand the formal theory standing behind process modeling, such as Petri Nets or LambdaCalculus.

One of the circumstances that led me to this topic was a contact with couple of peoplein OpenESB team of SUN Microsystems. In time of writing my thesis there is an ongoingeffort at SUN Microsystems to develop BAM component for OpenESB. Consultations andexchanges of ideas with themwere really useful for me. And I hope for them aswell. I wouldlike to thank them again for their cooperation.

1.2 Document structure

The document is structured in 4 main chapters. First chapter is introductory. Here I discussthe context and circumstances that led me to choose the topic, a small tour in the history of

1

1.3. GOALS OF THE THESIS

SW engineering and relation of this topic to workflow.Second chapter gives an overview over SOA approach. It describes main reasons for

SOA approach and gives a short insight in the used technologies. I will also examine somebasic approaches to system integration, used technologies, standards and role of BusinessProcesses in SOA.

Third chapter is about Business Process Management Systems. It discusses process life-cycle and roles in BPM solution development. Then shortly review BPEL, which is a stan-dard in process execution languages nowadays. At the end BPMS architecture and compo-nents are discussed.

Fourth chapter is a necessary intermezzo, explaining Common Event Processing whichis necessary for understanding the last chapter related to BAM.

Fifth chapter is finally related to Business Activity Monitoring. At the beginning I ex-plain Business process measurement and roles in monitor model development. Later I dis-cuss BAM architecture I propose and development of monitor models and common ways ofvisualization.

Last chapter just concludes the whole thesis, presents results and discusses which goalswere achieved and how.

1.3 Goals of the thesis

This thesis has several goals. First, to review the situation of Service Oriented Architectureand its usage in development of Information Systems. Second, to explain the purpose ofBusiness Process approach in SOA scope and finally andmost importantly, to gather the bestpractices in Business Activity Monitoring and propose generic architecture that can be usedfor development of Business Activity Monitoring solutions. That could be used especiallyin development of BAM solutions for open source BPMS. For this purpose I developed aprototype which is a part of this thesis. The prototype implements the basic concepts of theproposed architecture.

I try to give the vendor an independent insight in BPMS, thus some of the parts are rathergeneral. I describe the best practices rather than a solution for one particular vendor. Also thefirst boom of BPM brings many vendor specific solutions, but as BPMS are maturing thesedays, many important standards are defined, hence BPMfield tends to bemore cohesive andprovide more standard structure of BPMS and better cooperation of SOA based solutions ingeneral.

I will also try to give more general architectural overview rather than describe technicaldetails, because as I mentioned before BPMS is evolving rapidly, thus some this detailedinformation could be outdated even before this work will be finished. But of course I willtry to provide sources where those technical details can be found.

2

1.4. TRENDS IN SW ENGINEERING

1.4 Trends in SW engineering

As history of software engineering is quite short, we saw many revolutions and significantchanges. In early years, software architecture was driven by hardware limitations. Softwareproducts were compact single-purpose. In those days people kept up with hardware andused all opportunities given by computing power available.

As hardware performance grows exponentially, software complexity grows aswell. Gooddecisions made at the planning level become more and more important. These days we donot consider hardware limitations as the biggest problem anymore. Today we deal with an-other problem: How to get this complexity under control.

Modern software engineering copes with the complexity by building new layers on theexisting ones. In the higher layers implementation details are hidden. Examples of thesehigher layers can be modern high level programming languages or modeling languageslike UML. Then we use tools to generate implementation in lower layers. Higher layers aremore similar to the objects, actions and processes we recognize in the real world than thelower ones. This enables us to apply principles we know from the real world.

1.5 Integration of IT in Business

At the beginning of IT era, business people considered IT as something costly and mysteri-ous and not really reliable. Since IT is much more a part of everything around us these days,it also went deeper in business. These days IT is not used just as an office tool. Today a lotof business is driven by IT.

1.6 Processes & flat hierarchies in workflow

Process approach in workflow comes with the need for flexible and fast reactions to changesof market and demand. Usual concept of company structure is a hierarchical one. Such acompany organization has a tree structure, with a lot of steps from the highest chairmanto the lowest worker. This approach of course has the advantage that chairmanship hascontrol over everything, but is less flexible in case of significant changes on market. Todayfast evolving global markets bring a need for more flexible flat organization structures.

1.6.1 Flat organization structure

Flat organization structures provide higher flexibility on one hand, but require more infor-mation exchanges on the other hand. Those information exchanges have to be done accord-ing to predefined strategy and rules. And that is where the business processes come to focus.

3

1.6. PROCESSES & FLAT HIERARCHIES IN WORKFLOW

1.6.2 Business process as a know-how

Definitions vary, but in general we can say that Business process is a sequence of steps thatconsumes inputs and generates output with added value. This is quite a general definitionwhich doesnt explain too much.

In practice business process is a sequence of steps and rules that define the behaviour ofthe company in particular business situations. Those sequences are an important part of theknow-how of the company. By means of business processes we define documents (processmodels) describing those sequences. This is important because company does not risk losingits knowhow with leaving of an executive employee. This is of course an advantage forcompany chairmanship, because they dont have to be afraid of know-how loss in case someexecutives leave the company. On the other hand between the employees this approach isnot so popular because they feel like they are easily replaceable.

4

Chapter 2

SOA overview

This chapter is related to Service Oriented Architecture. It should review the SOA approach,describe basic technologies in SOA environment and explain the role of BPMS in SOA con-text. In the first section I will introduce SOA and mention the main reasons for coming ofSOA. Later I will mention the main field and context in which SOA is used. I will continuewith describing SOA layers in enterprise systems. Then I will give a small tour throughmostimportant SOA related technologies. In the next section I will describe twomain approachesused for service coordination. Last section will review a couple of integration scenarios inSOA context.

Analysts have predicted, pundits have professed, professors have lectured,companies have scurried to sell what they had, as SOA products oftenmiss-ing the point that SOA is not a product. Its about bridging the gap betweenbusiness and IT through a set of business-aligned IT services using a set ofdesign principles, patterns, and techniques. [2]

Dr. Ali Arsanjani, Chief Architect, IBM 9th November 2004

2.1 SOA - evolution not revolution

Since 90 there is a new trend in Software Architecture called Service Oriented Architecture.This approach sees software as independent components communicating and providingservices to each other. This is something natural that we can see in our everyday lives, forexample in business architecture.

This approach is not a new invention, but with growing complexity of software it ap-peared as a natural need. Because of that it slowly sneaks into software architecture andsometimes we do not even notice that we already use this approach.

One of the important impulses for SOA approach was the boom of the Internet and net-working. The Internet provided necessary infrastructure and allowed systems to commu-nicate with each other. That forced the people to think about the software as independentcomponents communicating with each other, rather than monolithic pieces of a code exe-cuted on one machine.

5

2.2. WHY SOA?

2.1.1 Service definition

A service (in SW context) is a software resource (discoverable) with an externalized servicedescription. This service description is available for searching, binding, and invocation by aservice consumer. The service provider realizes the service description implementation andalso delivers the quality of service requirements to the service consumer. [2]

2.2 Why SOA?

As SOA evolved in architectural approach there were several main points defined. Thosepoints should provide an answer to the question Why should we change to SOA ap-proach?

2.2.1 Dependency and loose coupling

One of the main goals of SOA is to make software components as independent of each otheras possible. SOA approach puts emphasis on loose coupling between components. Loosecoupled components can be easily replaced and modified. Loose coupling also allows plat-form independency and location transparency. Particular components can run on differentplatforms and machines can be located anywhere and communicate with each other even ifthey are remote.

2.2.2 Easy maintainability

Loose coupling allows us to replace components easily, redirect service to another compo-nent or simulate one component with another without an impact on the whole system.

2.2.3 Segregation of service consumers/provider

One of the other important features is that components are not tied upwith service providersand consumers. Segregation of business logic isolates the core processes of the applicationfrom other service providers and consumers. [6]

2.2.4 Leverage of legacy systems

One of the advantages of the SOA approach is that it enables usage of legacy systems. Wejust have to build an adaptor for the legacy system. This adaptor communicates with thelegacy system in its native protocol and provides service interface on the side of SOA basedsystem. When legacy system sends a message, it is transformed by the adaptor in a SOAPmessage and sent to any modern components. After the message is processed, the responseis translated back to the legacy format and delivered to the legacy component. The samecommunication is done in the opposite direction.

6

2.3. FOCUS OF SOA

2.3 Focus of SOA

Another important thing I would like to clarify is the scope where SOA is applied. Of courseservice oriented approach can be used on many levels of granularity.

The main use of SOA is enterprise systems. Those systems are usually accompanyingmany independent sub-systems providing different functionality for different employees ordepartments. SOA is applied on integration level. It means we use SOA approach to inter-connect them together. With components providing services to each other, we can defineclear structure of integration.

2.4 Enterprise integration and SOA layers

Enterprise systems usually consist of various operational systems processing particular data,such as accounting, warehouse systems, CRMs andmany others.This is shown on Figure 2.1.Those systems form bigger units called Enterprise components. One Enterprise componentis usually dedicated to one field of interest such as finance, warehouses etc. Those com-ponents dont exist on physical level, but are defined during integration analysis to groupservices provided by operational systems.

On business process level we define processes which are sequences of tasks using thoseservices. Particular tasks or their results are then presented to the user on presentation layer.

Operational layer

Enterprise layer

Services

Business Process choreography / orchestration

Presentation layer

2.5 SOA technologies - Web services and XML messaging

Just for completeness, I would like to mention some of the most important technologiesused in web-service context. I will not go deep in technical details, since those technologiesevolve really quickly.

To be able to interconnect heterogeneous systems and allow them to communicate witheach other there is a need for common message format. As XML has become the most popu-lar document format nowadays, it is used for most of the message oriented communication.Because of massive W3C standardization, there are many standards for service messagingsuch as SOAP.

7

2.5. SOA TECHNOLOGIES - WEB SERVICES AND XML MESSAGING

Figure 2.1: Layers of SOA in enterprise systems

2.5.1 SOAP

SOAP is a lightweight protocol intended for exchanging structured information in a decen-tralized, distributed environment. [7]

SOAP is messaging standard defined by W3C since 2000 (older version SOAP 1.1). TheSOAP architecture consists of several layers of specifications for message format, messageexchange patterns (MEPs), underlying transport protocol bindings, message processingmod-els, and protocol extensibility. [8]

8

2.6. SERVICES ORCHESTRATION AND CHOREOGRAPHY

2.5.2 WSDL

WSDL is an XML format for describing network services as a set of endpoints operatingon messages containing either document-oriented or procedure-oriented information. Theoperations and messages are described abstractly, and then bound to a concrete networkprotocol and message format to define an endpoint. Related concrete endpoints are com-bined into abstract endpoints (services). [7]

2.5.3 UDDI

The Universal Description, Discovery, and Integration (UDDI) protocol is an approved OA-SIS Standard and a key member of the Web services stack. It defines a standard method forpublishing and discovering the network-based software components of a service-orientedarchitecture (SOA). [9]

In other words UDDI is kind of web service registry service providing Yellow Pagesfor Web services.

2.6 Services Orchestration and Choreography

Suppose we have several components, each of them provides some services. To be able toaccomplish particular task using those services we have to define a sequence and rules howto use them. There are two different approaches to doing that. Their names are analogiesfrom theatre environment and they reflect the principles quite accurately. Both have theirpros and cons and each of them fits for different scenarios.

2.6.1 Choreography

Choreography approach is based on the idea that each actor knows what should he do andhow. In that approach we define the behaviour of the services inside the component. Eachcomponent knows how to communicate with another one, when and which service to use.The advantage of this approach is decentralization. Services can be quite independent andthere is no central control point.

2.6.2 Orchestration

Due to the above mentioned fact, choreography approach is less flexible for the scenariowhere we have control over all the components. It also does not fit well for our process basedsolution. Here we want some global conductor, who will control the communication of allcomponents. When we make changes we just change the conductor behaviour. And therethe orchestration comes to use. The conductor in this case is a process engine component. Itfollows the process steps, calls services of other components, sends responses back to othercomponents, orchestrates human tasks and processes business rules. This will be discussedin detail later in a chapter related to BPMS.

9

2.7. INTEGRATION WITH SOA

2.7 Integration with SOA

The main purpose of SOA is undoubtedly system integration. In the course of time therewere a lot of communication protocols and channels developed. There are many technolo-gies such as Email, HTTP, SOAP, binary and proprietary protocols and many others. Eachof them is dedicated to a particular purpose and has its own pros and cons. For interconnec-tion of those components which are speaking different languages we need some universalchannel. Nowadays there are twomain integration patterns used. Both have its purpose andboth are widely used. The first is Hub integration approach which is used more for pure in-tegration, the second is Service Bus approach which is more widely used in the context ofprocess oriented solutions. Sometimes we can even combine both of these approaches.

2.7.1 Service Hub scenario

This approach fits better to a situationwherewe have couple of components in heterogonousenvironment of several autonomous systems and we want to send messages between them.This scenario is suitable for leveraging the legacy systems. Service hub is a kind of trans-lator of their messages. We can see this scenario on Figure 2.2. Independent componentsspeak in their own language (send messages) to the hub. Those messages are translated,routed and delivered to the desired component in a desired format. This scenario is a goodexample of the use of Choreography service approach.

As we can see on Figure 2.2, central hub acts as a Message Broker. Brokering in thiscontext means, that the hub holds information about service providers and consumers. Thatway the provider and the consumer do not have to know so much about each other, theycommunicate just with the Broker.

2.7.2 Service Bus scenario

Service Bus ( Figure 2.3) is another approach to integration. Particular component send datain its language to Binding Component, which is a kind of adaptor that transforms themessage in universal language (nowadays usually SOAP protocol) of the Service Bus andsends it through Bus. The data go through bus to their recipients endpoint, where they areagain transformed by Binding component and delivered. This enables wide interconnectionbetween the components. Even the completely unknown protocol can be used if there is abinding component for it. This seems to be similar to Hub approach. The main difference isthat on ESB the communication is done mostly through SOAP protocol and in most casesthe Process Engine is present to manage the orchestration.

2.7.2.1 Role of JBI standard

The JBI 1.0 (JSR 208) specification is an industry-wide initiative to create a standardized inte-gration platform for Java and business applications. JBI addresses service-oriented architec-ture (SOA) needs in integration by creating a standardmetacontainer for integrated services.

10

2.7. INTEGRATION WITH SOA

Figure 2.2: Message broker - Service hub scenario

JBI is a messaging-based plug-in architecture. This infrastructure allows third-party compo-nents to be plugged in to a standard infrastructure and enables those components to in-teroperate seamlessly. It does not define the pluggable components themselves, but definesthe framework, container interfaces, behaviour, and common services. The meta- containeris itself a service-oriented architecture. JBI components describe their capabilities throughthe Web Service Definition Language (WSDL).

The major goal of JBI is to provide an architecture and an enabling framework that facil-itates dynamic composition and deployment of loosely coupled composite applications andservice-oriented integration components. It allows anyone to create JBI- compliant integra-tion plug-in components and integrate them dynamically into the JBI infrastructure.

JSR 208 specifies two deployable archive packages ( .jar files) called Service Unit and

11

2.7. INTEGRATION WITH SOA

Figure 2.3: Service Bus scenario

Service Assembly. These archives contain code and standard descriptors, in amanner similarto WAR and EAR packaging in Java EE 5. [6]

The JSR208 specification provides three installable JBI components: Service Engines, Bind-ings, and Shared Libraries. JBI components operate within a JBI container, which is definedby the JSR208 specification. Two popular implementations of JBI containers are Project OpenESB and ServiceMix. [4]

2.7.2.2 JBI components as containers

A very important thing to clarify in JBI context is the role of JBI components and their rela-tion with Service Units and Service Assemblies.

BCs and SEs can act as containers, and Service Units can be deployed to installed JBIcomponents. This arrangement allows the deployment (and undeployment) of component-specific artefacts (for example, concrete WSDLs). Service Units can describe what servicesare provided and consumed by the JBI component. Besides the standard descriptor, the JBIcomponent is responsible for interpreting the contents of the Service Unit .jar file. [6]

Multiple Service Units can be packaged in a Service Assembly. The Service Assemblydefines the target JBI components to which to deploy the Service Units.

12

Chapter 3

BPMS

At the beginning of this chapter I will explain the basic ideas of Business Process Manage-ment Systems and their role in the context of SOA. Then I will go quickly through processlifecycle, explaining the role of BPMS components in particular lifecycle phases. Then I willdiscuss the development of process models, and roles in that development. Next part willgive an overview over BPEL, the most popular process execution language. Then I will ex-amine BPMS architecture and describe basic components and services they provide. In theend I will mention the purpose of monitoring and optimization, but only briefly because itwill be examined more closely in the following chapter.

3.1 Processes as conductors of services

Once we have SOA components communicating through services, ESB as a communicationchannel, SOAP as universal language and we need conductor component that will coordi-nate the behaviour of components. And that is where BPMS appears.

We define a sequence of tasks that have to be done by our SOA components to ac-complish one business task. This is called Business Process. That process is deployed toprocess engine and launched. During runtime process calls services, invokes human tasksand makes decisions according to business rules. The advantage of the process oriented ap-proach is that we can easily monitor the desired processes and optimize them according toour needs.

3.2 Process lifecycle

At the beginning of process lifecycle ( Figure 3.1) we take Business process definitions, whichare result of business decisions made during Business analysis. In process lifecycle we de-fine four stages, which are repeated during process evolution. Document flow during thosephases is shown on Figure 3.2.

3.2.1 Specification

At this stage purpose and description of the process is specified and the process is usuallymodeled with the help of some graphical modeling tool, without too many technical details.

13

3.3. ROLES IN BPM SOLUTION DEVELOPMENT

Figure 3.1: Process lifecycle

3.2.2 Implementation

Here are clarified implementation details of the process, such as data types, connectors toother components etc. Then the process is implemented, tested and deployed in a processengine.

3.2.3 Monitoring

In this phase, which can take a long time, a business specialist watches the process behaviourand its impact on business. The monitoring is usually done with a BAM tool.

3.2.4 Optimization

At this point the process is reimplemented and optimized to better fulfil business needs.Here both business and IT specialists cooperate.

3.3 Roles in BPM solution development

In contrast to usual IT products, BPM solutions are developed in very tight cooperation ofthe business and IT specialists. BPM based solutions are usually complex and many peopleparticipate on the development process. Because of that we recognize several roles usuallydefined in BPM development context. Depending on the complexity of the project and theBPMS vendor some of the roles can be merged or responsibilities redirected. Roles and theiruse cases are shown in Use Case Diagram on Figure 3.3

14

3.3. ROLES IN BPM SOLUTION DEVELOPMENT

Figure 3.2: BPMS document flow

3.3.1 Business architect

This role describes an employee of a customer or an insider, who has a good overview overbusiness, knows what customer needs and what the business goals and the pitfalls are. Heshould have a tight connection with chairmanship and a good insight in business goalsdefinition.

He is responsible for the communication with the chairmanship, discovering and clari-fying how the processes should look like and defining them. The processes are usually firstdescribed by natural language or some formal way, depending on used methodology. Thenthey are modeled as process diagrams with some kind of notation such as BPMN. A per-son in this role does not have to be technically skilled, but he should be familiar with BPMdevelopment methodologies.

If the process simulation is supported by a modeling tool, a business architect can alsorun process simulation and analyze the efficiency of the processes.

A business architect should also know which measures are important and define themetrics and KPIs that will be measured during process runtime.

3.3.2 BPM specialist

This is a role for a more technically oriented person, who has deep knowledge of BPMSand is also skilled in technical area. His task is to take the process model created by Busi-ness Analyst and implement it as BPEL processes and take care of its integration with othercomponents. He should know BPEL as well as the underlying platform (nowadays mostlyJ2EE).

Some vendors of BPMS provide tools to export a model created by a business architect

15

3.3. ROLES IN BPM SOLUTION DEVELOPMENT

Figure 3.3: BPMS development - Use case diagram

and import it into tools used by BPM specialist. This can simplify the BPM specialists job,but limit the freedom of expression of the business architect, because he has to use a limitedset of modeling components provided by BPMS.

He also receives the definitions of KPIs and metrics and he develops a monitor model.This should be done when process model is finished because monitor model depends onstructure of processes.

3.3.3 BPM administrator

This role stands for BPM administrator, defining the roles in the system. He administratesuser rights, grants them an access to certain resources and allows them to fulfil certain hu-man tasks. He can adjust runtime details of the process solution.

3.3.4 Business user

This role stands for a user of BPM solution who is focused on monitoring and analyzing ofbusiness data. He is accompanied in development because he uses frontend part of Busi-ness Activity Monitor to develop and analyze dashboards. He can also develop a custom

16

3.4. BPEL

dashboard for other users.

3.4 BPEL

To be able to implement and run processes we need a language that expresses the processesand can be interpreted. There is a standard for Business Process Execution Language calledWS-BPEL. The whole idea was started in 1993 by a couple of big players in BPM. TodayBPEL 2.0 is a widely used standard with many implementations. BPEL is XML based lan-guage, describing processes and their structure. I am not going to provide a detailed BPELstudy here, also because the language evolves very quickly and provided information cansoon become out-of-date. Just to illustrate what BPEL can express, I will mention severalimportant matters.

3.4.1 Inputs, outputs and variables

BPEL define inputs and outputs of the whole process as well as inputs and outputs forparticular steps. We can define variables that are visible inside a certain block of process andmake assignments and operations over them.

3.4.2 Process structure

We can define usual structures in process such as conditions, loops, time and variable basedconditions, parallel nodes, decision points etc. We define both the main and the optionalprocess flows here.

3.5 BPMS architecture

Business Process Management System means a complex set of software components andtools that together provide functionalities that allow us to develop, deploy and run ourprocess based solution. Depending on the vendors some of the components are merged,some are not present, but all of the vendors more or less follow the same structure.

3.5.1 Modeling tools

Those tools are used mostly in initial phases of development of BPM solution. Input is usu-ally a description of processes and scenarios of their usage. According to specifications de-velopers create a process model and later also its implementation with all the communica-tion and interconnection of involved components.

3.5.2 Process Engine

This is a server side application executing the processes. Process engine usually interpretsBPEL or another language for process definition.

17

3.5. BPMS ARCHITECTURE

3.5.3 Business Activity Monitor

Business Activity Monitor is a server side tool monitoring process engine, Service Bus mes-saging and all the events in BPM solution.

18

Chapter 4

Intermezzo: Common Event Processing and Query languages

This short chapter should explain what Common Event Processing (CEP) is. Understandingof CEP is necessary for understanding of BAM, as CEP output is the data source for BAMsolution. Here I will discuss what event driven approach is, how to do CEP and mentionsome query languages used in CEP.

4.1 Communication as a flow of events

As the SOA approach is based on independent components, we can see a growing complex-ity of communication. From an event-based point of view we can see all the communicationas a flow of events. A lot of the SOA based systems are event-driven, meant componentsreact on event and produce new ones.

4.2 Event processing

At this stage the problem of monitoring of those events comes into focus. Sometimes weneed to monitor events, query the event flow and react on results of those queries in a real-time or near-real-time. Communication is fast and often a large amount of data is trans-ferred.

The simplest approach to deal with this monitoring is to log the communication andprocess the logs. This idea has several bugs in our context. First, we want real-time reactionso logging and later processing brings delay. Second, if we want to find something morecomplex such as event concurrence, event patterns, timing patterns etc, we have to processlogs many times. Then we easily get efficiency problems and we are definitely not near-real-time anymore, literally said, we are lost in the woods.

The problem of the logging approach is that we log even the events that we do not careabout. So we have to find a way how to skip the data we are not interested in. The solution isa mechanism that processes those event flows, catches wanted events and ignores the rest.This is what we call Event Processor. In fact Event Processor is a kind of filter. The problemis that sometimes patterns of the events we need to catch are so complex that they need their,own language.

19

4.3. EVENT PROCESSING QUERY LANGUAGES

4.3 Event processing query languages

The topic of event processing is not new and was discovered much earlier than anybodythought about SOA and BPM. Several approaches come from early nineties. It was soonclear that the solution is a declarative language. Of course it is good to reuse knowledge ofquery languages used in relational databases, so most approaches are similar to SQL. Forbasic patterns the SQL-like expressions like SELECT, FROM, WHERE etc. are sufficient, butin event-processing environment we want a more detailed expression. Very often we wantto use time-window and watch the concurrence of events during the time period defined bythe window. We also want to query for sequences and patterns in sequences. The query lan-guage differs at this point and offers different functionalities. Below I will mention severalimportant languages with their functionalities.

4.3.1 CQL

One of the well known languages is CQL developed at Data StreamManagement System atStanford. There is a complex formal background behind that language. It was developed inStanford in the nineties based on several previous approaches such as Tapestry or Aurora.What is important from BAM point of view is that it is used by SUNMicrosystems in Eventprocessor used within OpenESB platform.

4.3.2 EQL

Quite an interesting and flexible event processing query language is EQL (Event query lan-guage) developed in open source project called Esper. EQL have usual SQL-like syntax, plusseveral advanced features like time windows, time batches, stream aggregators etc. Becausethe whole Esper project is very well done and documented and also the EQL is quite pow-erful, this seems to be a good choice.

20

Chapter 5

BAM

This chapter is finally related to Business Activity Monitoring. It should explain the purposeof BAM and say something about the Business Optimization and Measurement in general.Then I will explain the logic that stands behind monitoring models. Next section gives aninsight in techniques of BAM results visualization. Then I will introduce my proposal ofBAM architecture which is of course inspired by existing systems. A part of this thesis isalso a BAM prototype that should serve as a proof of the technology. This prototype designwill be discussed in the last section of this chapter.

5.1 Business process optimization

Business process optimization is an activity that should be done iteratively during the life-time of the processes. This activity should be scheduled after process solution is deployedas well as after each significant change in process structure.

Business process optimization is a difficult task and requires good knowledge of businessprocesses inside the organization. However, evenwith themost powerful tool, the optimiza-tion efficiency still depends on the skills of the responsible person.

BAM provides runtime information about the business, allows real-time analysis of theprocesses, shows bottlenecks and unreliable tasks, measures time of each task and providestools to visualize all that information.

Concerning optimization there is one approach that is more a wish than a reality. Itinvolves Artificial Intelligence in business optimization. We know that a lot of AI algorithmscan be useful in optimization tasks. But this is today rather a future vision and at present wecan only see a few cases of real implementation of this. I will go in more detail concerningthis in the last chapter.

5.2 Business Process measurement

As mentioned before, there are two main goals of Business Process oriented solution. First,providing flexibility in process changes and allowing a quick reaction to market changes.Second, providing good insight in processes and allowing efficient business optimization.To be able to optimize we have to knowwhat is wrong or inefficient, so we have to start withthe measurement of the processes. And here we can use the Business Activity Monitoring.

21

5.2. BUSINESS PROCESS MEASUREMENT

This technique allows us to measure various aspects such as time, costs, performance andmany others. To be able to get better insight in this technique we have to understand acouple of basic terms.

5.2.1 Monitoring item instance

Monitoring item instance is the subject of our monitoring. It is often instance of process, butnot necessarily just BPEL process. We can also monitor a process that consists of severalsteps that are identifiable by events delivered to the monitor and include also sequencesdone outside of BPEL engine.

A good example of such monitoring instance can be Order process. Several order pro-cesses can be started at the same time and we want to monitor their state. We usually definemetrics that are computed for every instance.

5.2.2 Metric

In BAM context, metric is the measured attribute of process instance, the aspect of processwe want to monitor. An example of the metric can be order duration time, order cost, cus-tomer name etc.

Once we have metrics defined we can compose them to more complex structures suchas KPIs.

5.2.3 KPIs

KPI are quantifiablemeasurements, agreed to beforehand, that reflect the crit-ical success factors (of the company, department, project). [5]

F. John Reh

From business point of view, KPIs are defined during business goals definition. LaterKPIs measure whether the desired goal was achieved or not. Defining the KPIs is a disciplineof business analyst and should be defined in documents describing enterprise strategy andgoals.

From implementation point of view KPI is an aggregating function over metrics of all orselected monitoring instances.

KPIs are usually composed of aggregation of several metrics or KPIs. An example ofsuch KPI can be the average amount of shipped orders per department, per month.

5.2.4 Trigger

Trigger is a pair of rule and action. The rule defines the condition that leads to firing thetrigger. The action defines the activity that is performed when trigger is fired. Triggers aredefined separately. Once trigger is defined it can be used by metrics and KPIs. An exampleof that can be:

22

5.3. MONITOR MODEL DEVELOPMENT

Once the order fulfilment time exceeds the defined time, fire the time exceeded trig-ger that will start a process that tracks the particular order and sends a warning to a respon-sible person.

5.2.5 Timer

A timer is something like stopwatch. It is started by the trigger and it measures time undercertain conditions. The timer can also set off the trigger when certain interval is reached.Timers are used to measure time. For example we define a timer that measures Order fulfil-ment time. Once the order is finished, the timer stops.

5.2.6 Counter

A counter is a simple mechanism to measure iterative events. Every time the event occursthe counter is increased by one.

For example we define a counter that is increased by one for each cancelled order.

5.2.7 Monitoring scopes

Sometimes we have one process solution that we want to monitor, but different scopes ofmonitoring. For example a financial department has completely different interests in moni-toring the orders, than a logistic department. For this reason we sometimes want to definedifferent monitoring scopes on the same event source. One scope defines its own metrics,KPIs and triggers.

5.2.8 Business situations

One of goal of the feedback provided by BAM is to allow our process solution to react on cer-tain business situations. Most commonly, when some measure such as metric or KPI reachescertain value we want to start a process that will react to the situation in an appropriate way.

5.3 Monitor model development

Good decisions made before and during monitor model development are keys to moni-toring efficiency. Before we start we have to specify what we want to monitor. The wholedevelopment is mostly done top-down. The input for monitor model development are KPIsdefinitions tied with business goals definitions. Those we have to retrieve from business ori-ented documents and follow the KPIs metrics events order. We can see BAM data flowon Figure 5.1. Now let me describe the particular steps.

23

5.3. MONITOR MODEL DEVELOPMENT

Figure 5.1: BAM document flows

5.3.1 KPI definitions

The input for monitor model development should be business goals and KPIs. Those areusually defined before whole process solution is developed. Those inputs come from goalanalysis documents. Every well done goal analysis should contain exact definition of KPIs.KPIs very often also contain the target value and the expected ranges of the value. The goalis to achieve the target value or to be as close as possible.

5.3.2 Metrics definition

Once we have KPIs definitions we have to analyze them and define whichmetrics have to beused. We establish a list of metrics, counters and timers that are required to compute KPIs.We can add additional metrics which are not used for KPI computation, but are interestingand can be useful.

5.3.3 Interactions and business situations

Once we design all the metrics we have to define interactions between them, define triggersand actions that trigger fire. One of them is a reaction to a certain business situation. Thereaction is usually a warning sent to particular channel or a start of another process that

24

5.4. BAM RESULTS VISUALIZATION

reacts to the situation.

5.4 BAM results visualization

This section describes what BAM frontend should deliver to the end user. In business intel-ligence field there are many visualization techniques such as dashboards containing gauges,graphs and figures. There are also more advanced techniques like OLAP multidimensionalviews etc.

5.4.1 Dashboards

Dashboard term came from airplane dashboard and should represent a view that allows usto control a lot of measures in a small area. Today dashboards ( Figure 5.2) are very oftenused in various Business Intelligence tools which are a superset of BAM tools.

Dashboard means a configurable area where we can place several visualization elementsand design it according to our needs.

A small example of typical BI dashboard follows:

Figure 5.2: Dasboard example

From BAM scope there are several basic elements that are used in dashboards.

5.4.1.1 Process instance data tables

One of the elementary functions we expect from the BAM frontend is basic informationabout process instances. Here we want to see the values of metrics for each process instancein a general view, which is usually presented by a data table.

25

5.5. BAM VS. TECHNICAL MONITORING

5.4.1.2 Gauges

Simple visualization element usually used to express value of KPI. Ranges and target arehighlighted with different colour.

5.4.1.3 OLAP-like analysis

On-Line Analytical Processing is a widely used technique for analyzing multidimensionaldata. It has its roots in pure database data analysis, today it is widely used in Business Intel-ligence, financial reporting and forecasting andmany other fields. OLAP allows querying ofmultidimensional data and visualizes the results in tables ( Figure 5.4) or charts ( Figure 5.3).

Figure 5.3: BAM chart example

5.5 BAM vs. technical monitoring

It is important to make a difference between BAM and technical monitoring. Sometimes wecan even use the same or similar tools to do both, so it can be confusing. But the difference

26

5.6. BAM IN NON PROCESS ENABLED ENVIRONMENT

Figure 5.4: BAM table example

is in the result and impact of the monitoring.The result of technical monitoring is stats reports that inform the user how the solution

is working. Sometimes it can be also SOA-based process oriented solution, but it is impor-tant that technical monitoring provides information about performance of the solution andreports if technical requirements are met.

On the other hand business monitoring delivers information how the business goals areachieved. Of course that information is retrieved from system events, so sometimes technicalmonitoring can be an underlying part or a support of BAM.

5.6 BAM in non process enabled environment

Monitoring our business processes in an environment which is not process based, i.e. thereis no process engine, sounds impossible. But surprisingly enough it is possible. Suppose wehave our business strategy, the goals are defined andwewould like tomeasure how success-ful we are in fulfilment of those goals. We have some technical solution consisting of a fewsystems interconnected in some way. If this solution is able to produce events that can beconsumed by our BAM solution, business monitoring is possible. Since BAM is dependentonly on event source, we can still monitor any element we want.

27

5.7. BAM REFERENCE ARCHITECTURE

5.7 BAM reference architecture

At this point I would like to describe the architecture I am proposing. It will be used in aBAM prototype developed as a part of this thesis. This architectural draft is a result of longconsulting with developers of SUNMicrosystems. It should reflect the best practices in BAMas well as flexible architecture that can be used in standardized JBI environment. It shouldpresent BAM as an independent component in JBI environment that cooperates with EventProcessor.

5.7.1 Document flow

Before describing the architecture in detail the data flows in BAM solution should be clari-fied. The document flow diagram on Figure 5.5 shows how artefacts such as documents anddata are transformed during the development. It is divided in run-time and post runtimephases.

Figure 5.5: BAM document flow

5.7.1.1 Design time

In this phase we start the whole monitoring process, define monitor model and deploy it tothe BAM engine.

Inputs:First are business requirements, usually described in natural language or some moreformal way.

Second are event definitions, usually described by some data definition language.Those define the form of event description received formCEP engine. Thismay differ

28

5.7. BAM REFERENCE ARCHITECTURE

vendor to vendor, but in my opinion it is simple and elegant to use XSD as today itis a standard for XML data definitions. The event format is usually retrieved fromprocess model.

Outputs:Output of this phase is a monitoring model containing description of KPIs, metrics,triggers etc. Monitor model defines the overall view of data that are later presentedby frontend. According to this model, corresponding monitoring component is builtand deployed.

5.7.1.2 Run time

During this phase monitor model is executed by BAM-core component and monitoringstarted. Monitor model requirements are transformed in queries deployed on CEP engine.Then CEP engine filters the events and sends them in a format defined by event definitionsto the BAM engine. Here events are processed and stored in BAM engine database. Thenfrontend can pull the monitoring data from BAM-core and present them to the user.

Inputs:Compiled monitor model.

Outputs:Monitoring data presented by particular frontend.

Another output is BAM-core calls of the processes in BPEL engine. Those calls arefired when certain business situation occurs.

5.7.1.3 Post runtime

Here monitoring data can be processed, usually in long-time scope by knowledge discoverytools and other AI. This is not so frequently done nowadays and it will not be implementedin the prototype, but as was mentioned earlier it is one of the expected ways where businessintelligence will go in future. The results of this process should serve the self-optimizingprocesses.

Inputs:Monitoring data

Outputs:Gained knowledge and self optimizing data.

29

5.7. BAM REFERENCE ARCHITECTURE

5.7.2 Architecture overview

Architectural diagram on Figure 5.6 should clarify general architecture of BAM solution andexplain functions of each of them.

Figure 5.6: BAM architecture in layers

5.7.2.1 Modeling tool

Usually GUI based toolkit is used to define monitor model. The model contains definitionof events that should be caught, metrics, triggers and KPIs. Finished model is deployedand monitoring can start.

5.7.2.2 BAM core

This is the main component of BAM solution. It generates event patterns according to themonitor model and deploys them on CEP engine. It later processes the received event dataand transforms them in the desired form. BAM core can also communicate with the Process

30

5.8. PROTOTYPE DESIGN

engine, start and stop the processes, generate events etc. according to triggers and alarmsdefined in the monitor model.

5.7.2.3 CEP engine

This is the lowest level component responsible for event filtering. The CEP engine receivesquery patterns from the BAM core. It queries the event flow both from the Process engineand ESB and sends the wanted events back to BAM core. Usually only process engineevents are used for BAM, but CEP engine allows also filtering of ESB flow events. Thatcan be used in more technical oriented monitoring, or combined with the business data, tomonitor performance, resources usage etc.

5.7.2.4 Frontend

Frontend receives data already processed, with computed KPIs etc. and takes care of theirvisualization.

Every BAM solution should deliver graphical frontend witch rich visualization possibili-ties, such as charts, dashboards or graphs. An advanced OLAP-like visualization tool can bealso useful. One of the advanced features some frontends also provide is a real-time view ofprocesses, visualized on process graph. Here you can view process diagram as it was mod-eled and track the state of a particular process instance. It is also common that at least onefrontend should be web based. In this case frontend should provide a possibility to assem-ble your dashboards on fly. This is done usually by AJAX based scripts. AJAX becomes astandard for web-based BI tools today and it is also supported by Jasper Dashboards, one ofthe hot candidates for open source BAM frontend.

5.7.2.5 Long term data mining BI tools

An optional component that can analyze data from long-term perspective, realize data min-ing and knowledge discovery processes. Discovered information is delivered back to BAMcore. Mostly external tools are used for such cases nowadays but hopefully in future someof those tools will become a part of BAM solutions. That will allow the feedback obtainedby those tools to be sent back to the bam core or the process server.

5.8 Prototype design

5.8.1 Prototype goal

The aim of the prototype is to demonstrate proposed BAM architecture, with emphasis onevent-metric-KPI logic used for monitor models.

For this purpose the prototype provides a simple development UI for developing themonitor models based on event-metric-KPI logic, an event emitter that can simulate eventsource (for example BPEL engine) and a simple frontend that shows the monitoring data.

31

5.8. PROTOTYPE DESIGN

5.8.2 Platform

The prototype is written as a server-side application for Java 2 Enterprise Edition 5. It usesEJB 3 for BAM core logic and for persistence and JSF and servlets for web UI.

For testing is recommended an application server Glassfish V2 and some database, ide-ally both run in NetBeans 6.5 IDE.

5.8.3 Prototype use cases

Use cases are shown in the Use Case diagram on Figure 5.7.

Figure 5.7: Dasboard example

Define model

32

5.8. PROTOTYPE DESIGN

Here user can define the monitor model with the help of web-based UI . This isaccompanied by the following:

1. Define events defining inbound events and data that should be extracted andused for monitoring

2. Definemetrics definingmetrics that will be measured and a situation in whichthe value is changed with the help of trigger-event handler mechanism.

3. Define KPIs defining the KPIs over metrics

Emit eventsThe user can emit events defined in the text file.

Browse monitoring dataThe user can browse monitoring data collected form emitted events.

5.8.4 Prototype components

5.8.4.1 BAM core

The core engine is implemented as an EJB 3 application, using entity beans for persistenceand several session beans for the logic. Entities are shown in the Class Diagram on Figure 5.8.

5.8.4.2 Web frontend

Both Model Development UI and BAM frontend are standard JSF-based web applications,with standard Create-Edit-Update-Delete (CRUD) functionality.

5.8.4.3 Event emitter

Event emitter is implemented as Web-Service with simple servlet based frontend, whichallows uploading a file with events to be emitted.

5.8.5 Prototype usage

The user can run sample monitor model of Duck Delivery Enterprise which shows moni-toring of delivery orders. For this sample a set of testing events is provided.

The user can also define his own model, but then he has to create his own testing eventfiles and make sure that the monitor model is valid and all values are properly set. Web-UI for model development does not guarantee model validity, since this is quite a complexproblem.

33

5.8. PROTOTYPE DESIGN

Figure 5.8: Prototype Class Dagram

5.8.6 How to run the prototype

The prototype is standard EAR that has to be deployed to J2EE application server and run.The prototype needs a database with JNDI name bamse. It is recommended to fill thatdatabase with included testing data. I recommend to do the whole testing inside NetbeansIDE.

The instructions (Tutorial) for using the prototype can be found on the same CD as theprototype. The CD is part of this thesis.

34

Chapter 6

Conclusion

Here will discuss the current state of BAM on commercial and open source field. I will alsosum up my thesis and assess how successful I was at achieving the goals that I set.

6.1 State of the arts in BAM

Today BAM seems to be almost matured in some of proprietary BPMS platforms providedby big player such as IBM, Oracle, SAP and many others. Their solutions are often sufficientfor basic monitoring and sometimes provide some advanced features such as public inter-faces that allow interconnection with external tools. However, there is no de facto standardfor BAM, so solutions differ a lot. Also most of those solutions are really tied with vendor-specific BPMS platform and cannot be used outside of it.

In open source world where BPMS systems dont contain all components provided bycommercial platforms is the presence of BAM very limited. Nowadays there is still an ongo-ing effort to provide sufficient development tools such as visual editors and other tooling.BAM is a second class citizen in this case, because you cannot monitor processes which youare not able to develop due to the lack of development tools. I believe once open sourceBPMS platforms will be more matured, BAM will become a must and development will gofaster. Concerning event sources and event processing, open source world is well equipped,so the development of BAM solutions shouldnt be so hard.

6.2 Summary

I combined my experience with commercial BAM tools, conclusions made during testing ofvarious other solutions and valuable information from developers of SUNMicrosystems.

As was set, first this document is supposed to provide an elementary insight in SOAand BPMS to a reader not so familiar with the topic, as well as provide a review to moreexperienced readers. The document should also serve the people who are familiar just withvendor specific information about BPM, which is often more promotion than facts. Thisdocument gives the vendor-independent and more general view of the problem.

Second, this document introduces and clarifies BAM s, discusses basic principle and re-views the architectural context in which BAM solutions are used. It also provides genericguidelines in BAM solutions development and explains how to construct monitor models.

35

6.2. SUMMARY

I hope this document will be helpful to the developers designing and implementingBAM solutions especially on open source platforms. Like many other new technologies inthese days, BPMS and BAM solutions arematuring, thus they are also coming to open sourceworld.

Last but not least, also important is the prototype that shows the principle of Event-Metric-KPI logic, Provide simple interface to create a monitor models, and include simpleevent generator.

36

Bibliography

[1] Brandl, H. and Guschakowski, D.: Complex Event Processing in the con-text of Business Activity Monitoring, University of Applied Sciences Regens-burg, 2006/2007, .

[2] Arsanjani, A.: Service-oriented modeling and architecture, IBM, 9 November 2004, , . 2,2.1.1

[3] ESPER reference documentation, EsperTech Inc, .

[4] About JBI components, Sun Microsystems, Inc, , . 2.7.2.1

[5] About.com - about KPI, About.com, , . 5.2.3

[6] Raj, G. and P.G, B. and Babo, K. and Palkovic, R.: Implementing Service-OrientedArchitectures (SOA) with the JavaEE 5 SDK, Sun Microsystems, Inc, May 2006,, . 2.2.3, 2.7.2.1, 2.7.2.2

[7] SOAP Version 1.2 W3C Recommendation, World Wide Web Consortium, 27 April2007, , .2.5.1, 2.5.2

[8] SOAP protocol, Wikipedia, , . 2.5.1

[9] About UDDI 101, XML.org (OASISs site), , . 2.5.3

37