Systems
Andrzej Stroi ´nski
A dissertation submitted to the Council of the Faculty of Computing
in partial fulfillment of the requirements for the degree of Doctor of Philosophy
Supervisor: Prof. Jerzy Brzezi ´nski, Ph. D. Dr. Habil.
Poznan, Poland 2018
I wish to thank my promotor prof. dr hab. Jerzy Brzei´nski for great support during my work under this thesis. Thanks to his guidence and help this thesis received its final look and quality.
This work was supported by the Polish National Science Center under Grant No. DEC-2012/05/N/ST6/03051 and the Poznan University of Technology.
Contents
Acknowledgements ii
1 Introduction 1
1.1 Discovery of process models . . . . 1
1.2 Goal and scope of the thesis . . . . 8
2 Basic definitions and problem statement 10 2.1 Communicating resource system — CRS . . . . 10
2.1.1 CRS system model . . . . 10
2.1.2 Business process and application process in CRS . . . . 15
2.1.3 Process log, process trace and events . . . . 16
2.1.4 Resource log in CRS systems . . . . 18
2.2 Modelling of processes using Petri nets . . . . 23
2.2.1 Place and Transition net, Workflow net and workflow net properties . . . . 23
2.2.2 Petri nets for modelling CRS . . . . 32
2.3 Problem statement . . . . 42
3 Alpha and Alpha Plus Algorithms 45 3.1 Alpha Algorithm . . . . 45
3.1.1 Pseudo code of Alpha algorithm . . . . 47
CONTENTS
3.1.2 Analysis of the Alpha algorithm . . . . 48
3.2 Alpha Plus algorithm . . . . 49
3.2.1 Discovering length-two loops . . . . 49
3.2.2 Length-one loops and Alpha Plus algorithm . . . . 52
3.2.3 Correctness and analysis of Alpha Plus algorithm . . . . 54
4 Gathering event logs in CRS systems 56 4.1 Problems in gathering meaningful event logs in CRS . . . . 56
4.1.1 Resource independence and event correlation . . . . 57
4.1.2 Log interleaving problem . . . . 59
4.2 Context logging in CRS . . . . 60
4.3 Non-invasive context logging for JSR-311 with AspectJ: a case study 63 4.4 The algorithm for a reconstruction of CRS global process log set of business process . . . . 68
5 Discovery of process models in CRS 75 5.1 System model . . . . 76
5.2 CRS event log . . . . 77
5.3 Ordering relations and log completeness . . . . 78
5.4 CRS miner algorithm . . . . 85
5.4.1 The idea of CRS miner . . . . 86
5.4.2 STEP I: Assuring global activity uniqueness . . . . 88
5.4.3 STEP II: Construction of ordering relation . . . . 89
5.4.4 STEP III: CRS process model discovery . . . . 92
5.4.5 Results of the CRS miner . . . . 92
5.5 The hCRS miner — discovery of resource local process and resource communication . . . . 95
5.5.1 The idea of discovery of resource local process and resource communication . . . . 96
5.5.2 STEP I: decomposition of CRS global process log set into resource local process logs . . . . 99 5.5.3 STEP II: discovery of resource local processes of the CRS . 100
5.5.4 STEP III: discovery of business process . . . 105
5.5.5 hCRS miner — example . . . 107
5.5.6 hCRS miner — correctness proof and final remarks . . . 110
5.6 Distributed hCRS miner with resource hierarchy . . . 114
5.6.1 Idea of dhCRS miner algorithm . . . 114
5.6.2 STEP I: Log partitioning . . . 115
5.6.3 STEP II: Distributing the discovery of resource local pro- cess models over computational nodes . . . 115
5.6.4 SUB-STEP in STEP II: Mining the local process . . . 116
5.6.5 STEP III: Generating the global process model . . . 117
5.6.6 STEP IV: Mining resource hierarchy . . . 117
5.6.7 Result and final remarks . . . 117
5.7 Coloured dhCRS miner — discovery of aggregated coloured Petri net model . . . 120
5.7.1 STEP III*: mining global process . . . 120
5.8 Discovery of models of business processes with one length and two length loops . . . 124
5.8.1 Discovery of models of business process of length one loops 124 5.8.2 Discovery of business process models with length two loops 125 6 Comparison and evaluation of CRS process model discovery al- gorithms 127 6.1 Characteristic of process model discovery algorithms . . . 127
6.1.1 Characteristics of CRS miner algorithms . . . 127
6.1.2 Assumptions of CRS miner algorithms . . . 128
6.2 Computation complexity evaluation . . . 129
6.3 Experimental performance evaluation . . . 130
6.3.1 Test 1: Comparing CRS miner, hCRS miner and dhCRS miner algorithms . . . 132
6.3.2 Test 2: Local activities in a nested process . . . 134
6.3.3 Test 3: Number of resources . . . 137
6.3.4 Test 4: Impact of the number of processing nodes on pro- cessing time . . . 139 6.3.5 Test 5: Nested vs. orchestrated process models . . . 141 6.3.6 General comments . . . 143
7 Conclusions 145
Bibliography 148
Index 159
List of Figures
2.1 An example of Communicating Resource System . . . . 14
2.2 Example of a business process . . . . 16
2.3 An example of event log . . . . 17
2.4 An example of business process in CRS described using communi- cation net with resource hierarchy. . . . 21
2.5 Example of a PTnet. . . . 24
2.6 An example of an implicit place (px). . . . 28
2.7 Typical process patterns . . . . 29
2.8 Example of communication net with two concurrent invocations. . 36
2.9 Example of communication net with drawn instances . . . . 37
2.10 CRS business process modelled with coloured Petri net . . . . 44
3.1 W F net discovered by AA for AP L1= {ha, b, c, di12, ha, c, b, di10, ha, e, di2} 48 3.2 The model discovered by the Alpha algorithm for activity process log AP LM2 = {ha, b, c, d, c, e, f i12, ha, b, x, e, f i10} . . . . 51
3.3 The model discovered by Alpha Plus algorithm for activity process log AP LM2 = {ha, b, c, d, c, e, f i12, ha, b, x, e, f i10} . . . . 52
3.4 The resulting model discovered by the Alpha Plus algorithm based on log AP L3 = {ha, x, ei, ha, c, c, ei, ha, c, c, c, c, c, c, ei} . . . . 54
4.1 Event correlation during multiple global process execution . . . . . 57
LIST OF FIGURES
4.2 Event correlation during single global process execution . . . . 58 4.3 Example of activity correlation problem . . . . 59 4.4 Problem of log interleaving . . . . 60 4.5 Discovery of a global process based on local logging and local pro-
cesses discovery . . . . 61 4.6 Context logging example . . . . 62 4.7 Idea of context (aspect) logging framework. . . . 68 4.8 CRS example of multiple concurrent global processes with drawn
local process instances. . . . 70 5.1 An example of parallel execution of local and communication ac-
tivities . . . . 77 5.2 An example of the real business process model in CRS and possible
local process trace logs. . . . . 87 5.3 Process model discovered by the CRS miner . . . . 88 5.4 The idea of hCRS miner algorithm . . . . 98 5.5 An example of the result of step III of the hCRS miner algorithm. 104 5.6 Model of business process executed in CRS discovered by hCRS
miner. . . 107 5.7 Model of business process executed in CRS discovered by CRS
miner. . . . 108 5.8 Model of business process discovered by dhCRS miner. . . 118 5.9 An example of coloured communication net discovered by the cd-
hCRS miner . . . 126 6.1 An example of a nested business process model used in Test 1, Test
2 and Test 5. . . 132 6.2 An example of a orchestrated business process model used Test 5. . 133 6.3 Test 1: Discovery of business process with variable number of re-
sources 1..5 . . . 134 6.4 Test 2: Discovery of business process with 10 resources and variable
number of local activities 5..18. . . 136
6.5 An example of a nested business process model used in Test 3 and Test 4. . . 137 6.6 Test 3: Discovery of business process with variable number of re-
sources 1..10 with number of local activities fixed to 14. . . 139 6.7 Test 4: Discovery of business process with variable number of pro-
cessing nodes 1..9. . . . 140 6.8 Test 5: Discovery of complex nested and orchestrated business
process model by dhCRS miner . . . 142 6.9 Test 5: Discovery of simple nested and orchestrated business pro-
cess model by dhCRS miner . . . 143
List of Tables
5.1 The initial state of the activity ordering table in step II of CRS miner. . . . 89 5.2 The activity ordering table in step II of the CRS miner after ap-
plying local and remote log-based ordering relation in CRS. . . . . 90 5.3 The activity ordering table at the end of step II of the CRS miner. 92 6.1 Test 1: Discovery of business process with variable number of re-
sources 1..5 . . . 134 6.2 Test 2: dhCRS miner results for discovery of business process with
10 resources and variable number of local activities 5..18. . . . 136 6.3 Test 2: hCRS miner results for discovery of business process with
10 resources and variable number of local activities 5..18. . . . 136 6.4 Test 3: dhCRS miner results for discovery of business process with
variable number of resources 1..10 with number of local activities fixed to 14. . . 139 6.5 Test 3: hCRS miner results for discovery of business process with
variable number of resources 1..10 with number of local activities fixed to 14. . . 139 6.6 Test 4: dhCRS miner results for discovery of business process with
variable number of processing nodes. . . 141
LIST OF TABLES
6.7 Test 5: dhCRS miner results for discovery of simple/complex nested and orchestrated business process model. . . 143
1
Introduction
1.1 Discovery of process models
Nowadays distributed computer systems become ubiquitous and affect almost ev- ery aspect of modern life. To make such systems easier to develop, cheaper to maintain and less error prone the Service Oriented Architecture (SOA) has been proposed [Erl05]. SOA is a distributed system architecture style where the func- tionality of the system is scattered over independent, loosely-coupled components, called services. A service provides a small fraction of the system’s functionality, that can be remotely invoked by a system client or by other system services.
To provide a complex functionality in SOA systems, services are composed into business processes. For example, a complex function like booking a holiday trip can be achieved by executing two services: flight booking and hotel booking, in an appropriate order. There are two general approaches to compose business processes: orchestration and choreography.
In orchestration there is a central coordinator service, called orchestrator, that invokes other services [BCB+06] according to a predefined plan (program) ex- pressed using a number of sequential, parallel or alternative workflow constructs.
In choreography, however, there is no central coordinator, but workflow control is distributed, and each system service needs to communicate with other services to know when it has to join the business process execution [BDO05].
Currently, two approaches are used to implementing SOA systems: procedural SOAP Web Services (SOAP-WS) and declarative RESTful Web Services (REST- WS). In the SOAP-WS approach, communication between services takes as foun- dations a specialized XML-based protocol, called SOAP (Simple Object Access Protocol) [STK02]. Interoperability is ensured by encapsulating the transmitted data into SOAP envelopes created according to the description of the service in WSDL (Web Services Description Language) documents [Wal02, WSD]. To make services described by WSDL documents discoverable by other services or devel- opers, the UDDI (Universal Description, Discovery, and Integration) registry has been proposed [UDD]. The task of this registry is to store and share the descrip- tion of the service functionalities in WSDL[Wal02]. Business processes are usu- ally implemented in the BPEL language (Business Process Execution Language) [JEA+07, BCB+06] and interpreted by a runtime environment called BPEL en- gine [aOD]. Additionally, to ensure desired system properties concerning QoS (Quality of Service), security and manageability, a huge stack of so-called WS-
* standards has been proposed by W3C (World Wide Web Consortium, [w3c]) and OASIS (Advancing Open Standards for the Information Society, [oas]). Un- fortunately, the number and complexity of WS-* standards make development of SOAP-WS based systems very difficult and error prone, in addition to introducing significant performance overhead.
Due to flaws of SOAP-WS, another approach to implement SOA systems, called RESTful Web Services, is increasingly gaining attention of both practi- tioners and academic community. This approach is based on REST (Represen- tational State Transfer) architectural style proposed by Roy T. Fielding [TF00], which defines the required properties that a distributed system should meet to be lightweight and efficient. Systems fulfilling these requirements are called REST- ful. [RR07]
In practice, the most common implementation of SOA with REST princi- ples is based on ROA (Resource Oriented Architecture) which uses the existing Web infrastructure and the HTTP protocol [RR07]. ROA assumes that the func- tionality of a distributed system is scattered over a collection of communicating
resources that are software components combining data structures, program code or pieces of hardware. No matter what the resource provides, it always executes some process when it is invoked. A complex functionality can be obtained by composing resources. Moreover, in ROA the CRUD (Create, Retrieve, Update, Delete) operations are mapped onto HTTP methods, i.e. GET, POST, PUT, and DELETE, etc., and the unique addressing and hierarchy of resources are supported by the URI (Uniform Resource Identifier) standard.
A generalization of RESTful systems is the Communicating Resource Sys- tem (CRS) [SDB16], which comprises a set of independent and hierarchically composed resources that communicate to realize a business process. Here, the business process is a chain of resource invocations so it performs a complex func- tionality as a composition of data and functionalities provided by resources. Same as in the SOAP-WS approach, also for CRS there are specialized programming languages and technologies that allow us to define and execute business processes.
The most prominent solutions available up to date are BPEL4REST [Pau08], ROsWeL [BDF+12], JOpera [jOp], and Jolie [jol].
It should be noted that CRSs may consist of hundreds or even thousands of cooperating resources. Each resource can perform simple local operations (local process) or orchestrate other resources by invoking them, using, e.g. the HTTP protocol to execute a business process. CRSs are implemented with a long lifespan and rolling updates in mind. Therefore, they are created in a modular and incre- mental way, usually by a number of different and independent enterprise entities.
The long and distributed development may lead to incorrect component usage and overall system failures, like e.g. resource invocation loops, bottlenecks, resource leaks, livelocks, deadlocks, and violation of CRS (REST, ROA) principles, which adversely affect CRS [DSB15a, SDB14a, BHRS95, BBG87, BBG92, BKKL12].
These problems can lead, in the best case scenario, to a reduction of system QoS, and in the worst case to complete malfunction of the processes. Therefore, for effective management and maintenance of a CRS it is crucial to detect occur- rences of such problems and solve them as fast as possible. In order to address this issue, it is possible to use methods of model checking [CGP99, Cyr12] or con-
formance checking [DSB15b, vdA11, ADO+08]. Here, based on the real model of a process one can analyse the possible process behaviour. Unfortunately, in prac- tice the real model usually is not available and even if it is available it often does not reflect the actual process behaviour. It is mainly because during the process implementation and lifetime, components of the system involved in the process are modified but their models are not maintained up-to-date. Therefore, very often to effectively analyse, manage, improve or enhance CRS processes, models of the processes should be discovered (reconstructed) first, based on historical information gathered and stored in the system activity log.
The problem of process model discovery has been intensively investigated for the last two decades, as an element of the so called process mining, and a lot of work has been done already [AGL98, CW98a, CW98b, Her00, MWVdAvdB02].
Four basic approaches to process model discovery have been introduced in [vdA11]:
direct algorithmic modelling, two-phase algorithmic modelling, computational in- telligence modelling, and partial (incomplete) modelling.
In direct algorithmic modelling, ordering relations of process activities are extracted from system activity logs and used to construct a process model. The basic algorithm in this class is the Alpha algorithm [vdAWM04], which generates a specific Petri net (i.e. sound and structured workflow net [DR98] ) representation of the process. It is one of the first process discovery algorithms that could appropriately deal with concurrency, and many of its concepts have been applied in more sophisticated methods. The basic idea of this algorithm is to browse a log of the process activities in search of specific patterns, e.g. sequential, alternative or parallel patterns. Next, the discovered patterns are composed and used to construct a complete process model. However, the problem is that the Alpha algorithm is unable to discover short loops (loops of length one and two). This problem is solved by the Alpha plus algorithm presented in [dMvdAW03], that detects short loops in an activity log, removes from the log loops of length one, and identifies activities belonging to loops of length two. Then, the Alpha algorithm is executed for the modified log, and loops of length one are added to the discovered model.
Another extension of the Alpha algorithm was presented in [WAWS07], where the authors introduced two types of causal dependencies between process ac- tivities: explicit and implicit. Consequently, the algorithm can partially cope with the so-called ”non-free” choice constructs (e.g. situations where there is a mixture of branching and synchronization). One more algorithm presented in [WWvdA+10a] extends the Alpha algorithm capabilities in dealing with invisible tasks.
Other direct algorithmic modelling methods include algorithms that use ”language- based regions” to generate the process model [BDLM07]. General concept of these methods is to treat logs as a finite language, and then, using region-based syn- thesis methods, to construct a minimal Petri net including the language. In [CC10, vdvDHS09] the authors propose algorithms based on ”language-based re- gions” which generate Petri net places by converting the log into a system of in-equations. In this case, the system consisting of in-equations can be seen as the footprint of the process and be used to construct the final Petri net.
The second approach involves two-phase modelling algorithms. Such algo- rithms refine initially discovered low-level process models based on the activity log (e.g. transition system, hidden Markov model) into a high-level model (e.g.
Petri nets) [Alp14, CKLY98, VdARV+10]. These algorithms enable users to con- trol the balance between ”underfitting” (the model is too general) and ”overfitting”
(the model is too specialized to catch all logs) of the process model.
Computational intelligence approach for model discovery includes, but is not limited to, genetic programming, machine learning, fuzzy sets and ant colony optimization. An example, is a genetic process mining algorithm to discover Petri net given a log of activities [dMWvdA07]. This algorithm attempts to mimic the evolution of a process. The action starts with the initial model of the process and then the model is evolved by the crossover technique (combining parts of two or more individuals) and mutation (random modification of an individual) until a result of acceptable quality is reached.
The partial modelling approach consists of methods that produce an incom- plete end-to-end process model. Examples of such methods are the discovery of
frequent episodes [MTV97] or mining of sequential patterns [SA96].
Different approaches and techniques to process model discovery have been applied, among others, to distributed SOA systems.
In [RGvdA+06] the authors use log-based analysis and process discovery tech- niques on web services’ logs to discover ”actionable Web service modelling intelli- gence” [RGvdA+06]. However, only the problem of the Web service log gathering in SOAP-based Web services is solved.
In [KLK+09], the authors present an approach to collecting logs in order to extract process activities from SOAP-based applications, and integrating portal log files. The papers [Bea06] and [MNSPea11] present methods for correlating activities with processes and process instances. These methods consider the global perspective of business process only, as well as interactions between services, without taking into account local activities.
Another interesting concept is presented in [Bea11]. It concerns the so- called cross-organization process model discovery. Here, the authors deal with a large number of process variants executed in different organizations, as such a case is quite typical in the Software-as-a-Service (SaaS) and Cloud Computing paradigms. The authors propose to cross-correlate and compare process mod- els and the observed behaviour in different organizations. Methods presented in this work have been successfully applied to real-life event logs in different Dutch municipalities [Bea11].
An application of data mining and process model discovery techniques in order to discover and analyse interactions between a web service consumer and provider has been discussed in [Dea04]. Here, three levels of analysis are presented: work- flow of large-scale interactions and collaborations of Web services which together form a business process, interaction of Web services and their direct neighbours, and operation of Web services in isolation. For each level, the approach to log gathering is presented, and the minimal set of information that must be available in the log is defined. This work is based on the assumption of implementing SOA systems with the SOAP-WS and therefore, it strongly relies on WS-* standards and SOAP-WS communication types (one-way notifications, etc.).
An extension of the aforementioned work was described in [DG07], where the authors define Web service logging levels that correspond to the possibility of discovering meaningful information about processes. Next, they show solution to discover the process model in a SOA system using existing methods implemented in the PROM framework [PMG17]. In this work, like in the previous one by the same authors, the method is strongly dependent on properties of SOAP-WS and therefore it is not applicable directly to CRSs. Moreover, in this solution the resulting model only concerns the business process. In consequence, it is not possible to discover local processes of resources involved in the execution of the business process and the discovered model is very complex and hard to comprehend.
The paper [vdAV08] deals with process model discovery with the usage of the PROM framework in the case of event logs acquired from the IBM WebSphere product. Here, some basic process discovery methods are applied, and the prepro- cessing data step is strongly based on the IBM WebSphere features. Therefore, this approach is not general enough to be used for other systems.
An important aspect of research in the field concerns discovery of process hierarchy. In [BVvdA12] and [GGP05], the authors show a concept to simplify a huge process model by substituting parts of the model by one component, but they do not consider communication and resource hierarchy.
There is also research that considers the decomposing of a process model dis- covery problems into smaller problems [VDA12]. Here, the concept of passage is used in order to pinpoint substructures of a process model that can be discovered and analysed in separation from each other. This approach is designed for huge processes without specialized constructs like communication, or complex systems which need to be modelled by higher level process models.
Let us note that the aforementioned approaches to process model discovery are not perfectly suited to CRSs. Therefore, new methods should be proposed to take into account specific features of CRSs, including resource separation, synchronous communication and resource hierarchy.
1.2 Goal and scope of the thesis
The dissertation tackles development and evaluation of new concepts for discovery of Petri net models of distributed processes in Communicating Resource Systems.
To meet this general goal the following problems should be solved:
• Gathering in logs all the data necessary to discover process models. It is non-trivial because CRSs are asynchronous and distributed systems com- posed of hundreds or even thousands of resources. Each system component gathers log independently, so in general, global ordering of process activities occurring in different resources is not possible.
• Appropriate extensions of Alpha and Alpha plus algorithms for discovering Petri net models of distributed processes in CRS.
• Discovery of a resource perspective of processes in CRSs, concerning re- source composition, resource communication, and resource hierarchy.
• Performance analysis of the proposed solutions in this thesis.
The dissertation is structured as follows. In Chapter 2 we present foundations of CRS, Petri nets, coloured Petri nets, and logs. We also formally state the problem of discovery of Petri net model of distributed processes. Chapter 3 presents Alpha and Alpha plus algorithms that are the basis for development of new concepts proposed in the following sections. Chapter 4 describes data that must be gathered by CRSs, the idea of a CRS event log gathering framework, and a process-related data reconstruction algorithm for enriching CRS event logs with process instance identifiers. In Chapter 5 we propose a CRS miner, a new process model discovery algorithm that is able to discover a sound and structured workflow net model of a business process from the CRS system event log. It is based on the Alpha algorithm introduced in [vdAWM04], but it can also be combined with the Alpha plus algorithm [dMvdAW03]. Section 5.5 describes an extension of the CRS miner, called hCRS miner, which is able to discover CRS-specific process constructs related to resource communication and resource
composition. Further extension of the CRS miner, called the dhCRS miner, is presented in Section 5.6.1. This algorithm is a distributed version of the hCRS miner, which additionally discovers the CRS system resource hierarchy. The dhCRS miner discovers a partial process model of each resource on independent computing nodes, and later combines the partial results to obtain a business process model. In Chapter 6 performance evaluation of the proposed algorithms is presented. Finally, in Chapter 7, conclusions are presented and further research directions are discussed.
2
Basic definitions and problem statement
In this chapter, in Section 2.1 we formally introduce a class of distributed systems called Communicating Resource Systems (CRSs) as well as the notions of business process, global and local process, event, event log, process traces and process log. Then, in Section 2.2, we present the foundations of Petri nets and define specialized Petri nets called communication nets, which are well suited to model processes executed in CRS. Finally, in Section 2.3 we state precisely the problem of discovery of Petri net models of distributed processes in CRS.
2.1 Communicating resource system — CRS
2.1.1 CRS system model
Similarly to ROA based systems [RR07], Communicating Resource Systems (CRSs) consist of resources that combine simple data elements (e.g. integer), complex data structures (e.g. tables, records), pieces of hardware (e.g. I/O device con- trollers), or units of computation (program codes). No matter what a resource provides, it always executes some local process when it is invoked. Resources are passive, in the sense that they perform activities only on demand.
Formal definition of a resource is as follows:
Definition 1 (Resource). Resource is a tuple res = hrid, S, Ent, Com, Loc, W F i, where:
rid — is a resource identifier,
S — is a set of values representing a state of the resource, Ent — is a set of all entry point activities that can be
invoked on the resource,
Com — is a set of all communication activities (e.g. send, receive) that can be performed by the resource (Ent ⊂ Com),
Loc — is a set of all activities that can be performed by the resource during its execution excluding communication activities (Com ∩ Loc = ∅), W F — is a possible resource behaviour described in some formalism,
e.g. Petri net.
Examples of activities that are performed by the resource during the execu- tion of a process are: receiving a message from another resource (Ent), sending a message to an other resource (Com), retrieving some information from data storage (Loc), or performing some calculations like adding numbers (Loc).
Resources can communicate with other resources only by exchanging (sending and receiving) request and response messages. In CRS we assume the synchronous communication model, meaning that, after sending a request, a resource is waiting for response, as in the synchronous HTTP protocol. A formal definition of a CRS, loosely inspired by [KN11], is the following.
Definition 2 (Communication Resource System, CRS). Communication Re- source System is a tuple
CRS = hR, I, Act, α, η, θ, Ci, where:
R — is a set of resources,
I — is a set of resource identifiers rid,
Act — is a set of all activities that resources can execute (S
r∈RLocr∪S
r∈RComr),
α — α ⊆ (R × Act), is a relation defining activities a ∈ Act that can be performed by a resource r ∈ R,
η — is a surjective function η : R → I that assigns identifiers from I to resources from R. We denote η(r) = rid for (r, rid) ∈ η and r ∈ R, rid∈ I, θ — is a surjective function θ : OP S → RET S that assigns return codes
rc ∈ RET S that are sent with responses to request activities o ∈ OP S, where OP S =S
r∈RComr and RET S is a set of possible return codes, C — is a strict partial order binary relation (irreflexive, anti-symmetric,
transitive) over R, C⊆ (R × R), called resource hierarchy.
Based on resource hierarchy, we will define the following notions related to CRS: sub-resource (Definition 3), direct sub-resource (Definition 4), top resource (Definition 5), and unique belonging (Definition 7).
Definition 3 (Sub-resource, super-resource). Whenever (ri, rj) ∈C for some ri, rj ∈ R, we say that ri is a sub-resource of rj, and we write ri C rj. We say also that the rj is a super-resource for ri.
Definition 4 (Direct sub-resource, direct super-resource). If ri C rj and 6 ∃rk ∈ R: ri C rkC rj, then we call ri a direct sub-resource of rj or we call rj a direct super-resource of ri, and write ri C1rj.
Direct sub-resource ri of rj is a specific sub-resource of rj such there are no resources between ri, and rj in the resource hierarchy. Similarity direct super- resource rj of ri is a specific super-resource of ri such there are no resource between rj, and ri in the resource hierarchy.
Definition 5 (Top resource). A resource rt∈ R is a top resource, in C if ∀r ∈ R : (rt, r) /∈C. A set of all top resources is denoted as T , T ⊆ R.
Top resources are starting points for resource hierarchies in CRS. Their iden- tifiers must be unique in the system (Definition 6).
Definition 6 (Top resource naming uniqueness). ∀ri, rj ∈ T , such that ri 6= rj, η(ri) 6= η(rj).
Definition 7 (Unique belonging property). Unique belonging property states that
∀ri, rj, rk∈ R, if ri C rj and ri C rk and rj, rk ∈ T , then rj = rk.
The unique belonging property states that each resource in a CRS can be a sub-resource of only one top resource in the system.
Definition 8 (Direct sub-resource naming uniqueness). ∀ri, rj, rk ∈ R, if ri C1
rk and rj C1 rk and ri 6= rj, then η(ri) 6= η(rj).
Direct sub-resource naming uniqueness states that in the set of all direct sub- resources of a given resource, each sub-resource has a unique name.
Definition 9 (Resource addressing). Let us define a path function (address) of a resource ri:
path(ri) =
η(ri) if ri ∈ T
path(rj) · ”/” · η(ri) if ri C1 rj
where · is a string concatenation.
Resource addressing is a function that assigns e.g. unique URI address to each resource in the system, based on its place in the resource hierarchy. For example, let us consider the following addressing paths: path(ri) = www.eg.com/
employees/john doe/, and path(rj) = www.eg.com/employees/. Here, the re- source ri that represents the employee of www.eg.com company named john doe is a sub-resource of resource rj representing all company employees.
Definition 10 (Communication in CRS). Communication in CRS is a tuple hpath(rs), path(rd), o, rci, denoted path(rs)−−→ path(ro,rc d), where:
Figure 2.1: An example of Communicating Resource System
path(rs) — is the address of a requesting resource rs (sending a request message and receiving a response message), called source resource (rs∈ R),
path(rd) — is the address of a requested resource rd (receiving a request message and sending a response message), called destination resource (rd∈ R),
o ∈ OP S — is a request activity of a resource rs invoking a resource rd,
rc ∈ RET S — is a return code to the activity o, sent by rd to rs
An example of communication in a CRS could be /client/−−−−−−−−→ /resourceX/,GET ,200OK where client invokes resource resourceX using operation GET, and receives the return code 200 OK.
Now, let us discuss the introduced definitions concerning CRS and its compo- nents in the example shown in Figure 2.1. The system resources perform activities which can be communication activities (e.g. sending a request) or local (internal) activities (e.g. saving a datum, reading a variable or deleting a database object).
Moreover, some distinguished resources are top resources (e.g. r1, r3, r4 in Fig- ure 2.1), and some of them have sub-resources, e.g. r2 is a sub-resource of r1, and r7 is a sub-resource r6. Note that r2 is also a direct sub-resource of r1. As has been required, a resource is either a top resource or a sub-resource of only one top resource. In addition, all top resources, as well as resources having the
same direct super-resource, are uniquely named.
In CRS, resources are addressed by addressing paths. In practice, the URI standard can be used for that. In the example, the path for resource r7 would be r5/r6/r7 (Definition 10). The arcs in Figure 2.1 show the direction of com- munication that occurs between resources.
2.1.2 Business process and application process in CRS
Definition 11 (System client). A system client (or client in short) is an exter- nal component that is not a part of the CRS but plays a role of an initiator of processing in CRS.
Definition 12 (Application process). An application process P is a set of all pos- sible process executions where each execution is a sequence of activities ha1, a2, . . . ani that system performs from a start activity to an end activity of process. A simple process execution will be called process instance or case.
Definition 13 (Business Process). Business process is an application process initiated by client to achieve client’s goals.
The difference between a business process and an application process is that a business process is always requested by a system client and a response from the system is sent back to that client. The application process, on the other hand, can be requested by a system client directly or by other system resource. As a result, a requester (client or system resource) gets a response.
Definition 14 (Local application process). A local application process (or simply a local process) is an application process performed by a single system resource.
Definition 15 (Global application process). A global application process (or sim- ply a global process) is an application process performed by two or more system resources.
Let us consider the example presented in Figure 2.2. Here, the system client is invoking resourceA/. The first dotted arc from the system client to the activity a of resourceA/ denotes the invocation of a business process by the client. The
business process in this example consists of all activities that begin with the client system request (BP start ) to the system and ends with the response to that request (BP end ). Note that a system resource may not be aware of the business process is it involved in. In the example, resourceB/ is not aware that it is invoked by (in the context of) the business process started by the system client.
system client
start
a
f
b
end c
d
start
a
t
b
end resourceB/
BP start
BP end
resourceA/
Figure 2.2: Example of a business process
2.1.3 Process log, process trace and events
Execution of processes in distributed systems is usually monitored, and system state characteristics (attributes) like time, process identifier, instance identifier, and required resources related to individual activities, are stored in system logs.
This information can be further used to analyse the process behaviour. We for- malize basic notions related to logs following [vdAWM04] and [vdA11].
Definition 16 (Event, attribute). An event e of an activity occurrence is a tuple of attribute values characterizing this occurrence. Let E be the event universe, i.e. the set of all possible events, and let AT be a set of all attributes. For any event e ∈ E and attribute at ∈ AT , #at(e) will denote the value of the attribute
at for event e. If an event e does not include an attribute at, then we assume that #at(e) =⊥ (null value).
Definition 17 (Event log). An event log is a set of events related to system activities in some time period. An event log represents a shared history of system behaviour.
An event log can be stored in different forms, but usually it is a table where each event is represented by a single row. Values of all attributes for each event can be found in columns associated with the attribute names.
instanceid eventid activity time resourceid
1 1 start 54 A
1 2 requestsend 55 A
1 3 responserecieve 58 A
1 4 process value 78 A
1 5 verify the
value 100 A
1 6 end 101 A
2 7 start 32 A
2 8 process value 56 A
2 9 verify the
value 89 A
2 10 end 90 A
processid 1 1 1 1 1 1 1 1 1 1
5 11 start 54 A
5 12 requestsend 55 A
5 13 responserecieve 58 A
5 14 process value 78 A
5 15 verify the
value 100 A
5 16 end 101 A
6 17 start 32 B
6 18 process value 56 B
6 19 verify the
value 89 B
6 20 end 90 B
2 2 2 2 2 2 2 2 2 2
Figure 2.3: An example of event log
An example of event log is presented in Figure 2.3. The set of event attributes comprises: processid, instanceid, eventid, activityid, time, resourceid. In order to simplify references to events we will write e1 to indicate the event with value 1 of its eventid. For event e1 we have: #processid(e1) = 1, #instanceid(e1) = 1,
#eventid(e1) = 1, #activityid(e1) = start, #time(e1) = 54, #resourceid(e1) = A.
Definition 18 (Event sequence). An event sequence σ is a set of events ordered according to the time of occurrences of the event activities.
An example of event sequence of event log in Figure 2.3 is: σ = he1, e2, e3, e4, e5, e6i.
Definition 19 (Process trace). A process trace τ of a process P r is an event sequence, that is a part of event log related to a single process execution (one instance of a process).
Let us note that, neglecting some attributes (e.g. time), multiple instances of a process P r can produce the same process traces.
Definition 20 (Process log). Let τ1, τ2, . . . τnbe a set of process traces of a process P r and n be some natural number. A process log of P r, denoted P L(P r), is a multi-set of traces of the process, P L(P r) = {τ1k1, τ2k2, . . . τnm}, where the script ki denote how many times the trace τi occurs in the process log P L(P r).
Sometimes not all attributes of events in process log are required to analyse a process, and a process log can be simplified replacing every event in the process log with an event comprising only the set of required attributes. If events of process P r comprise only the activity attribute value, the process trace and process log are called activity process trace and activity process log, respectively.
The set of activity process log of process P r will be denoted by AP L(P r).
Process log combining traces that include all event sequences possible to occur during process execution, is called a complete process log complete process log.
2.1.4 Resource log in CRS systems
In order to analyse the behaviour of CRSs where multiple resources can cooperate and communicate while executing complex global processes, events should include appropriate information related to processes.
In CRS we distinguish two types of events: resource local events (rle) and resource communication events (rce) .
Definition 21 (Resource local event, rle). A resource local event rle ∈ E is an event associated with a local activity of a resource, containing values of at least
four mandatory attributes: eid, rid, aid, lpid, where:
eid — is an event identifier, locally unique for a resource,
rid — is a resource identifier, globally unique for the whole CRS, aid — is an activity identifier associated with a local activity,
lpid — is a locally unique process instance identifier for a local process of a resource.
Consequently, for an event rle we will denote values of attributes eid, rid, aid, and lpid, by #eid(rle), #rid(rle), #aid(rle) and #lpid(rle), respectively. An event rle is stored in a log associated with a resource.
The information represented by an event corresponds to local process activity in a resource indicated by value of attribute rid. The value of attribute eid is locally unique at the resource, i.e. different resources can use the same event identifiers. Note that because rid is unique for the whole system, the concate- nation of rid and eid allows us to generate an event id which is globally unique in the whole system. Attribute lpid identifies the local process instance of the resource. Note that there is no local process identifier in rle. It is because as a local process, we understand a process executed by a resource rid, and therefore rid can be used as a local process identifier. Examples of rle for resourceI and activities a and d in Figure 2.4 could be as follows: he1, resourceI, a, AHF i and he4, resourceI, d, AHF i, where AHF is a local process instance identifier.
Definition 22 (Resource communication event, rce). A resource communication event rce ∈ E is an event associated with a communication activity of a resource, containing values of the following mandatory attributes:
eid — is an event identifier, locally unique for a resource,
rid — is a resource identifier, globally unique for the whole CRS, aid — is an activity identifier associated with a
communication activity,
lpid — is a locally unique process instance identifier of a local process,
inv lpid — is an identifier of the local process instance that sent the message received by resource rid as a result of the activity aid occurrence source — is the address of a resource sending a message,
dest — is the address of a resource receiving a message,
convid — is a conversation id that identifies two events involved in single synchronous communication.
An event log entry rce in addition to attributes present in rle, stores infor- mation about the source and the dest (destination) of the communication. Let, for example, values of attributes of event rcei be as follows: #source(rcei) = www.ex.com/resA and #dest(rcei) = www.ex.com/resB. It means that the re- source www.ex.com/resA sent a request or response message to the resource www.ex.com/resB. Note that such information is usually logged by application servers like Apache Tomcat [Apa15], Ruby on Rails, and similar ones.
Additional information stored within rce is lpid and inv lpid. Note that lpid is an identifier of a local process instance of a resource rid, and inv lpid is an identifier of the local process instance that sent the message received by activity aid(if activity aidis an activity of receiving a message). As a result it is possible to analyse the resource logs to identify global process instances, which are chains of local process instances linked by communication activities. The attribute convid stores the identifier of synchronous communication that allows us to correlate sending a request to remote resource and receiving a response to that request. If two events are correlated then values of this attribute in both events should be equal.
Now let us consider the example presented in Figure 2.4. Here, we focus on two communication events (e, e0) related to activities b and c executed at resourceI. We assume the following values for these two events:
• e = he1, resourceI, b, CF 0, null, resourceI, resourceJ, 1i, and
• e0 = he2, resourceI, c, CF 0, GHA, resourceJ, resourceI, 1i.
The values correspond to the attributes of resource communication event pre- sented in the Definition 22. Note, that the value CF 0 is a local process instance identifier at resourceI and GHA is a local process instance identifier at resourceJ that is returned in response to invocation of resourceJ by resourceI. The value 1 in last attribute (conv id) pinpoints that activity b and c are involved in the same communication (b is an activity of sending invocation message, and c is an activity of receiving response to that message).
resource K resource K/L
ak start
ek dk bk fk
gk
hk ik
end
resource J
end a
b
c
d comm
resKLa
comm resKLd
resource I start
end a
b
c
d comm
resJa
comm resJd start
Figure 2.4: An example of business process in CRS described using com- munication net with resource hierarchy.
Now, let us discuss the definitions of an event log, process traces and process logs suited to the CRS. First, three definitions (23, 24, 25) concern CRS from the local perspective of a single resource in CRS. Next, we introduce the definitions from the entire system perspective that includes all activities performed by CRS resources in multiple global processes (see Definition 26, 27, 28). Finally, we propose the definition of the event log, trace and process log from the perspective of a single business (global) process that is executed in CRS (see Definition 29,
