Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie

Size: px
Start display at page:

Download "Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie"


1 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 BIZNESOWYCH ZGODNIE Z PARADYGMATEM SOA PROMOTOR: dr inż. Dominik Radziszowski Kraków 2011


3 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 AND ANALYSIS SUPERVISOR: Dominik Radziszowski Ph.D. Eng. Krakow 2011

4 First and foremost, we wish to express our gratitude to our supervisor PhD. Eng. Dominik Radziszowski 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 contributions to our research on business process monitoring greatly helped to advance our work. Last but not least, we wish to thank our families and friends who continually supported and encouraged us in our work.

5 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 /08.

6 Contents 1. Introduction Motivation Thesis Objectives Document Structure Individual Contributions Problem Background SOA Solution Stack (S3) Business Process Monitoring BPEL Language Monitoring Solutions Evaluation BPEL Engines Enabling Monitoring for Business Process Engines Technology Overview OSGi and Spring Dynamic Modules Enterprise Service Bus and SerivceMix ESB Architecture ServiceMix OSGi Management and Monitoring OSGiMM Architecture OSGiMM Domain Event Processing Rule Processing with Drools Expert Complex Event Processing with Drools Fusion Eclipse Rich Client Platform Eclipse RCP Architecture System Architecture and Design Design Assumptions System Requirements

7 CONTENTS Functional Requirements Non-functional Requirements High Level Architecture Main System Elements Monitoring Process Communication Layer Extensions Monitoring Domain Extensions BPM Subscription Extensions Architecture of Rule-based Event Processing Remote Event Processing Rule Registry Monitoring Console Monitoring Console Core Elements Monitoring Console Extension Points BPEL Monitoring Console Component Rule-based Event Processing in Monitoring Console Implementation BPEL Monitoring Domain BPM Container BPM Component ApacheODE Engine Monitor BPM Rule Event Processor Events Hierarchy Topology Events Monitoring Events Subscription Implementation Topology Subscription Monitoring Subscription Subscription Topology Restrictions Monitoring Console Core Elements Monitoring Project Navigator Console Extensibility Implementation Realization of BPEL Monitoring Component Local Event Processing Rule-based Event Processing... 77

8 CONTENTS Business Rule and Rule Registry Implementation Event Processing Engine Implementation Drools Fusion Event Processing Engine Integration Testing OSGi Testing Framework Example Integration Test Case Business Process Monitoring Platform Modules System Evaluation Deployment Infrastructure Functional Verification Process Monitoring Validation Rule Processing Validation Additional Features Performance Verification Description of the Test Processes Test Cases Performance Tests Summary Evaluation Summary Conclusions Work Summary Thesis Contributions Further Research Glossary Acronyms Bibliography...116

9 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 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

10 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 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

11 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) Document Structure The first chapter comprises introduction and motivation of the presented work. In the Problem Background 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.

12 1.4. Individual Contributions 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

13 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) 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

14 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

15 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 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

16 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 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,

17 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] 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] 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.

18 2.4. Monitoring Solutions Evaluation 17 BPEL Process Manager by Oracle Type Process design Monitoring Documentation Licence Supported application servers Remarks Description Oracle BPEL Designer BPEL Console Java API Oracle API ias/bpel/index.html - extensive documentation with step-by-step tutorials proprietary, free for noncommercial use WebSphere, JBOSS, BEA WebLogic 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 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

19 2.4. Monitoring Solutions Evaluation 18 ActiveVOS by Active Endpoints Type Process design Monitoring Documentation Licence Supported application servers Remarks Description advanced graphical editor for business process management build-in monitor - processes, tasks and statistics, no API starthere/c_activevosdemonstration/ ActiveVOSDemonstration.html commercial, free 30-day trial JBoss, WebSphere, WebLogic, Tomcat 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 Process design Monitoring Documentation Licence Supported application servers Remarks Description Cardiff LiquidBPM Studio build-in LiquidBPM Manager, no API sdk/features/liquidbpm_components.html 30-day evaluation not required no available source code, license do not allow for decompilation and modification of the execution code Table 2.4. LiquidBPM by Cardiff

