Model-based verification of event-driven business processes (PDF ...

Model-based Verification of Event-driven Business Processes Christian Reinartz

Andreas Metzger

Klaus Pohl

Paluno (The Ruhr Institute for Software Technology) University of Duisburg-Essen 45127 Essen, Germany

Paluno (The Ruhr Institute for Software Technology) University of Duisburg-Essen 45127 Essen, Germany

Paluno (The Ruhr Institute for Software Technology) University of Duisburg-Essen 45127 Essen, Germany

[email protected] [email protected] [email protected] due.de due.de

ABSTRACT Event-driven business processes employ event-processing capabilities to analyze internal and external event streams for complex situations that may impact on process execution. An open issue is the verification of such event-driven business processes in order to detect, among others, deadlocks. Individual verification approaches for business processes and event processing networks exist. However, even if the business processes and the event processing networks individually are deadlock-free, deadlocks may arise due to the integration of event processing networks and business processes into event-driven business processes. This paper introduces a verification technique for event-driven business processes. The main aspects of the technique are (1) to formalize business process models and event processing networks as an integrated petri-net, and (2) to perform reachability analyses of the integrated petri-nets to reveal deadlocks. We provide a proofof-concept realization utilizing petri-net simulators, demonstrate the applicability of the verification technique, and sketch future extensions of the technique.

Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques – Petri nets; D.2.4 [Software Engineering]: Software/Program Verification – Correctness proofs, Validation

General Terms Documentation, Reliability, Languages, Verification

Keywords Verification, BPMN, Event Processing, Petri-nets, Deadlocks

1. INTRODUCTION Event-driven business process management combines the automated execution of business processes (BPM) and the detection of complex events from continuous event streams (CEP). Eventdriven business process management is a suitable paradigm for real-time business activity monitoring, event-driven process control and event-driven predictive analytics [1], [2]. With the inPermission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. DEBS '15, June 29 - July 3, 2015, Oslo, Norway Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-3286-6/15/06...$15.00. http://dx.doi.org/10.1145/2675743.2771826

creasing volume, velocity and veracity of data sources, such as provided by the Internet of Things [3] and cloud computing [4], leveraging event-processing capabilities as part of IT-supported business process control receives increasing relevance [5] [6]. The concept of event-driven business processes has been explored in various industrial application domains. Important examples for such domains include agri-food [7], as well as transport and logistics [8]. To illustrate, logistics transport and processes are complex and affected by many external factors. The complexity stems from collaboration among cargo carrying airlines, freight forwarders, airport logistics companies, ground handlers, ground transport companies and regulatory agencies (customs, security, etc.). External events include traffic situations, weather conditions, and fluctuating cargo volumes [9]. Responding to events in such complex processes as promptly as possible is essential for maintaining efficient supply chains [10]. An open issue is the quality assurance and in particular the verification of event-driven business processes. Verification is required in order to detect, among others, undesired deadlocks. While individual verification techniques for business processes and event processing networks exist, verification techniques for eventdriven business processes are not yet available. Yet, as we will demonstrate in this paper, even if the business process and the event processing networks individually are deadlock-free, deadlocks may arise in event-driven business processes due the integration of control flow (defined in the business process) and event flow (defined in event processing networks). To address this gap, we introduce a verification technique for event-driven business processes. The main aspects of our verification technique are  

to formalize business process models and event processing networks (including the underlying messaging middleware) as an integrated petri-net; to perform reachability analysis of the integrated petrinet to reveal deadlocks.

We describe a proof-of-concept realization that uses capabilities of existing petri-net simulators. We show the applicability of the verification technique by demonstrating its ability to detect deadlocks and discussing its scalability with respect to performance. A critical discussion of the technique indicates potential extensions and future research directions. The paper is structured as follows. Section 2 introduces a running example showing why an integrated verification of business process models and CEP is necessary to uncover deadlocks. Section 3 introduces our verification approach, including the formalization

as integrated petri-nets and the reachability analysis of these petrinets. Section 4 describes the proof-of-concept realization, discusses its pros and cons and sketches future directions. Related work is discussed in Section 5.

sole perspective of the business process, no deadlocks will occur. The EPNs of our example are shown in Figure 2, following a visualization introduced by Etzion and Niblett [14]. The example includes three EPNs, one for each event processing task of the business process:

2. RUNNING EXAMPLE To describe our running example and the formalization that follows in Section 3, we employ the main concepts of a concrete approach for integrating business processes and complex event processing. The approach we use has been presented by Appel et al. [11], [12], [13] and introduces Stream Processing Units (SPUs) and Eventlets to specify event-driven business processes. An SPU is a modeling extension for the business process modeling notation (BPMN) that defines a special type of process task: an eventstream processing task. Each SPU encapsulates an event processing network (EPN). The EPN of an SPU is implemented within a corresponding Eventlet that includes the actual event processing rules and patterns.



EPN A: This EPN simply aggregates two incoming events of type e to an outgoing event of type a. EPN B: This EPN composes a new event of type x from two incoming events of type a and type b, respectively. EPN C: This EPN translates events of type a to events of type b.

 

Considering the three EPNs individually, they are deadlock free. Even when combining the three EPNs into one integrated event processing network, no deadlocks are observed. EPN A Event e

Event Producer

To foster understandability, we purposefully selected a rather abstract running example. We will introduce the business process and event processing parts of the example separately and then move on to explain how the integration will lead to deadlocks not visible when looking at BPM and CEP individually.

+ Event Stream Processing Task B

Event Consumer

Event a

Event Producer

Compose EPA

+

Event a

EPN B

Event Stream Processing Task A Task 1

Aggregation EPA

Event Producer

Event x

Event Consumer

Event b

Event Stream Processing Task C

EPN C

Figure 1. Business Process

Event a

Event Producer

The business process of the example is shown in Figure 1. Process execution starts with the execution of Task 1 (a regular BPMN task). When it finishes, the control flow is forked to the two stream processing tasks A and B. Task B runs until its encapsulated EPN generates a new, outgoing complex event. After completion of Task B, process execution continues to stream processing Task C, which also completes on complex event generation. As soon as the event processing Task A is completed, the parallel control flows join and the business process terminates. From the

Translate EPA

When we consider the combination of the business process and the EPNs into an event-driven business process, a deadlock will arise. A deadlock in event-driven business processes happens when an event stream processing task needs unavailable resources (e.g. events) which are produced by another event stream processing task that is waiting for execution.

Event e Event Stream Processing Task A Aggregation EPA

+

Event Consumer

Figure 2. Event Processing Networks

External Event Producer

Task 1

Event b

Event a Event Stream Processing Task B

Event Stream Processing Task C

Compose EPA

Translate EPA

+

Event b Event x External Event Consumer

Business Process control flow Event Processing data flow

Figure 3. Integrated Event-driven Business Process

However, the execution depends on the waiting event stream processing task. Figure 3 visualizes this integration in a pseudonotation to better explain the deadlock. After the fork in the business process, EPN A will create a complex event of type a, once it receives external events e. The created event a is then consumed by the two even processing tasks B and C. The EPN of task B includes a compose agent. Thus, the outgoing event x will only be created if event b is received in addition to event a. Events of type b are only produced by the EPN of event processing task C. However, due to the control flow defined in the business process, EPN C will only be activated after EPN B has completed, which can only happen if EPN B has received both events a and b. Thus, we enter a deadlock situation. This example demonstrates that even if the business process (control flow) and the event-processing networks (event flow) have not faced a deadlock, integrating the two may lead to deadlocks due to interactions between event and control flow.

3. VERIFICATION APPROACH This section describes the two main steps of our verification approach (see Figure 4): (1) The formalization of business process models and evenprocessing elements as an integrated petri-net (see Section 3.1); (2) The reachability analysis of the integrated petri-net to determine deadlocks in event-driven business processes (see Section 3.2).

grated petri-net model. In particular, arcs between the business process layer and the EPN layer represent control flows between business process objects and event processing elements, while arcs between the EPN layer and the messaging layer represent event flows. In the following subsections, we describe – in a bottom-up order – the mappings for each of the three layers, as well as the connections between the layers.

3.1.1 Messaging Formalization Typically, message-oriented middleware is used for exchanging events between event producers and event consumers (e.g., see [15]). Common messaging models include point-to-point (where events from an event producer are processed by a single consumer), and pub/sub (where events are sent to a specific topic and may be processed by multiple consumers subscribing to this topic). Figure 5 shows how to map those two messaging models to petrinet concepts. Each event stream x is represented as a petri-net place. Event producers, such as EPNs or external event sources, are modeled as petri-net transitions and are connected to the event stream place via incoming edges. The broadcasting of events to subscribed event producers (in the case of pub/sub) is modeled using an outgoing petri-net transition connected to places that represent the outgoing events. Note this unsymmetrical formalization of the pub/sub model that ensures that more than one event producer may publish events, and that each event is broadcast to all its subscribers. Messaging

Petri-net Mapping t producer 1

Process model

Point to Point (2) Reachability analysis Petri-net

P event x

Detected deadlocks

Event Processing Networks

t producer 1

Publish/Subscribe

To formalize event-driven business processes, the relevant concepts for event-driven business processes (EPNs, EPAs and the messaging middleware) are mapped to petri-net concepts, such as places and transitions. In this section, we describe that mapping. The resulting integrated petri-net is structured into the following three main modeling layers (as shown for our running example in Figure 6):

 

Business process layer: This layer maps the standard concepts of business process models, BPMN in our case, to places and transitions. In particular we map the concept of SPUs (as introduced in Section 2) to petrinets. Event Processing Network layer: This layer maps all EPNs (and their EPAs) referenced by an SPU in the business process layer to petri-net concepts. Messaging layer: Core messaging models (such as pub/sub or point-to-point) are formalized on this layer, thereby representing event distribution.

Arcs that cross the boundaries of adjoining layers represent the connection of elements across the layers and thus form the inte-

P event x

P event x

Figure 4. Overview of verification approach

3.1 Formalization as Integrated Petri-Net

t transmit event x

...

(1) Mapping



P event x

t producer n

t broadcast event x P event x

Figure 5. Formalization of Message-oriented-middleware The formalization leads to the following semantics. The number of tokens in each event stream place represents the number of available events for a given event stream at run-time. A firing of any incoming transition will produce an additional token in the event stream place. Whenever the broadcast transition fires, an event is sent to all subscribed consumers, reducing the number of tokens in the event stream place by one.

3.1.2 EPN Formalization EPNs typically contain several EPAs. EPAs offer functions such as filter, pattern detect and transformation [14]. A filter selects those events from an event stream that match a filter condition. Pattern detect can apply complex logical functions to incoming events in order to recognize patterns in event streams. A transformation maps incoming events into new events (e.g., of different event types). Transformations include aggregation, split, or composition. To demonstrate the mapping of EPNs to the integrated petri-net model, we focus on the latter kind of EPAs: transformation EPAs.

Business Process

Event Processing Network

Messaging Figure 6. Example of integrated petri-net The mappings for the specific kinds of transformation EPAs are depicted in Figure 7 and described below: 







A translation EPA transforms a single incoming event (of type x) to new a single output event (of type y). A translation EPN is formalized by a petri-net transition with one incoming place that represents the consumed event stream x and one outgoing place that represents the produced event stream y. An aggregation EPA aggregates several events from one event stream to a new complex event. It is formalized by a petri-net transition with one incoming place that models the event stream for event type x and one outgoing place that models the event stream for event type y. The number n on the incoming arc specifies the number of incoming events that must be available at the place x to transform these events to a new complex event. A split EPA transforms events from one event stream to new events for two outgoing event streams. Their information may be cloned from the incoming event or may include subsets of the attributes of the incoming event. A split EPA is formalized by a petri-net transition with one incoming place that models the event stream for event type x and two outgoing places that model the event streams for event types y1 and y2. A compose EPA transforms events from two incoming event streams to new events for one event stream. The new event is a combination of the two incoming events. It is formalized by a petri-net transition with two incoming places that model the event streams for event types x1 and x2. One outgoing place models the event stream for event type y.

The incoming and outgoing places of an EPA represent potential connections to other EPAs in an EPN. For example an EPN may consist of two EPAs A and B. EPA A produces an event x that is

consumed by EPA B. The outgoing place of EPA A is at the same time the incoming place for EPA B. This formalization allows the composition of EPAs into more complex EPNs. EPA Function

Petri-net Mapping

Translate EPA P event x

P event y n

Aggregation EPA P event x

P event y

P event y1

Split EPA P event x

P event y2

P event x1

Compose EPA P event y

P event x2

Figure 7. Formalization of EPA and EPN

3.1.3 Integrating Messaging and EPN Formalization Event-driven systems have the advantage that participants are only loosely coupled. The event-processing elements only need to know that there is an event producer and an event consumer. To formalize this loose coupling, an outgoing transition for an event stream modeled on the Messaging layer is connected by an arc to the incoming place that models the input of an EPA on the EPN layer. As an example, Figure 6 shows how the event stream

a is connected to the EPN C as an input event. It also shows how the output of EPN C is connected to the event stream b.

3.1.4 Business Process Formalization Formalizing process models as petri-nets is a common step in verifying business process models (see Section 5). As a basis for our formalization, we use the mappings proposed by Djikman et al. [16], which map core BPMN concepts to simple petri-nets. Figure 8 shows an excerpt of the typical BPMN concepts and their mappings (for the complete mappings please refer to [16]). In order to extend this formalization with event-driven business process concepts, we introduce the formalization of SPUs, which we briefly introduced in Section 2. Generally speaking, an SPU is a special type of BPMN task. It includes the connection to EPNs as well as explicit or implicit completion conditions. As a result, we explicitly model the starting and termination of an SPU as petri-net transitions. The start transition is triggered by the incoming control flow of the business process, while the termination transition may either be triggered by an internal message within the business process (explicit completion), or when the EPN that is encapsulated by the SPU terminates (implicit completion). Figure 6 shows both cases, where SPU A is explicitly completed and SPUs B and C are implicitly completed. BPMN Object

Petri-net Mapping Px

t SPU start

P SPU active

t SPU end

Py

Event Stream Processing Task

transition fires. Depending on the kind of completion, the firing of the transition is either triggered by a token within the process (explicit completion) or by a token from an SPU (implicit completion).

3.1.5 Integrating EPN and Business Process Formalization Basically, SPUs encapsulate the logic of the EPNs on the BPMN layer and define when EPNs should be activated or deactivated. To manage the activation, an EPN is connected to the SPU’s internal place “SPU active”. All EPAs in the EPN that consume events must be connected to the “SPU active” place. Without this connection, the entire EPN would be active even if the corresponding task in the business process was not running. To ensure that each EPA instance is working for the entire SPU’s life time, a second arc is connected back to the “SPU active” place. Irrespective of the number of connected and running EPAs, the token is always available until the “SPU end” transition fires. The “SPU end” transition fires when the “termination” place is triggered. If the termination is triggered by an implicit completion, the EPN must be connected to the termination place. Figure 6 depicts the activation and termination concept. In our example, EPN C is connected to “SPU active” and vice versa. EPN C is also connected to the “Termination SPU C” place for internal completion.

3.2 Reachability Analysis To detect deadlocks, we apply reachability analyses for petri nets (e.g., see [17]) to the integrated petri-net model of the eventdriven business process.

t EPA

P termination

t Task T

Py

Task Px

In simple terms, a petri-net is considered free from deadlocks when it never gets stuck. This can be expressed in temporal logic, such as CTL (computation tree logic), as follows: AG EX true

Start P Start

t Start

Py

Px

t End

P End

End P y1

Fork Px

t Fork P y2

P x1

This means that for all paths through the petri net, at least one next place may be reached for each of the places along the path. For this expression to be true, however, a petri-net must never terminate, as otherwise this termination would be detected as deadlock (as no next state will be reachable from the end state). In case an event-driven business processes has a defined end (such as in our running example), deadlock analysis thus needs to be performed differently. Reachability analysis has to determine that every path of the petri-net will in fact terminate in the place representing the end of the process. If one path does not reach an end place, a deadlock may occur during execution. This can be expressed in CTL as follows: AG EF end_place

Join t Join

Py

P x2 P Message

To ensure the correct identification of deadlocks from the reachability analysis, the petri-net must be correctly initialized with tokens as follows: 

Message  Px

t Message

Py

Figure 8. Formalization of BPMN and SPUs This formalization leads to the following semantics. When the starting transition fires, the tokens are placed in the SPU’s internal place “SPU active”. The SPU remains active until the termination

One token must be placed on the business process start place to ensure that the execution of the business process may commence. All places on the messaging layer that are connected to external event sources must have enough initial tokens such as to avoid starvation due to lack of external events. In our example, we require at least two events of type e such that the compose transition of EPA A can fire.

4. PROOF OF CONCEPT This section describes a proof-of-concept realization of our verification approach and demonstrates its applicability using the running example. In addition to showing that the approach is capable of detecting deadlocks, we provide an initial performance analysis. Finally, the approach is critically discussed and future directions for enhancing the approach are presented.

4.1 Prototypical Realization 1

We employed the petri-net tool Netlab to develop a prototypical realization of our approach as a first proof-of-concept. Netlab supports simple petri-nets with weighed arcs and multiple tokens per place.

Section 3.2), the marking of the end state of the process determines whether there is a real deadlock or not. In case there is a token in the end place, this means the process has terminated normally and thus there is no actual deadlock. In case there is no token in the end place, this means the process has not reach normal termination and thus this implies an actual deadlock.