20 2.4. Monitoring Solutions Evaluation 19 BPELMaestro by Parasoft Type Process design Monitoring Documentation Licence Supported application servers Remarks Description Eclipse platform plug-in build-in monitoring, no API jsp?product=bpel proprietary not required 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 Process design Monitoring Documentation Licence Supported application servers Remarks Description Eclipse platform plug-in console API & logging, no documentation bpel.shtmlhttp://www1.creativescience.com/ Products/bpelEngine.shtml commercial not required no available source code, license do not allow for decompilation and modification of the execution code Table 2.6. bizzyme by Creative Science Systems

21 2.4. Monitoring Solutions Evaluation 20 Biztalk by Microsoft Type Process design Monitoring Description Windows Workflow Foundation - VS2008, Visio BizTalk Server Administration Console Microsoft Operations Manager (MOM) Event Viewer Business Activity Monitoring (BAM) aa aspx monitoring-biztalk-server.shtml Documentation Licence Supported application servers Remarks extensions: evaluation/adapter/default.mspx free 30-day trial version.net Platform 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 Monitoring monitoring console and API user-guide.html#userguide-managementapi Documentation open source Licence JEE compliant Supported application servers access to the source code, can be instrumented Remarks Table 2.8. ApacheODE

22 2.4. Monitoring Solutions Evaluation 21 jbpm by JBoss Type Process design Monitoring Documentation Licence Supported application servers Remarks Description Graphical Process Designer processes are launched by Process Virtual Machine, no dedicated monitoring solution, available monitoring API and source code open source (CPL/LGPL) JBoss 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 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.

23 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.

24 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.

25 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 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

26 3.2. Enterprise Service Bus and SerivceMix 25 allows for simple product reconfiguration and extension by declaratively exporting the new or modified services 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) 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.

27 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 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.

28 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.

29 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 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.

30 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 OSGiMM Architecture The OSGiMM architecture is shown in figure 3.4. Figure 3.4. OSGiMM Architecture

31 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 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 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.

32 3.4. Event Processing 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 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

33 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 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:

34 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 Eclipse RCP Architecture Figure 3.6. Eclipse RCP Architecture Eclipse RCP architecture (figure 3.6) consists of following the core elements: Equinox Equinox [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 platform The 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 Toolkit Standard 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

35 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. JFace JFace 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 Workbench Eclipse 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.

36 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 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

37 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 System Requirements In this section, the most important functional and non-functional requirements for the designed system are characterized 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.

38 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. Business process infrastructure discovery Business process visualization «include» Performance analysis of business process execution «include» IT Specialist Configuration of business process monitoring components Defined business process conditions tracking 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:

39 4.2. System Requirements 38 Business process discovery Business process visualization Business Analyst Defined business process conditions tracking «include» Business process variable tracking 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.

40 4.2. System Requirements 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 defined business 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

41 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 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.

42 4.3. High Level Architecture 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 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

43 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 ServiceMix implementation 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.

44 4.3. High Level Architecture 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.

45 4.4. Communication Layer Extensions 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) 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,

46 4.4. Communication Layer Extensions 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 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.

47 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.

48 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.

49 4.5. Architecture of Rule-based Event Processing 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 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).

50 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 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.

51 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.

52 4.6. Monitoring Console 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 Figure Monitoring Console components 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,

53 4.6. Monitoring Console 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 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.

54 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 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).

55 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 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 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 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 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.

56 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.

57 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 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

58 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. BPMContainer ITopologyElement +getchildren(): List<? extends ITopologyElement> +getpath(): List<String> +getname(): String BPMComponent EngineMonitor EventProcessor 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.

59 5.1. BPEL Monitoring Domain 58 List<String> bpeltopologystr = bbagent.retrievedomaintopology("bpel"); for (String bpelcontainerstr : bpeltopologystr) { BPMContainer newbpm = (BPMContainer) ApiJAXBBpel.getInstance(). unmarshallcontainer(bpmcontainerstr); } } 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 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 and section 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.

60 5.1. BPEL Monitoring Domain 59 BPMMonitoringAgent MsAgent +registerms(msinstance,msdefinition,mseventlistener) +unregisterms(msinstance) TopologyAgent +getagentdomain(): Set<String> +getdomaintopology(): String +registerms(msinstance,msdefinition,topologyeventlistener) +unregisterms(msinstance) MonitoringSubscriptionProcessor +registerms(msinstance,bpmmonitoringsubscription, MsEventListener) +unregisterms(msinstance) 1 1 ComponentTopologyTracker 1 TopologySubscriptionProcessor +registerts(msinstance,bpmcontainertopologysubscription, TopologyEventListener topologyeventlistener) +unregisterts(msinstance ) 1 BPMTopologyAgent Figure 5.2. BPM Container - Class Diagram 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 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:

61 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 Engine Monitor MsEventConverterProcessor ApacheOde EventListener InstanceEventSubscriber ApacheOdeEngineMonitor ManagementAPI WSQueryProcessor AbstractBPMAgent ProcessDeploymentTopologyListener Figure 5.3. ApacheODE Engine Monitor - Class Diagram 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:

62 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 AbstractTwoWayBPMAgent «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 BPMEventProcessor IRuleRegistry +addrule(businessrule:businessrule) +removerule(businessruledescription) +getrule(businessruledescription): BusinessRule +getrules(): Collection<BusinessRuleDescription> 1 «toplogyelement» RuleMonitoringDefinition +name: String +creator: String +description: String +ruleidlist: List<BusinessRuleDescription> +topology: TopologyDefinition BusinessRuleDescription +id: String +contenthash: String +version: String +ruletype: RuleType BusinessRule +content: String +businessruledescription: BusinessRuleDescription Figure 5.4. BPM Event Processor - Class Diagram

63 5.1. BPEL Monitoring Domain 62 :Monitoring Console rmd:rule Monitoring Definition :EventProcessor :IEventProcessingEngine :ESB Communication Layer registerrmd RuleMonitoringDeployedEvent rmd RuleMonitoringDeployedEvent 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 el subscribetotopology(el,rmd) processevent(me) MonitoringEvent RuleMatchedEvent RuleMatchedEvent RuleMatchedEvent Figure 5.6. Event processor - monitoring event processing - Sequence Diagram

64 5.2. Events Hierarchy 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) 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

65 5.2. Events Hierarchy 64 TopologyBPEL ComponentLifecycleEv RuleMonitoringDefinitionDisabledEv RuleMonitoringDefinitionEnalbedEv RuleMonitoringDefinitionDeployedEv RuleMonitoringDefinitionUndeployedEv ProcessDeployedEv ProcessUndeployedEv ComponentStartedEv ComponentStoppedEv Figure 5.7. Topology Events - Class Diagram 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

66 5.2. Events Hierarchy 65 Event type ActivityEv ActivityEnabledEv ActivityExecStartEv ActivityExecEndEv ActivityDisabledEv ActivityFailureEv CompensationHandlerRegisteredEv CorrelationSetEv ExpressionEvaluationEv ExpressionEvaluationSuccessEv ExpressionEvaluationFailedEv ScopeStartEv ScopeCompletionEv ScopeFaultEv VariableEv VariableModificationEv VariableReadEv RuleMatchedEv Description Abstract class for the activity events An activity is enabled An activity execution is started An activity execution is terminated An activity is disabled An activity failed A compensation handler is registered for a scope A correlation set value has been initialized An abstract class for the expression evaluation events Expression evaluation succeeded Expression evaluation failed A scope is started A scope is completed A fault has been produced in a scope An abstract class for the variable events Value of a variable has been modified Value of a variable has been read An event produced by BPM Rule Event Processor to inform that business rule was matched Table 5.3. Monitoring events description