4.2 Applicability The reachability graph computed for the example consists of 22 states that are shown in Figure 11 as output of the Netlab tool. In addition, the Netlab tool provides a summary of the petri-net properties as shown in Figure 10.

Figure 9 shows a screen-shot of the Netlab graphical editor with the petri-net of our running example. All petri-net concepts that we use in our formalization are supported by Netlab.

Figure 10. Petri-net Properties of Example In our example, reachability analysis provides the following results: 

Figure 9. Integrated Petri-net of Example Netlab offers two features for petri-net analysis: First, it allows the simulation of the petri-net (called “marker game”), facilitating the tracing and debugging of the event-driven business process. Second, and more importantly, the tool can compute a reachability graph for a given petri-net. The nodes of the reachability graph are all the petri-net states that can be reached from a given initial state. A petri-net state is a concrete marking of places by tokens. Transitions between states describe how to reach from one state to one or more next states. In case no next state exists, a deadlock in the petri-net is detected. Whether this deadlock in the petri-net also implies a deadlock in the event-driven business-process depends on the actual marking of that deadlock state. Assuming that our event-driven business process terminates (see the discussion on reachability analysis in 1

http://www.irt.rwth-aachen.de/download/netlab



The tool has detected one deadlock in the petri-net model in state M22. As mentioned above, it now depends on the marking in state M22 whether this is an actual deadlock or not. As highlighted in Figure 11, M22 does not have a token in the end place and thus we have detected an actual deadlock in our example. In addition to the deadlock, eight dead transitions are identified. Following these dead transitions may help in locating the root cause for the deadlock. In our example, we can trace back from dead transition T8 as follows: Transition T8 represents the “Compose EPA” of EPN B. T8 is never fired, because no event b is available from transition T12, as in turn transition T9 (representing EPN C) has not produced an event b. No event b can be produced, as EPN C only is activated once EPN B completes, which never can happen in our example

In general, a reachability graph is a good analysis technique for smaller petri-nets [17]. However, for larger petri-nets, it faces the state space explosion problem. To assess the scalability of the proof-of-concept realization, we have measured the execution time of the proof-of-concept realization for varying a number of tokens for an incoming event e. As visualized in Figure 12, the execution time for building the reachability graph exponentially increases with the number of external events. This means that we

Event stream e

BPMN Start Initial marking

BPMN End

Potential Deadlock

Figure 11. Reachability graph may quickly reach scalability limits with the explicit approach of first building a reachability graph and then analyzing this graph. One pragmatic solution is to only use the minimum number of tokens to meet the pre-conditions as laid out in Section 3.2. We discuss a more generic and scalable solution in the next section. 300

The petri-net formalization for event-driven business processes we presented in this paper has shown to be applicable to the detection of deadlocks. However, one limitation of using simple petrinets lies in the fact that only one event type per message queue or topic can be supported, because tokens cannot be differentiated. To discern the events based on their event type, the petri-net tokens in the formalization need to be enriched. Colored petri-nets are one potential candidate for an enriched formalization, as colored petri-nets offer a differentiation of tokens [18].

250 200

Time (sec)

input models. In fact, the CTL expressions we have provided in Section 3.2 already serve as specifications for the model-checking problem. Due to advanced heuristics for state-space exploration, model checkers may provide significantly improved scalability. As a future enhancement of our approach, we will thus formulate the deadlock detection problem in event-driven business processes as a model-checking problem.

150 100 50 0 2

25

50

75

100

125

150

175

200

Number of external events

Figure 12. Performance Analysis

4.3 Discussion and Future Enhancements As mentioned in the previous section, state-space explosion may become a problem for larger petri-nets. In addition to the size of a petri-net, the number of tokens affects state-space computation. For event-driven business processes, this may become a particular issue if the model should be verified for event streams with a large volume and velocity of events. An alternative solution to the explicit computation of a reachability graph is to employ model checkers that employ petri-nets as

5. RELATED WORK In this section, we describe related approaches for the verification of event-processing systems and business processes. For the verification of CEP systems, Etzion et al. use static analysis at design time to discover disconnected agents, the consequences of events, the provenance of generated events, and whether potential cycles exist in single EPNs [19]. Ericsson et al. propose a tool that uses existing property patterns for CEP to perform seamless, automatic verification of CEP rules [20]. Existing verification approaches focus on checking CEPs individually. Potential interactions and integration with business processes have not been considered.

For the verification of business processes, several formalizations for BPMN models have been proposed, including the mapping of BPMN objects to petri-nets [16]. Static analyses are performed by petri-net verification tools, including model checkers, which are used at design time [21]. The verification properties are defined in temporal logic, mostly in CTL. Properties like the absence of dead tasks or the proper completion of a business process are checked by those verification approaches. Although internal business process events, such as messages and exceptions, are considered by these approaches, continuous external event streams and more complex event processing agents are not supported. There is awareness that event-driven business processes may exhibit specific kinds of failures. As an example, Hummer et al. mention uncorrelatable events, transformation fault and deadlocks as potential failures [22]. Hans et al. consider the use of eventdriven messaging for business process execution. They focus on potential failures in the messaging middleware, such as deadlocks or livelocks [23]. To this end, they propose a petri-net formalization for publish/subscribe middleware. Sachs et al. introduce an approach for performance analysis of event-driven systems [15]. They formalize event-driven systems and their message interactions and event queues as queuing petri-nets. The petri-net dialect they employ promises to address some of the limitations of our approach identified above. Even though the above two approaches consider interactions between process participants, they do not explicitly consider event-processing rules and networks for their analysis. In conclusion, we lack a dedicated verification approach for event-driven business processes, which explicitly considers the interactions between business processes and event-processing networks.

6. CONCLUSIONS AND FUTURE WORK We presented a verification approach for detecting deadlocks in event-driven business processes. One key aspect of this approach is the formalization and integration of control flow (defined in the business process) and event flow (defined in event-processing networks and messaging middleware) into a single petri-net for analysis. We demonstrated that the analysis of such an integrated petri-net can uncover deadlocks that would go unnoticed if the business process and the event-processing elements were verified in isolation. Our proof-of-concept realization of the verification approach has demonstrated the feasibility of such deadlock analysis. However, the proof-of-concept faces scalability limitations due to statespace explosion of the underlying petri net reachability analysis we employed. In future work we therefore will investigate using state of the art model checkers that provide advanced heuristics for state space exploration. In addition, we will extend our formalization to more expressive petri net dialects (such as colored petri nets) to support event attributes such as event type, occurrence time or event sources.

7. ACKNOWLEDGMENTS The research leading to these results has received funding from the European Union's Seventh Framework Programme FP7/20072013 under grant agreement 604123 (FIspace) and from the EFRE co-financed operational program NRW.Ziel2 under grant agreement 005-1010-0012 (LoFIP).

8. REFERENCES [1] Julian Krumeich, Benjamin Weis, Dirk Werth, and Peter Loos, “Event-Driven Business Process Management: where are we now?,” Bus. Process Manag. J., vol. 20, no. 4, pp. 615–633, Jul. 2014. [2] R. von Ammon, C. Emmersberger, T. Greiner, F. Springer, and C. Wolff, “Event-Driven Business Process Management,” presented at the Fast Abstract, Second International Conference on Distributed Event-Based Systems, DEBS 2008, Rom, Juli 2008, Rom, 2008. [3] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” Comput. Netw., vol. 54, no. 15, pp. 2787 – 2805, 2010. [4] J. Erbes, H. R. Motahari Nezhad, and S. Graupner, “The Future of Enterprise IT in the Cloud,” Computer, vol. 45, no. 5, pp. 66–72, May 2012. [5] Networked European Software and Services Initiative (NESSI), “Software engineering: Key enabler for innovation.” Jul-2014. [6] Big Data Value Association (BDVA), “Big data value strategic research and innovation agenda (SRIA).” Jan-2015. [7] S. Wolfert, C. A. G. Sorensen, and D. Goense, “A Future Internet Collaboration Platform for Safe and Healthy Food from Farm to Fork,” in Global Conference (SRII), 2014 Annual SRII, 2014, pp. 266–273. [8] Z. Feldman, F. Fournier, R. Franklin, and A. Metzger, “Proactive Event Processing in Action: A Case Study on the Proactive Management of Transport Processes (Industry Article),” in Proceedings of the 7th ACM International Conference on Distributed Event-based Systems, New York, NY, USA, 2013, pp. 97–106. [9] A. Metzger, R. Franklin, and Y. Engel, “Predictive Monitoring of Heterogeneous Service-Oriented Business Networks: The Transport and Logistics Case,” in SRII Global Conference (SRII), 2012 Annual, 2012, pp. 313–322. [10] FInest EU FP7 Integrated Project, “Requirements Analysis and Selection of Technology Baseline for Event Processing Component (Deliverable-6.1).” 2011. [11] S. Appel, S. Frischbier, T. Freudenreich, and A. Buchmann, “Event Stream Processing Units in Business Processes,” in Business Process Management, F. Daniel, J. Wang, and B. Weber, Eds. Springer Berlin Heidelberg, 2013, pp. 187–202. [12] S. Appel, S. Frischbier, T. Freudenreich, and A. Buchmann, “Eventlets: Components for the Integration of Event Streams with SOA,” in Proceedings of the 2012 5th IEEE International Conference on Service-Oriented Computing and Applications (SOCA), Washington, DC, USA, 2012, pp. 1–9. [13] S. Appel, P. Kleber, S. Frischbier, T. Freudenreich, and A. Buchmann, “Modeling and execution of event stream processing in business processes,” Inf. Syst., vol. 46, pp. 140– 156, Dec. 2014. [14] O. Etzion and P. Niblett, Event Processing in Action, 1st ed. Greenwich, CT, USA: Manning Publications Co., 2010. [15] K. Sachs, S. Kounev, and A. Buchmann, “Performance Modeling and Analysis of Message-oriented Event-driven Systems,” Softw Syst Model, vol. 12, no. 4, pp. 705–729, Oct. 2013. [16] R. M. Dijkman, M. Dumas, and C. Ouyang, “Semantics and analysis of business process models in BPMN,” Inf. Softw. Technol., vol. 50, no. 12, pp. 1281–1294, Nov. 2008. [17] T. Murata, “Petri nets: Properties, analysis and applications,” Proc. IEEE, vol. 77, no. 4, pp. 541–580, Apr. 1989.

[18] W. M. P. Van Der Aalst, “The Application of Petri Nets to Workflow Management,” J. Circuits Syst. Comput., vol. 08, no. 01, pp. 21–66, Feb. 1998. [19] E. Rabinovich, O. Etzion, S. Ruah, and S. Archushin, “Analyzing the Behavior of Event Processing Applications,” in Proceedings of the Fourth ACM International Conference on Distributed Event-Based Systems, New York, NY, USA, 2010, pp. 223–234. [20] A. Ericsson, P. Pettersson, M. Berndtsson, and M. Seiriö, “Seamless Formal Verification of Complex Event Processing Applications,” in Proceedings of the 2007 Inaugural International Conference on Distributed Event-based Systems, New York, NY, USA, 2007, pp. 50–61.

[21] N. Lohmann and D. Fahland, “Where Did I Go Wrong?,” in Business Process Management, S. Sadiq, P. Soffer, and H. Völzer, Eds. Springer International Publishing, 2014, pp. 283–300. [22] W. Hummer, C. Inzinger, P. Leitner, B. Satzger, and S. Dustdar, “Deriving a Unified Fault Taxonomy for Eventbased Systems,” in Proceedings of the 6th ACM International Conference on Distributed Event-Based Systems, New York, NY, USA, 2012, pp. 167–178. [23] P. Hens, M. Snoeck, G. Poels, D. Backer, and Manu, “A Petri Net Formalization of a Publish-Subscribe Process System,” Social Science Research Network, Rochester, NY, SSRN Scholarly Paper ID 1886198, Jul. 2011.