67 5.2. Events Hierarchy 66 MonitoringEv ProcessInstanceEv ProcessInstanceStartedEv ProcessInstanceStateChangeEv ProcessMessageExchangeEv ProcessTerminationEv ProcessCompletionEv ScopeEv ScopeStartedEv ScopeCompletionEv VariableEv CorrelationSetEv VariableReadEv VariableModificationEv ScopeFaultEv CompensationHandlerEv ExpressionEvaluationEv PartnerLinkEv ExpressionEvaluationSuccessEv ExpressionEvaluationFailedEv ActivityEv ActivityDisabledEv ActivityFailureEv ActivityExecStartEv ActivityExecEndEv ActivityEnabledEv Figure 5.8. Monitoring Events - Class Diagram

68 5.3. Subscription Implementation Subscription Implementation As described in section subscriptions are divided into two categories: topology subscription and monitoring subscription. Their details are described in this work part 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 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 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.

69 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 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. ComponentRestriction ProcessRestriction GenericRestriction +patterns: List<Pattern> Pattern +pattern: String +property: String +positive: boolean +enabled: boolean ContainerRestriction RuleRestriction Figure 5.9. Topology restrictions - Class Diagram

70 5.4. Monitoring Console 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 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 The class structure of this console element is presented in figure The roles of the most important classes are then specified. Figure 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

71 5.4. Monitoring Console 70 :System :ConsoleSubscription :ConsoleCommunicator LocalMonitoringSubscriber :ESB Communication Layer Create Subscription Creating subscription and subscribing. new addsubscription subscribe registerms new lms1 registerlocalsubscriber(lms1) subscriptionstatechange(subscribed) setsubscriptionstate(subscribed) SUBSCRIBED Figure 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.

72 5.4. Monitoring Console 71 :System :ConsoleSubscription :ConsoleCommunicator LocalMonitoringSubscriber :ESB Communication Layer Reconnect Handling communication layer reconnection. setsubscriptionstate(unsubscribed) subscriptionstatechange(unsubscribed) DISCONNECTED update subscribe() new CONNECTED lms2 registerlocalsubscriber(lms2) unregisterlocalsubscriber(lms1) subscriptionstatechange(subscribed) setsubscriptionstate(subscribed) SUBSCRIBED Figure Console Subscription - handling reconnection - Class Diagram TopologyListener +ontopologyelementchange(te:itopologyelement) TopologyViewer RCP viewer that displays topology tree +display() osgi:import TopologyBuilderService +gettopology() +gettopology(topologyrestriction) +addtopologylistener(topologylistener) +removetopologylistener(listener) «osgi:service» TopologyBuilderServiceImpl Figure Topology Viewer and Topology Service - Class Diagram

73 5.4. Monitoring Console 72 Monitoring Workbench and Project Management The concept of business process monitoring specific project was described in section 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() «osgi:service» MonitoringWorkbench MonitoringStructureNode +createproject() +getchildren() MonitoringWorkbenchRoot ProjectTopologyElement BPMMonitoringProject +ts: TopologySubscription +topolgy: BPMTopology +subscribe() +isintopology() +markintopology() +markouttopology() BPMContainterElement +container: BPMContainer BPMComponentElement +component: BPMComonent +getbpmcomponenttype(): BPMComponentType ContreteComponentProjectNode Figure 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.

74 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 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 Console Extensibility Implementation This section describes the implementation details of the console extensibility introduced in section

75 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 Figure 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:

76 5.4. Monitoring Console 75 <extension point="pl.edu.agh.bpm.monitor.project.extension"> <projectextension extensionid="pl.edu.agh.bpm.monitor.rulemonitoring" extensionfactory= "pl.edu.agh.bpm.monitor.rulemonitoring.extension.rulemonitoringprojectextension" labelprovider="pl.edu.agh.bpm.monitor.rulemonitoring.extension.ruleextenstionlabelprovider"> </projectextension> </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 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.

77 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 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.

78 5.5. Rule-based Event Processing 77 public void loadxpaths() { GraphicalViewer graphviewer = this.fdesignviewer.getgraphicalviewer(); for (Object v : graphviewer.geteditpartregistry().keyset()) { if (v instanceof ExtensibleElement) { Element element = ((ExtensibleElementImpl) v).getelement(); String path = element.getattribute("xpath"); EditPart p = (EditPart) graphviewer.geteditpartregistry().get(v); registry.put(path, p); } } } public void updatecolor() { if (geteditorinput() instanceof InstanceEditorInput) { InstanceActivityNode node = ((InstanceEditorInput) geteditorinput()).getrootnode(); final InstanceState state = node.getmodel().getstate(); graphviewer.getcontrol().getdisplay().asyncexec(new Runnable() { public void run() { for (String xpath : registry.keyset()) { ActivityState acstate = state.getactivitystate(xpath); final EditPart editpart = registry.get(xpath); if (acstate.getexecutionstate() == ExecutionState.COMPLETED) { changepartcolor(editpart, COLOR_GREEN); } else { changepartcolor(editpart, COLOR_GRAY); } } } }); } } public void onstructurechange(structurenode node, StructureChange change) { if (node instanceof InstanceModel && change == StructureChange.UPDATE) { updatecolor(); } } 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 Business Rule and Rule Registry Implementation In this work part, Business Rule and distributed Business Rule repository - Rule Registry are described.

79 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 1 1 BusinessRule +ruledescription +type +content Figure Rule Registry - Class Diagram The Rule Registry class diagram is shown in figure 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

80 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 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 IEventProcessingEngineFactory +getnewinstance(): IEventProcessingEngine +getenginetype(): EngineType creates IEventProcessingEngine +addrule (rule:businessrule) +removerule(rule:businessrule) +processevent(event:monitoringevent) +addrulematcheventlistener(listener:eventlistener) +getenginetype(): EngineType DroolsEngineFactory FusionEventProcessingEngine Figure 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 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,

81 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. KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration(); config.setoption(eventprocessingoption.stream); knowledgebase = KnowledgeBaseFactory.newKnowledgeBase(config); session = knowledgebase.newstatefulknowledgesession(); session.addeventlistener(this); Listing 5.4. Drools Fusion configuration public void processevent(monitoringev event) { session.insert(event); session.fireallrules(); } 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,

82 5.5. Rule-based Event Processing 81 package rules; import pl.edu.agh.as3.sensors.backbone.api.ms.msdata.*; import pl.edu.agh.as3.sensors.backbone.api.bpm.cep.variablevalue; #declare any global variables here global pl.edu.agh.as3.sensors.bacrkbone.api.bpm.cep.variableextractor variable global pl.edu.agh.bpm.ruleprocessor.ruleresultmanager result declare event ( timestamp ) end rule "rule name" when #condition description then #actions taken end 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). rule "sample rule" when #condition description then result.setdescription(drools, "User comment"); result.setseverity(drools, 5 ); end 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).

83 5.6. Integration Testing 82 public void afteractivationfired(org.drools.event.rule.afteractivationfiredevent event) { Activation activation = event.getactivation(); Result result = resultmanager.getandremoveresult(activation); String id = getdroolsruleid(activation.getrule()); BusinessRuleDescription brd = droolsruletobusinessrulemap.get(id); RuleMatchedEv rulematchedev = creatematchedev(activation, brd, result); //notify on rule matched event listenersupport.onevent(rulematchedev); } 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. drools.multithreadevaluation = <true false> drools.maxthreads = <-1 1..n> 1 2 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 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

84 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 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

85 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) 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. import org.apache.servicemix.platform.testing.support.abstractintegrationtest; public class MonitoringAgentIntegrationTest extends AbstractIntegrationTest protected String[] gettestbundlesnames() { return new String[] { "apacheodeenginemonitor, 0.0.1", "BPMComponent, 0.0.1", "BPMContainter, 0.0.1" }; } public void testmonitoringsensorbundleshouldbestarted() throws Exception { checkbundlestarted("apacheodeenginemonitor"); } } Listing Example integration test

86 5.7. Business Process Monitoring Platform Modules 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 pl.edu.agh.bpm.droolsruleprocessor org.drools.eclipse.bpm Description event processing engine used by BPM Rule Event Processor that uses Drools Fusion Drools modules adjusted for Business Process Monitoring Platform Monitoring Console Core Modules Bundle pl.edu.agh.bpm.monitor.charts pl.edu.agh.bpm.common pl.edu.agh.bpm.monitor.common pl.edu.agh.bpm.monitor.model Description chart support for business process statistics common elements used across all bundles common product visual elements and Eclipse RCP helpers object model of the monitoring project and topology elements managed by Monitoring Console

87 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

88 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.

89 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 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 instances Virtualization Server 2 is Intel Core i5 processor with 8GB of RAM Ubuntu Server instances Virtualization Server 3 is Inel Core i5 processor with 4GB of RAM Ubuntu Server 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

90 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 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

91 6.2. Functional Verification 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 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

92 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

93 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

94 6.2. Functional Verification 93 Figure 6.9. Monitoring Console - monitoring project is created Figure Subscribing for the selected process Figure Monitoring Console is subscribed for a given process Figure Process instance execution

95 6.2. Functional Verification 94 Figure Executed process instances Figure Execution path of the monitored process

96 6.2. Functional Verification 95 Figure Monitoring events collected Figure Process activities summary

97 6.2. Functional Verification 96 Figure Activity execution charts 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).

98 6.2. Functional Verification 97 Figure New rule wizard Figure Business Rule wizard - name and description Figure Business Rule wizard - rule template selection

99 6.2. Functional Verification 98 Figure Business Rule wizard - target project selection Figure Drools rule editor Figure Deployment of the business rule to Rule Registry

100 6.2. Functional Verification 99 Figure Browsing Rule Registry Figure Creation of the Rule Monitoring Definition Figure Rule Monitoring Definition - basic configuration

101 6.2. Functional Verification 100 Figure Rule Monitoring Definition - business rule selection Figure Rule Monitoring Definition - target topology selection Figure Rule Monitoring Definition activation Figure Process instance execution Figure Events generated by BPM Rule Event Processor

102 6.2. Functional Verification 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 Console Summary View Figure Container Summary View

103 6.3. Performance Verification 102 Figure Engine Monitor Summary View Figure 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 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

Generic ESB Monitoring Architecture Compliant With JBI

Generic ESB Monitoring Architecture Compliant With JBI Generic ESB Monitoring Architecture Compliant With JBI Marek Psiuk Tomasz Bujok Supervisor: Prof. Krzysztof Zieliński Department of Electrical Engineering, Automatics, Computer Science and Electronics

More information

An architectural blueprint for autonomic computing.

An architectural blueprint for autonomic computing. Autonomic Computing White Paper An architectural blueprint for autonomic computing. June 2005 Third Edition Page 2 Contents 1. Introduction 3 Autonomic computing 4 Self-management attributes of system

More information

What s New in Oracle SOA Suite 12c O R A C L E W H I T E P A P E R J U L Y 2 0 1 4

What s New in Oracle SOA Suite 12c O R A C L E W H I T E P A P E R J U L Y 2 0 1 4 What s New in Oracle SOA Suite 12c O R A C L E W H I T E P A P E R J U L Y 2 0 1 4 Disclaimer The following is intended to outline our general product direction. It is intended for information purposes

More information

Architectural patterns

Architectural patterns Open Learning Universiteit Unit 3 Learning Unit 3 Architectural patterns Contents Introduction............................................... 35 3.1 Patterns..............................................

More information

State of art in the field of Adaptive Service Composition Monitoring and Management

State of art in the field of Adaptive Service Composition Monitoring and Management D5.1 Version: 0.7 Date: 2008-07-30 Author: UNITN Dissemination status: PU Document reference: D5.1 State of art in the field of Adaptive Service Composition Monitoring and Management Project acronym: COMPAS

More information

PRACA MAGISTERSKA. Metamodel and Workflow Management System for Object - Oriented Business Processes

PRACA MAGISTERSKA. Metamodel and Workflow Management System for Object - Oriented Business Processes PRACA MAGISTERSKA Metamodel and Workflow Management System for Object - Oriented Business Processes Metamodel i system zarzadzania przepływem pracy dla procesów biznesowych zorientowanych obiektowo Student

More information

Convergence of Social, Mobile and Cloud: 7 Steps to Ensure Success

Convergence of Social, Mobile and Cloud: 7 Steps to Ensure Success Convergence of Social, Mobile and Cloud: 7 Steps to Ensure Success June, 2013 Contents Executive Overview...4 Business Innovation & Transformation...5 Roadmap for Social, Mobile and Cloud Solutions...7

More information

Simplifying the Development of Autonomic Enterprise Java Bean Applications via Model Driven Development

Simplifying the Development of Autonomic Enterprise Java Bean Applications via Model Driven Development Simplifying the Development of Autonomic Enterprise Java Bean Applications via Model Driven Development Jules White, Douglas Schmidt, Aniruddha Gokhale {jules, schmidt, gokhale}@dre.vanderbilt.edu Department

More information

Guide to Secure Web Services

Guide to Secure Web Services Special Publication 800-95 (Draft) Guide to Secure Web Services Recommendations of the National Institute of Standards and Technology Anoop Singhal Theodore Winograd Karen Scarfone NIST Special Publication

More information

SIMPL A Framework for Accessing External Data in Simulation Workflows

SIMPL A Framework for Accessing External Data in Simulation Workflows Peter Reimann b Michael Reiter a Holger Schwarz b Dimka Karastoyanova a Frank Leymann a SIMPL A Framework for Accessing External Data in Simulation Workflows Stuttgart, March 20 a Institute of Architecture

More information

A Template for Documenting Software and Firmware Architectures

A Template for Documenting Software and Firmware Architectures A Template for Documenting Software and Firmware Architectures Version 1.3, 15-Mar-00 Michael A. Ogush, Derek Coleman, Dorothea Beringer Hewlett-Packard Product Generation Solutions mike_ogush@hp.com derek_coleman@hp.com

More information

Application Performance Management with Oracle Enterprise Manager 11g

Application Performance Management with Oracle Enterprise Manager 11g An Oracle White Paper April 2010 Application Performance Management with Oracle Enterprise Manager 11g Introduction... 1 Top Challenges of Application Performance Management... 2 Oracle s Application Performance

More information

Cloud Service Level Agreement Standardisation Guidelines

Cloud Service Level Agreement Standardisation Guidelines Cloud Service Level Agreement Standardisation Guidelines Brussels 24/06/2014 1 Table of Contents Preamble... 4 1. Principles for the development of Service Level Agreement Standards for Cloud Computing...

More information

Power System Control Centers: Past, Present, and Future

Power System Control Centers: Past, Present, and Future Power System Control Centers: Past, Present, and Future FELIX F. WU, FELLOW, IEEE, KHOSROW MOSLEHI, MEMBER, IEEE, AND ANJAN BOSE, FELLOW, IEEE Invited Paper In this paper, we review the functions and architectures

More information

Problem Management. Contents. Introduction

Problem Management. Contents. Introduction Problem Management Contents Introduction Overview Goal of Problem Management Components of Problem Management Challenges to Effective Problem Management Difference between Problem and Incident Management

More information


PROJECT FINAL REPORT PROJECT FINAL REPORT Grant Agreement number: 212117 Project acronym: FUTUREFARM Project title: FUTUREFARM-Integration of Farm Management Information Systems to support real-time management decisions and

More information


NEER ENGI ENHANCING FORMAL MODEL- LING TOOL SUPPORT WITH INCREASED AUTOMATION. Electrical and Computer Engineering Technical Report ECE-TR-4 NEER ENGI ENHANCING FORMAL MODEL- LING TOOL SUPPORT WITH INCREASED AUTOMATION Electrical and Computer Engineering Technical Report ECE-TR-4 DATA SHEET Title: Enhancing Formal Modelling Tool Support with

More information

JCR or RDBMS why, when, how?

JCR or RDBMS why, when, how? JCR or RDBMS why, when, how? Bertil Chapuis 12/31/2008 Creative Commons Attribution 2.5 Switzerland License This paper compares java content repositories (JCR) and relational database management systems

More information

Monitoring and Diagnosing Applications with ARM 4.0

Monitoring and Diagnosing Applications with ARM 4.0 Monitoring and Diagnosing Applications with 4.0 Mark W. Johnson IBM Corporation The (Application Response Measurement) standard provides a way to manage business transactions. By embedding simple calls

More information

By Nicholas R. Jennings and Stefan Bussmann

By Nicholas R. Jennings and Stefan Bussmann odern control systems must meet increasingly demanding requirements stemming from the need to cope with significant degrees of uncertainty, as well as with By Nicholas R. Jennings and Stefan Bussmann Mmore

More information

Business Intelligence Software Customers Understanding, Expectations and Needs

Business Intelligence Software Customers Understanding, Expectations and Needs Business Intelligence Software 1 Running head: BUSINESS INTELLIGENCE SOFTWARE Business Intelligence Software Customers Understanding, Expectations and Needs Adis Sabanovic Thesis for the Master s degree

More information

MDA Journal A BPT COLUMN. David S. Frankel. January 2004. Until February. David Frankel

MDA Journal A BPT COLUMN. David S. Frankel. January 2004. Until February. David Frankel MDA Journal MDA Journal January 2004 Over the past year, Microsoft has given indications that it takes model-driven approaches to software seriously. Statements emanated from the top of the company about

More information

4everedit Team-Based Process Documentation Management *

4everedit Team-Based Process Documentation Management * 4everedit Team-Based Process Documentation Management * Michael Meisinger Institut für Informatik Technische Universität München Boltzmannstr. 3 D-85748 Garching meisinge@in.tum.de Andreas Rausch Fachbereich

More information

A Rational Software Corporation White Paper

A Rational Software Corporation White Paper Rational Unified Process Best Practices for Software Development Teams A Rational Software Corporation White Paper Rational Unified Process Best Practices for Software Development Teams WHAT IS THE RATIONAL

More information

Visualization of Scheduling in Real-Time Embedded Systems

Visualization of Scheduling in Real-Time Embedded Systems Institute of Software Technology Department of Programming Languages and Compilers University of Stuttgart Universitätsstraße 38 D 70569 Stuttgart Master Thesis Nr. 3372 Visualization of Scheduling in

More information

Enterprise Application Integration based on Service Oriented Architecture

Enterprise Application Integration based on Service Oriented Architecture Enterprise Application Integration based on Service Oriented Architecture Zaigham Mahmood Abstract Enterprises have invested heavily in large-scale applications software to run their services and business

More information

The current issue and full text archive of this journal is available at www.emeraldinsight.com/1463-7154.htm

The current issue and full text archive of this journal is available at www.emeraldinsight.com/1463-7154.htm The current issue and full text archive of this journal is available at wwwemeraldinsightcom/1463-7154htm BPMJ 15,5 744 management (BPM) : a survey Ryan KL Ko Advanced Design and Modelling Laboratory,

More information

A Monitoring-based Approach to Object-Oriented Real-Time Computing

A Monitoring-based Approach to Object-Oriented Real-Time Computing A Monitoring-based Approach to Object-Oriented Real-Time Computing Dissertation zur Erlangung des akademischen Grades Doktoringenieur (Dr.-Ing.) angenommen durch die Fakultät für Informatik der Otto-von-Guericke-Universität

More information

Intelligent Value Chain Networks: Business Intelligence and Other ICT Tools and Technologies in Supply/Demand Chains

Intelligent Value Chain Networks: Business Intelligence and Other ICT Tools and Technologies in Supply/Demand Chains 28 Intelligent Value Chain Networks: Business Intelligence and Other ICT Tools and Technologies in Supply/Demand Chains Evelin Vatovec Krmac University of Ljubljana, Faculty of Maritime Studies and Transport

More information

Design and Evaluation of a Wide-Area Event Notification Service

Design and Evaluation of a Wide-Area Event Notification Service Design and Evaluation of a Wide-Area Event Notification Service ANTONIO CARZANIGA University of Colorado at Boulder DAVID S. ROSENBLUM University of California, Irvine and ALEXANDER L. WOLF University

More information