modeling and execution of event stream processing in ... · epc and bpmn extensions to model spus...

Modeling and Execution of Event Stream Processing in Business Processes

Stefan Appel, Pascal Kleber, Sebastian Frischbier, Tobias Freudenreich, Alejandro Buchmann

TU Darmstadt, Databases and Distributed Systems Group, Darmstadt, Germany

Abstract

The Internet of Things and Cyber-physical Systems provide enormous amounts of real-time data in form of streams of events.Businesses can benefit from the integration of these real-world data; new services can be provided to customers, or existing businessprocesses can be improved. Events are a well-known concept in business processes. However, there is no appropriate abstractionmechanism to encapsulate event stream processing in units that represent business functions in a coherent manner across the processmodeling, process execution, and IT infrastructure layer. In this paper we present Event Stream Processing Units (SPUs) as such anabstraction mechanism. SPUs encapsulate application logic for event stream processing and enable a seamless transition betweenprocess models, executable process representations, and components at the IT layer. We derive requirements for SPUs and introduceEPC and BPMN extensions to model SPUs at the abstract and at the technical process layer. We introduce a transformation fromSPUs in EPCs to SPUs in BPMN and implement our modeling notation extensions in Software AG ARIS. We present a runtimeinfrastructure that executes SPUs and supports implicit invocation and completion semantics. We illustrate our approach using alogistics process as running example.

Keywords:Event-stream processing, Business process modeling, Business process execution, EPC extensions, BPMN extensions

1. Introduction

Business process modeling and execution is widely adoptedin enterprises. Processes are modeled by business experts andtranslated into executable workflow representations. They areexecuted inside IT infrastructures, e.g., Service-oriented Archi-tectures (SOAs) or workflow management systems. With theadoption of the Internet of Things and Cyber-physical Systems,huge amounts of information become available that reflect thestate of the real world. The integration of this up-to-date infor-mation with business processes (BPs) allows quick reactionson unforeseen situations as well as offering new services tocustomers, e.g., monitoring of environmental conditions duringtransport of goods and handling exceeded temperature thresh-olds [1].

A common paradigm for the representation of informationfrom sources like the Internet of Things or Cyber-physical Sys-tems is streams of events. The notion of a stream illustratesthat new events occur over time, e.g., continuous temperaturesensor readings. In such event-based systems, event producersdo not necessarily know the event consumers, or whether theevents will be consumed at all. This independence is intrin-sic to the event-based approach [2]. The decoupling of eventproducers and consumers as well as the arrival of an indefi-nite number of events over time requires an appropriate event

Email addresses: [email protected] (Stefan Appel),[email protected] (Pascal Kleber),[email protected] (Sebastian Frischbier),[email protected] (Tobias Freudenreich),[email protected] (Alejandro Buchmann)

dissemination mechanism. Commonly, publish/subscribe sys-tems are used; they allow asynchronous m:n communicationbetween fully decoupled participants. Event consumers specifytheir interest in events in form of subscriptions; event producersspecify the type of events they may publish in advertisements.

While single events are a well-known and established con-cept in BP models [3, 4], event stream processing lacks an ap-propriate abstraction for the seamless integration across the pro-cess modeling, process execution, and IT infrastructure layer.In collaboration with Software AG1 we developed Event StreamProcessing Units (SPUs) as such an integration concept for eventstream processing.

In this paper we present SPUs. SPUs provide a service-likeabstraction to encapsulate event stream processing logic at theabstraction level of business functions. They hide implementa-tion details and are suitable building blocks for the integrationof event stream processing with BPs. We analyze BP model-ing, BP execution, and the IT infrastructure, and derive require-ments for SPUs at the modeling, execution, and IT infrastruc-ture layer. We address the decoupled nature of event-based sys-tems and provide process modelers with an appropriate repre-sentation of SPUs that can be mapped to executable workflowrepresentations and the IT infrastructure seamlessly. At the ITlayer, SPUs are manageable components that are conceptuallyequivalent to services in a SOA. SPUs contain, for example,complex event processing (CEP) functionality.

This paper extends previous work: In [5] we introduce Busi-ness Process Model and Notation 2.0 (BPMN) extensions to

1www.softwareag.com

Preprint submitted to Information Systems April 28, 2014

model SPUs. SPUs, however, are a generic concept not limitedto a specific modeling notation. Thus, we present an additionalimplementation of SPUs in this paper: we introduce extensionsto model SPUs in Event-driven Process Chains (EPCs) as an al-ternative BP modeling notation with focus on abstract processmodels from a business perspective. We also present a mappingbetween SPUs in EPCs and SPUs in BPMN to illustrate thegeneric applicability of our SPU concept; it can be applied todifferent modeling notations to support, for example, a holisticBP modeling approach. As further extensions to [5] we providemore examples on modeling SPUs with BPMN and additionaldetails on workflow execution semantics. We also present animplementation for modeling and execution of SPU-containingprocess models.

The paper is structured as follows: we introduce a logisticsscenario as running example; we then derive requirements forthe integration of event stream processing with BPs at the mod-eling, execution, and IT infrastructure layer. In Section 3, weintroduce Event Stream Processing Services (ESPSs) as an ex-tension to EPCs to model SPUs. We introduce Event StreamProcessing Tasks (ESPTs) as BPMN 2.0 extension to modelSPUs. We present a mapping of SPU-containing process mod-els from EPCs to BPMN and from BPMN to BPEL as well asa runtime environment for SPUs. In Section 4 we present theimplementation of our EPC and BPMN extensions in SoftwareAG ARIS; we sketch the model-to-execute workflow that bringsSPU-containing business process models to execution. In Sec-tion 5 we discuss related work; we summarize our findings inSection 6.

Scenario

We illustrate our concept of SPUs by means of an order-to-delivery process. The processing of an order consists of multi-ple process steps: an order is received, the invoice for the orderis prepared and the payment is processed. With SPUs, data gen-erated during the physical transport can now be integrated withthis process. An event stream that provides monitoring data re-lated to the shipment can be used to detect, e.g., temperaturethreshold violations. An SPU can represent such a monitoringtask and integrate it at the BP modeling, BP execution, and ITinfrastructure layer. A shipment monitoring SPU is instantiatedwith the shipment of an order. The SPU completes after deliv-ery. Throughout the paper, we illustrate our approach on thebasis of such a monitoring SPU.

2. Event Stream Integration Requirements

Business process models describe workflows in companiesin a standardized way. They document established businessprocedures with the goal of making complex company struc-tures manageable. This encompasses the business perspectiveas well as the IT perspective. For the modeling and execution ofprocesses, an appropriate level of abstraction is crucial to hideirrelevant details to the process modeler. Building blocks forBP modeling, BP execution, and IT infrastructure should en-capsulate business functions in a self-contained way, e.g., like

services in a SOA [6]. The BP model describes interactionsbetween these building blocks.

The implementation of BPs in enterprises involves threelayers: the modeling layer, the execution layer, and the IT in-frastructure layer (see Figure 1). During design time, businessexperts create models from a business perspective, e.g., usingEvent-driven Process Chains (EPCs) [7, 3] or the Business Pro-cess Model and Notation 2.0 (BPMN) [4]. The models are thentransformed into executable workflows represented in, e.g., theBusiness Process Execution Language (BPEL) [8]. Typically,the workflow execution requires IT support, which is providedby a SOA and workflow management systems.

Model (e.g., BPMN 1/2, EPC)

<process name="pns:Caller"> <invoke partnerLink=“Link"> <service name="wns:Billing”/> </invoke> </process>

Executable Workflow (e.g., BPMN 2.0, BPEL)

IT Infrastructure (e.g., SOA, EDA)

BPM Transition Process

Billing by Credit Card

Invoke Billing by Credit Card Service

Billing by Credit Card Service

Invoke Invoice Service and Billing Service

Billing Service (different methods); Invoice Service

Accounting (Invoice & Billing)

Examples of Abstraction high coherence low coherence

Des

ign

Tim

e Run

Tim

e

Status quo Effort? High/low Impl. & maint.

Figure 1: Transition steps between process modeling, process execution, andIT infrastructure layer.

The transition process from a BP model to, e.g., SOA ser-vice interactions is not trivial and requires expertise from thebusiness perspective as well as from the IT perspective. Toenable the seamless implementation of modeled processes, theabstraction of business functions should have the same gran-ularity at each layer; a coherent abstraction across the layersminimizes the transition effort [9]. The example in Figure 1illustrates this: the low coherence case requires a refinementwith each transition step (a single BPMN task maps to multi-ple services) while the high coherence case allows a one-to-onetransition between the business function representations avail-able at each layer (e.g., BPMN tasks, BPEL invocations, andSOA services). In the following, we derive requirements forSPUs as business function abstractions. With the encapsulationof event stream processing in SPUs, a high coherence betweenthe different layers is achieved; this supports a seamless tran-sition between process model, executable workflow, and IT in-frastructure. Table 1 shows the requirements we derive in thefollowing sections in a summarized form to simplify later ref-erence.

2.1. Business Process Modeling Layer

Process models are typically created by business expertsthat have a good knowledge about the company structure andestablished workflows. These process models describe interac-tions between business functions [6]. For a clear separation ofconcerns between the business perspective and the IT perspec-tive, it is necessary to encapsulate event stream processing logicin SPUs that hide technical details at the modeling layer. SPUsare the abstract representation of business functions that processevent streams. SPUs require at least one event stream as inputand may output event streams or single events. An important

2

characteristic of SPUs is the demand for continuous process-ing of event streams; rather than in single request/reply interac-tions, SPUs process new events as they arrive, e.g., a shipmentmonitoring SPU receives new monitoring data continuously.

RequirementsFor the integration of event streams, the modeling notation

has to provide elements or patterns to express SPUs (R1) [10].While the actual event-processing functionality is encapsulatedinside SPUs, event streams – as they represent a core data asset– should be accessible by the modeler [11]. Further, integratingevent streams during modeling simplifies the transition to anexecutable workflow [12]. Thus, the modeling notation has toprovide means to express event streams as input/output to/fromSPUs (R2). Finally, the modeling notation must allow SPUs torun continuously and in parallel to other tasks (R3). This in-cludes appropriate execution semantics adapted to event-basedcharacteristics (R4) [13].

2.2. Workflow Execution Layer

The execution of BP models requires a transition from the,often graphical, model notation to a formal process representa-tion. The interactions between the different process tasks areformalized in a workflow description, e.g., using BPEL. Thisworkflow description contains, e.g., service invocations and de-fines the input data for services. Like traditional BP tasks canbe mapped to human tasks or service invocations, SPUs need tobe mapped from the model to the IT infrastructure.

RequirementsTo support SPUs at the workflow execution layer, the exe-

cution notation has to support the instantiation of the SPU con-tainers provided by the IT infrastructure (R5) [14]. It furtherneeds means to define streams of events as input and output ofSPUs (R6). The instantiation and completion of SPUs needsto be configurable with respect to event-based characteristics(R7) [13].

2.3. IT Infrastructure Layer

The IT infrastructure holds the technical representations ofSPUs. It is responsible for the execution of the encapsulatedevent stream processing logic. In contrast to SOA services,SPUs follow the event-based paradigm. While services are in-voked explicitly, SPUs react on streams of events. Servicesencapsulate business functions in a pull manner (reply is re-quested); SPUs encapsulate reactive business functions that aredefined on event streams pushed into the system.

RequirementsThe IT infrastructure has to provide a runtime environment

for SPUs that respects event-based characteristics, e.g., implicitinstantiation (R8) [13]. It must provide containers for SPUsthat represent business functions (R9) [10]. Just like services,these SPU containers must be manageable and capable of re-ceiving the required data in form of event streams (R10) [15].

R1 Model notation support for SPUsR2 Model notation support for event streamsR3 Continuous and parallel execution of SPUsR4 Event-based-compliant SPU completion semantics

R5 SPU instantiation supportR6 Support input/output to/from SPUs in form of event

streamsR7 Control over SPU instantiation and completion behav-

ior

R8 Runtime environment for SPUsR9 SPU container modelR10 Support for SPU management

Table 1: Combined requirements at business process modeling, business pro-cess execution, and IT infrastructure layer

3. Event Stream Processing Units

To support SPUs at the BP modeling, BP execution, andIT infrastructure layer, we suggest mechanisms at each layer.At the modeling layer, we introduce Event Stream ProcessingServices (ESPSs) to represent SPUs in EPCs and Event StreamProcessing Tasks (ESPTs) to represent SPUs in BPMN processmodels. Our SPU concept is applicable in the context of dif-ferent modeling notations as we show by means of a mappingbetween ESPSs and ESPTs. At the IT infrastructure layer, weadapt Eventlets [14] for the implementation of SPUs. The exe-cution layer is responsible for the mapping between ESPTs andEventlets. This is shown in Figure 2: like services are the basicbuilding blocks of a SOA, SPUs are the basic building blocks ofan event-driven architecture (EDA). At the execution layer, ser-vice tasks in a model are mapped to, e.g., web services. Equally,ESPTs are mapped to Eventlets.

Event Streams Database: Persistent Data

EDA

SPU1 ... SPUn

SOA

Service1 ... Servicen

Reactive Workflow (e.g., BPEL, BPMN 2.0)

Push-based (subscribe)

Pull-based (request/reply)

Reactive Business Processes (e.g., BPMN)

Service Task

Web Service

Event Stream Processing Task

Eventlet

Figure 2: Stream Processing Units (SPUs) as building blocks of an event-drivenarchitecture (EDA)

3.1. Modeling Layer

Different business perspectives need to be incorporated dur-ing BP modeling. Business analysts provide knowledge aboutprocesses from an abstract business perspective. The resultingprocess models are then refined iteratively, e.g., by process en-gineers, and evolved to more technical process representations.EPCs, for example, follow a strict scheme with business eventsfollowed by functions. They are widely adopted in industry and

3

well suited for the abstract modeling from the business perspec-tive [16]. BPMN is a newer and more powerful process mod-eling notation. It supports abstract as well as technical processmodels and is typically more compact than EPCs. Both nota-tions can be combined to support a holistic BP modeling pro-cess. This is, for example, the case in Software AG’s model-to-execute process: EPCs are used for abstract, business-orientedmodels; BPMN is used for technical process models. A modeltransformation process is specified for the transition betweenEPCs and BPMN.

The integration of SPUs with EPCs and BPMN requires ex-tensions to the modeling notations that address the characteris-tics derived from the streaming nature of event data. SPUs ex-hibit the following specific properties that cannot be expressedcompletely with existing EPC and BPMN elements:

• Execution semantics: After the instantiation, SPUs canrun indefinitely; events arrive and are processed contin-uously, e.g., temperature measurements during the ship-ment transport. The completion semantics differ fromservice-like request/reply interactions where the reply trig-gers the process control flow to proceed. In contrast,completion of SPUs has to be triggered - either implic-itly or explicitly. In either case, the completion indicatesa clean shutdown. Implicit completion requires the spec-ification of a condition that determines when the SPUshould complete. Examples are a timeout in case no newevents arrive, the detection of a certain event pattern, ordedicated events, e.g., shipment arrival. Explicit comple-tion triggers the completion of an SPU externally. Forexample, when a process reaches a point where the pro-cessing of an event stream is not required anymore, e.g.,shipment arrival has been confirmed.

• Signaling: The continuous processing inside of SPUs re-quires support to trigger concurrent actions, e.g., trigger-ing exception handling in case of a temperature thresholdviolation without stopping the shipment monitoring SPU.

• Event stream input and output: The inputs for SPUs areevent streams. An event stream is specified by a subscrip-tion to future events, e.g., temperature measurements fora certain shipment. The output is specified by an adver-tisement that describes the events producible by an SPU.

3.1.1. SPU Integration with EPCsEPCs are a notation for computation independent models

(CIM), a concept in model driven architectures [17]. CIMs,also referred to as business or domain models, are created froma business viewpoint and contain only few technical details.EPCs became popular as process modeling notation for SAP R/3as well as notation in the context of ARIS (Architecture of In-tegrated Information Systems) [18]. ARIS is an approach forholistic business process modeling and management of enter-prise information systems. EPCs consist of functions (e.g., con-firm order) preceded and followed by business events (e.g., or-der arrived and order confirmed). Event stream processing canbe modeled as such EPC functions; an EPC function refers to

an SPU. In ARIS, EPC functions are supported by services withattached capabilities, e.g., an order confirmation service has thecapability to send out confirmations [19]. To model SPUs inEPCs we specify an appropriate supporting service type forEPC functions that represents event stream processing. Thisinvolves extensions to EPCs on the basis of service type objectswith capabilities.

Details of a service type object are modeled in a service al-location diagram; it describes a service from an abstract pointof view. In the service allocation diagram arbitrary objects areconnected to the service type object via associations. Con-nected objects are, for example, descriptions of the organization(organizational unit, responsible person) or data objects used asinput or as output of the service.

We introduce Event Stream Processing Services (ESPSs) tosupport EPC functions that represent event stream processing.ESPSs are a distinct service category based upon service typeobjects [19]; they are represented with a custom symbol type(see Figure 3, center). Since event objects in EPCs are not suf-ficient to model event streams – they rather represent a stateof a process than the continuous nature of event streams – weintroduce Event Stream Specifications (ESSs) that reflect inputdata and output data in form of event streams. We adapt a clus-ter model object to represent these event streams (see Figure 3,left). The Event Stream Processing Unit type (see Figure 3,right) is used to refer to the technical realization of SPUs.

��

� ��

��

� ��

Figure 3: Extensions to EPCs: Event Stream Specification (ESS), Event StreamProcessing Service (ESPS), and Event Stream Processing Unit Type

Definition 1. In EPCs an Event Stream Specification (ESS)(→ R2) references a stream of events. An ESS is a subtype of anabstract business object. The object type can be used as input oras output of functions, ESPSs, or Event Stream Processing Unittypes. The attached connection type specifies whether the ESSis input to or output from other objects. An ESS used as inputdetermines the subscription an ESPS has to issue. An ESS usedas output determines the advertisement that describes the eventoutput stream of an ESPS.

Definition 2. A function in an EPC that refers to an SPU issupported by an Event Stream Processing Service (ESPS) (→R1, R3, R4). An ESPS requires at least one ESS as input. It mayhave output ESSs. When the control flow reaches a functionsupported by an ESPS, this ESPS is activated with the specifiedESS as input. The completion of the ESPS is triggered implicitlyor explicitly (→ R5).

Implicit and explicit completion of ESPSs is expressed withdifferent instantiation capabilities: Start Processing with Com-pletion Condition and Start Processing. Explicit completion isalso expressed as a distinct capability of the ESPS. Upon com-pletion, either implicitly or explicitly, the ESPS stops process-ing, performs a clean shutdown, and passes on the control flow.

4

To trigger concurrent actions, ESPSs can send events; this ismodeled as a loop. An ESPS can be modeled with combinedexplicit and implicit completion. An ESPS has an associatedEvent Stream Processing Unit type: it provides the link to tech-nical process model representations. The Service AllocationDiagram for an ESPS is shown in Figure 4.

��

� ��

��

��

��

��

� ��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

��

Figure 4: A Service Allocation diagram provides the abstract configuration ofan Event Stream Processing Service. Objects, like the organizational unit, theresponsible person, or input/output data, are connected to the service type objectvia associations.

3.1.2. Example: Modeling Shipment Monitoring with EPCsTo illustrate the application of our EPC extensions, we model

the monitoring of environmental conditions in the order processintroduced in Section 1 with EPCs. An SPU is used to processan event stream that contains environmental data events, e.g.,temperature measurements. Figure 5 shows the service alloca-tion diagram for the ESPS that represents this shipment moni-toring SPU. The shipment monitoring ESPS requires shipment-monitoring events as input; it has capabilities to initialize theSPU with implicit and explicit completion.

��

��

��

��

��

��

��

��

Figure 5: The Shipment Monitoring example Service Allocation Diagram

Figure 6 shows the EPC process model with implicit com-pletion of the SPU. The monitor shipment function receivesshipment-monitoring events as input event stream. The func-tion is supported by the monitor shipment ESPS (see Figure 5);it uses a capability of the ESPS to initialize an SPU with animplicit completion condition. The implicit completion condi-tion is assigned to the connection between the EPC function andthe ESPS start processing with completion condition capability.Implicit completion is triggered when the shipment arrives at itsdestination address.

To report an environmental condition violation, the SPU isfollowed by an XOR operator: the process control flow triggersthe environmental condition violation event and directly returnsto the monitoring function. This control flow loop is instanta-neous so that the SPU continues processing; the event streamprocessing is not interrupted at the technical layer. This SPU-specific loop pattern is used to model asynchronous messagingin EPCs as required in event stream processing scenarios. Thecompletion of the SPU is triggered as soon as the completioncondition is fulfilled, i.e., when the shipment reaches its desti-nation. With completion of the SPU, the control flow moves onto the XOR operator and results in the shipment arrived event,which completes the process.

Figure 7 shows the order process with explicit completionof the SPU. The monitor shipment function is supported by theESPS capability for initialization with explicit completion. Anadditional process step is added after the arrival confirmation totrigger the explicit completion. The complete shipment moni-toring function uses the end processing capability of the ship-ment monitoring ESPS to trigger the completion of the ship-ment monitoring.

It is also possible to model SPUs with implicit and explicitcompletion in parallel. The monitor shipment function shownin Figure 6 is then combined with the complete shipment func-tion shown in Figure 7.

3.1.3. SPU Integration with BPMNBPMN 2.0 is widely adopted in industry and has a broad

tool support. From a technological perspective, processes canbe modeled in different granularities with BPMN. From a se-mantical perspective, the single building blocks (BPMN tasks)of a process model should reflect business functions and hidetechnical details. Our extensions to BPMN are shown in Fig-ure 8. As for EPCs, we define Event Stream Specifications(ESSs) that reflect input data and output data in form of eventstreams. Further, we introduce Event Stream Processing Tasks(ESPTs) to model SPUs.


Input Event Stream

Output Event Stream


Implicit Completion Explicit Completion Completion Condition Stop Signal

Figure 8: Extensions to BPMN: Event Stream Specifications (ESSs) and EventStream Processing Tasks (ESPTs)

Definition 3. In BPMN an Event Stream Specification (ESS)(→ R2) references a stream of events and their parameters.ESSs can be used as input and output of ESPTs. An ESS usedas input determines the subscription an ESPT has to issue. AnESS used as output determines the advertisement that describesthe event output stream of an ESPT.

Definition 4. In BPMN an SPU is modeled as Event StreamProcessing Task (ESPT) (→ R1, R3, R4). An ESPT requiresat least one ESS as input. It may have output ESSs. When thecontrol flow reaches an ESPT, it is activated with the specifiedESS as input. The transition from the active state to the com-pleting state (see BPMN task lifecycle [4, p. 428]) is triggeredimplicitly or explicitly (→ R5).

5

��

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

�!" #�$

Figure 6: The Shipment Monitoring example BP as EPC utilizing an SPU with implicit completion. The previously defined EPC extension elements are used.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

Figure 7: The Shipment Monitoring example BP as EPC utilizing an SPU with explicit completion

6

The implicit completion of an ESPT is realized with a mod-ified conditional sequence flow; the condition determines whenthe ESPT completes. The explicit completion is realized witha dedicated signal. It is attached as non-interrupting signal tothe boundary of the ESPT. Upon completion, either implicitlyor explicitly, the ESPT stops processing, performs a clean shut-down, and passes on the control flow, i.e., no additional token iscreated at catching the shutdown signal. To trigger concurrentactions, ESPTs can activate outgoing sequence flow elementswhile remaining in the active state. Non-interrupting condi-tional events can be attached to the boundary of an ESPT toindicate a conditional activation of sequence flow elements. AnESPT can be modeled with combined explicit and implicit com-pletion.

3.1.4. Related BPMN ConceptsEvents are part of the BPMN specification. However, events

in BPMN are meant to affect the control flow in a process [4,p. 233]. Events modeled as ESS do not exhibit this property;they are rather a source of business-relevant information that isexploited within the process. Due to these different semantics,events in the sense of the BPMN standard are not appropriateto model event stream input/output to/from SPUs.

From the task types contained in the BPMN standard, ser-vice tasks, business rule tasks, loop service tasks, and multipleinstance service tasks share properties with SPUs. However,the modeling of SPUs with those existing BPMN task types isnot feasible.

Service Tasks are containers for business functions that areimplemented as SOA services. The execution semantics for ser-vice tasks state, that data input is assigned to the service taskupon invocation; upon completion output data is available. ForSPUs, this separation is not feasible; input data arrives con-tinuously and output data can be available during task execu-tion in form of output streams. Therefore, service tasks are noappropriate representation for SPUs. In Business Rule Tasks,event stream processing can be used to check conformance withbusiness rules. However, event stream processing supports awider application spectrum than conformance checking, e.g.,real-time shipment tracking. Further, output in form of eventstreams is not part of business rule tasks; their purpose is tosignal business rule evaluation results. Loop Service Tasks per-form operations until a certain stop condition is met. However,the whole loop task is executed repeatedly, i.e., a repeated ser-vice call. This repeated execution of a business function de-picts a different level of abstraction compared to continuousprocessing inside an SPU; SPUs perform continuous process-ing to complete a single business function. To use loop tasksfor event stream processing, the process model would have todefine the handling of single events rather than the handling ofevent streams. This conflicts with the abstraction paradigm ofbusiness functions and degrades coherence across the layers.Multiple Instance Service Tasks allow the execution of a taskin parallel, i.e., parallel service calls. However, like loop tasks,this would require one task per event which conflicts with theintention to encapsulate business functions in tasks. In addi-tion, the number of task instances executed in parallel is static

and determined at the beginning of the task. This is not suitablefor event processing since the number of events is not known apriori.

In general, BPMN tasks have no support for triggered com-pletion required in event processing. In addition, event streamscannot be represented as input to and output from tasks. Thus,we extend BPMN with ESPTs. ESPTs support implicit and ex-plicit completion, an essential part of SPU execution semantics.Further, we introduce ESSs as input to and output from ESPTsin the form of event streams.

3.1.5. Example: Modeling Shipment Monitoring with BPMNTo illustrate the application of our BPMN extensions, we

model the monitoring of environmental conditions in the or-der process introduced in Section 1 with BPMN. Figures 9 and10 show two variants with different completion strategies. Theshipment monitoring is an SPU that receives monitoring eventsas input stream. This shipment monitoring SPU is modeledas an ESPT in BPMN; the monitoring events are assigned asan input ESS. The monitoring task can send a message event(as concurrent action) to indicate a violation of environmentalconditions, e.g., temperature threshold exceeded. The messageevent can activate a task or trigger a different process for han-dling the exception; this exception handling is omitted here forbrevity.

In Figure 9, the shipment monitoring is modeled with ex-plicit completion semantics. As soon as the shipment has ar-rived, the monitoring is not required anymore. Thus, the moni-toring task completion is triggered by sending the stop signal.

In Figure 10, the shipment monitoring is modeled with im-plicit completion semantics. This requires the definition of acompletion condition. In our example, we specify the shipmentarrival: when the location of the shipment matches the desti-nation address, the monitoring is completed. Other implicitcompletion conditions could be dedicated arrival events, e.g.,arrival scans of shipment barcodes, or timeouts, e.g., no newmonitoring events for the shipment arrive. The condition needsto be evaluated inside the SPU, thus support for different condi-tion types depends on the technical infrastructure that executesSPUs.

The modeling of data flow between ESPTs is shown in Fig-ure 11. The shipment monitoring SPU outputs a stream ofevents that indicate exceeded temperature thresholds. The re-port threshold violation SPU receives these events and imple-ments the reporting, e.g., by sending an email in case temper-ature thresholds were exceeded multiple times. Completion ofthe reporting SPU is triggered explicitly after the confirmationof arrival of the shipment. The monitoring SPU completes im-plicitly.

ESPTs can also be modeled with implicit and explicit com-pletion in parallel as shown in Figure 12. The implicit com-pletion is the default case: the monitoring stops as soon as theshipment has reached its destination. In addition, an explicitcompletion is modeled: when a customer cancels the order,shipment monitoring becomes obsolete.

The output of ESPTs can affect process execution as shownin Figure 13. When an environmental condition violation is de-

7

Business Process Model and Notation, v2.0 163

User Task

A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.

A User Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a human figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).

Figure 10.17 - A User Task Object

See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks.

Manual Task

A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.

A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).

Figure 10.18 - A Manual Task Object

See “Manual Task” on page 165 within the larger section of “Human Interactions” for the details of Manual Tasks.

Business Rule

A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task (see page 211) will allow the Process to send data to and receive data from the Business Rules Engine.

A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).Business Process Model and Notation, v2.0 163

User Task





Manual Task





Business Rule


A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).

158 Business Process Model and Notation, v2.0

10.2.3.1 Types of Tasks

There are different types of Tasks identified within BPMN to separate the types of inherent behavior that Tasks might represent. The list of Task types MAY be extended along with any corresponding indicators. A Task which is not further specified is called Abstract Task (this was referred to as the None Task in BPMN 1.2). The notation of the Abstract Task is shown in Figure 10.8.

Service Task

A Service Task is a Task that uses some sort of service, which could be a Web service or an automated application.

A Service Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Service Task (see Figure 10.11).

A Service Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that distinguishes the shape from other Task types (as shown in Figure 10.11).

Figure 10.11 - A Service Task Object

The Service Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints are introduced when the Service Task references an Operation: The Service Task has exactly one inputSet and at most one outputSet. It has a single Data Input with an ItemDefinition equivalent to the one defined by the Message referenced by the inMessageRef attribute of the associated Operation. If the Operation defines output Messages, the Service Task has a single Data Output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated Operation.

The actual Participant whose service is used can be identified by connecting the Service Task to a Participant using a Message Flows within the definitional Collaboration of the Process – see Table 10.1.




Service Task







Confirm Order

SPU: Monitor

Shipment

Create Invoice

Process Payment

Confirm Arrival

Shipment Monitoring

Events

ShutdownMonitoring

ShutdownMonitoring

Explicit Shutdown Special non interrup3ng signal to indicate proper ending of EBC

Environmental Condition Violation

Figure 9: Shipment monitoring SPU that is stopped explicitly. The data input/output of the service tasks is omitted.


User Task





Manual Task





Business Rule




User Task





Manual Task





Business Rule






Service Task










Service Task







Confirm Order

SPU: Monitor

Shipment

Create Invoice

Process Payment

Confirm Arrival

Shipment Monitoring

Events Environmental Condition Violation

Implicit Shutdown

Shipment Arrival: Location matches destination address

Figure 10: Shipment monitoring SPU that is stopped implicitly. The data input/output of the service tasks is omitted.


User Task





Manual Task





Business Rule




User Task





Manual Task





Business Rule






Service Task










Service Task







Confirm Order

SPU: Monitor

Shipment

Create Invoice

Process Payment

Confirm Arrival

Shipment Monitoring

Events

Implicit Shutdown


SPU: Report

Threshold Violation

Threshold Exceeded Events

ShutdownReporting

ShutdownReporting

Figure 11: Interacting SPUs: Output from monitoring SPU is used as input for reporting SPU. The SPUs have different completion strategies.


User Task





Manual Task





Business Rule


A Business Rule Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).Business Process Model and Notation, v2.0 163

User Task





Manual Task





Business Rule






Service Task










Service Task







Confirm Order

SPU: Monitor

Shipment

Create Invoice

Process Payment

Confirm Arrival

Shipment Monitoring

Events

ShutdownMonitoring

Shutdown Monitoring



User Task





Manual Task





Business Rule



Cancel Order

Order Canceled

Figure 12: ESPT with implicit and explicit completion: Upon cancelation of an order the shipment monitoring is completed explicitly; upon shipment arrival,monitoring completes implicitly.

8


User Task





Manual Task





Business Rule






Service Task










Service Task







Confirm Order

SPU: Monitor

Shipment

Create Invoice

Process Payment


User Task





Manual Task





Business Rule



Confirm Arrival

Shipment Monitoring

Events

ShutdownMonitoring


User Task





Manual Task





Business Rule



Send Shipment


Discard Goods

Replacement requested by

customer

Environmental Condition Violation


User Task





Manual Task





Business Rule



Reimburse Cancelation

Cancelation

Figure 13: ESPT that affects process execution: Upon detection of an environmental condition violation the shipment monitoring is stopped and the customerdecides upon cancelation of the order.

tected the shipment monitoring is stopped. After completion ofthe shipment monitoring ESPT, discarding of goods is triggeredand the customer decides upon cancelation of the order. In thiscase a reimbursement is triggered via a compensation event.

3.1.6. Transformation from EPC to BPMNEPCs can be used for abstract process models from a busi-

ness perspective; processes are modeled at the CIM layer. Forthe execution of processes a technical process representationis required that correlates with an executable process represen-tation. Since BPMN is a suitable notation for such technicalmodels, EPC models can be transformed to BPMN in orderto support automated process execution. This also requires atransformation of SPUs. Since SPUs are independent of a con-crete modeling notation a mapping of SPUs in EPCs to SPUsin BPMN is possible. The transformation from EPCs to BPMNcan also be partly automated. This is, for example, supportedby the Software AG ARIS business process platform.

Theoretical approaches for a mapping from EPCs to BPMNare given in [20]. The basic concept is the transformation ofEPC functions into a BPMN tasks. EPC events are disregardedas long as they are not decision conditions for connectors. Op-erators, organizational elements, and data objects are directlytransformed into their BPMN representations. In ARIS, for ex-ample, functions supported by a screen object are mapped toBPMN user tasks; functions assigned with an organizationalobject only are mapped to manual tasks. Analogously, we de-fine the mapping from EPC functions that are supported by ES-PSs to ESPTs in BPMN as shown in Figure 14.

An EPC function that is supported by an ESPS with im-plicit completion is mapped to an ESPT with implicit comple-tion, i.e., the completion condition assigned to the connectionbetween the EPC function and the capability is mapped to theoutgoing sequence flow of the ESPT (⇔a in Figure 14). AnEPC function that is supported by an ESPS with explicit com-pletion is represented by an ESPT with explicit completion; thecompletion is triggered by an SPU intermediate boundary non-interrupting signal event (⇔b in Figure 14). This event is trig-

��

��

��

��

��

��

��

⇔aEvent Stream

Processing Task

Completion Condition

��

��

��

��

��

⇔bEvent Stream

Processing Task

��

��

��

��

��

⇔c

��

��

��

��

��

��

��

��

��

��

⇔d Event Stream Processing Task

Condition

Figure 14: Mapping of SPUs between EPC and BPMN

9

gered by the SPU signal intermediate throwing event, which isthe BPMN representation for the explicit completion capabilityused by an EPC function (⇔c in Figure 14). ESPTs in BPMNallow non-interrupting conditional events to be attached to theboundary of an ESPT for a conditional triggering of subsequentactions. In EPCs this is modeled with an event loop enclosingsolely the event stream processing function (⇔d in Figure 14).The function supported by an ESPS is not completed in thiscase; the control flow directly returns. The outgoing EPC eventis consumed elsewhere and triggers concurrent functions.

Event streams in EPC are mapped to their corresponding el-ements in BPMN: an EPC input ESS (is input for association)is mapped to the BPMN input ESS; an EPC output ESS (hasas output association) is mapped to the BPMN output ESS. InEPCs the distinction between input and output event stream isbased on the type of the association connection, in BPMN indi-vidual elements for both cases exist.

3.2. Workflow Execution LayerThe execution of BPs by an IT infrastructure requires a tran-

sition from the technical process model to an executable processformat. The BPMN 2.0 standard itself specifies such executionsemantics; the standard also provides examples for the mappingbetween BPMN and BPEL. Independent of the concrete techni-cal representation format, the goal is to bridge the semantic gapbetween the technical model notation and interfaces of IT com-ponents so that the process can be executed automatically. Thetransition from a technical process model towards an executableprocess representation requires adding additional technical de-tails.

For different task types and control flow components, exe-cution languages provide executable representations. When themapping of graphical process task and process control flow el-ements is complete and all necessary data is specified, the pro-cess execution engine is able to execute instances of the process.Each instance reflects a concrete business transaction, e.g., pro-cessing of Order No. 42. For each process instance, the execu-tion engine orchestrates the different tasks, passes on task inputand output data, and evaluates conditions specified in the con-trol flow. Examples are the execution of BPMN service tasksand human tasks: a service task can be executed by calling aweb service. For this, the execution engine needs the serviceaddress as well as the input data to send to a service and theformat of the expected output data from this service. For theexecution of human tasks, process execution engines typicallyprovide a front end to perform the work necessary to completethe task.

At the execution layer we define the technical details thatallow ESPTs to be mapped to IT components. The mappingmechanism has to take into consideration that events arrive in-definitely and are not known when the control flow reaches anESPT. Thus, the data input must be specified as a subscriptionfor desired events that arrive during the execution period of anESPT. During process execution, this subscription has to parti-tion the event stream in process instance specific sub streams:when a process instance is created for a certain business task,e.g., processing of Order No. 42, the event stream has to be

partitioned in sub streams of events relevant for the different or-der process instances. This requires events to hold an attributethat allows an association with a process instance. Monitoringevents contain, for example, a shipment ID. This is shown inFigure 15: a monitoring task must be active for each processinstance. This task instance has to receive all monitoring eventsfor the shipment that is handled in this process instance. Giventhat each event carries a shipment ID, each monitoring task in-stance can issue a subscription for the appropriate events usingthe shipment ID as filter. When the process instance ID corre-lates with the shipment ID, the subscription can also be derivedby the process execution engine on the basis of the process in-stance ID.

ShipmentID = 3

ShipmentID = 2

ShipmentID = 1 Shipment Monitoring

Event Stream

Shipment Monitoring1 Process Instance 1



Figure 15: Process execution: Event Stream Processing Tasks (ESPTs) receivesub streams of events

The subscription parameters are essential for the instantia-tion of an ESPT. Like the input data passed on to a service dur-ing a service call, the subscription is part of the input data dur-ing an ESPT instantiation. Further, when the ESPT is modeledwith an implicit completion, the completion condition is partof the input data required for the instantiation. As for ESPTcompletion, different ESPT instantiation strategies are possi-ble. The push-based nature of stream processing allows an im-plicit creation of ESPT instances upon the arrival of appropriateevents. In addition, ESPT instances can also be created explic-itly by the process execution engine. When switching from ex-plicit to implicit instantiation, the responsibility of instantiationmoves from the process execution engine to the IT infrastruc-ture. Implicit instantiation is useful when the moment of in-stantiation cannot be determined by the execution engine. It isalso the more natural approach with respect to the characteris-tics of event streams; application logic is executed as soon asappropriate events are available. We support both instantiationschemes to allow for a high flexibility (→ R8). Independent ofthe instantiation scheme, a subscription does not guarantee theavailability of events, e.g., that events for Shipment No. 42 arepublished. Explicitly instantiated ESPTs can use a timeout todetect such an absence of events. With implicit instantiation,ESPT instances are not created in this case; the execution envi-ronment can detect and report this.

3.2.1. ESPT InstantiationThe execution of a BP leads to process instances that may

run in parallel. Each ESPT in the model has correspondingESPT instances that are created during process execution. EachESPT instance processes the event streams relevant for a par-ticular process instance (see Figure 15). The process executionengine can create an ESPT instance explicitly during the exe-cution of a process instance. The subscription parameters re-quired for the explicit instantiation must be derived per process

10

instance; they define the sub stream of events that has to be pro-cessed by a particular ESPT instance, e.g., monitoring eventsfor Shipment No. 42. The explicit instantiation is specified asfollows (→ R6, R7, R8):

EsptInstantiate(EsptName, EventStreamFilter,SubStreamAttribute,SubStreamId [, CompletionCondition])

For the monitoring example, the explicit instantiation of a mon-itoring task for Shipment No. 42 without and with completioncondition is:

EsptInstantiate(MonitorShipment,MonitoringEvent,ShipmentId, 42)

EsptInstantiate(MonitorShipment,MonitoringEvent,ShipmentId, 42,"destination.equals(location)")

An ESPT is referenced by name: EsptName, e.g., MonitorShipment. The subscription parameter has three parts: First,a general filter for events of interest that applies to all instancesof an ESPT is specified as EventStreamFilter, e.g., mon-itoring events. Second, the SubStreamAttribute definesthe part of the event data that partitions the event stream withrespect to ESPT instances, e.g., the shipment ID; both are staticexpressions and derived based upon the ESS used in the model.Third, the SubStreamId defines the concrete event sub streamfor which an ESPT instance should be created, e.g., ShipmentNo. 42. The SubStreamId is dynamic and derived per pro-cess instance by the execution engine at run time, e.g., based onthe process instance ID. The optional CompletionConditioncan be specified for implicit completion, e.g., defining a timeout.

With implicit instantiation, the process execution engine onlyregisters a static subscription pattern for an ESPT once, e.g.,with the registration of the process. Since events arise in apush-style manner, the IT infrastructure is able to create ESPTinstances implicitly at run time. The implicit instantiation isspecified as follows (→ R6, R7, R8):

EsptRegister(EsptName, EventStreamFilter,SubStreamAttribute[, CompletionCondition])

For the shipment monitoring example, the ESPT registration is:

EsptRegister(MonitorShipment, MonitoringEvent,ShipmentId)

In contrast to explicit instantiation, the execution engine is notresponsible for the dynamic subscription part anymore. Rather,the IT infrastructure ensures, that an ESPT instance is createdfor each distinct value of the SubStreamAttribute, e.g.,for each shipment ID.

Upon implicit instantiation, the creation of ESPT instancesis not synchronized with the control flow of the process exe-cution. ESPT instances are created based upon the availabilityof events, i.e., as soon as events for a certain entity instance

are available the corresponding ESPT instance is created. Theavailability of events for Shipment No. 42, for example, resultsdirectly in the creation of an ESPT instance that processes theseevents. This happens independently of the control flow of theprocess execution. In cases where this behavior is not desired,a synchronization step has to be performed between the begin-ning of the actual event processing and the control flow of theprocess execution. Two cases have to be taken into consider-ation: First, the process control flow reaches an ESPT and noESPT instance has been created yet. Second, an ESPT instanceis created although the control flow has not reached the ESPT.

In the first case, the process execution blocks and proceedsafter the completion of an ESPT instance; this behavior is equiv-alent to the execution semantics of, e.g., service tasks. How-ever, the process execution engine has no control over the in-stantiation and thus relies on the IT infrastructure. In the secondcase, the already created ESPT instance has to wait for the con-trol flow of the process execution engine. This can be achievedby implementing a lock after the creation of an ESPT instance;this lock is released upon a dedicated signal from the processexecution engine. Since a dedicated signal from the processexecution engine is required, the explicit creation of ESPT in-stances is an alternative in such cases.

ESPTs with Output Event Streams. ESSs used as output of ES-PTs can be mapped to advertisements. Advertisements informthe IT infrastructure about the event types published by eventproducers; they allow the validation of subscriptions, i.e., whetherevents are potentially available for an issued subscription. Thevalidation of subscriptions allows the identification of inconsis-tencies between demand and availability of event streams uponregistration of ESPTs. The event types for the advertisementsare derived from output ESSs are included as additional param-eter at the instantiation or registration of ESPTs:

EsptInstantiate(EsptName, EventStreamFilter,SubStreamAttribute,SubStreamId [, CompletionCondition][, PublishedEventType])

EsptRegister(EsptName, EventStreamFilter,SubStreamAttribute [, CompletionCondition][, PublishedEventType])

A shipment monitoring SPU with implicit completion that out-puts threshold exceeded events (see Figure 11) is then registeredas follows:

EsptRegister(MonitorShipment, MonitoringEvent,ShipmentId,"destination.equals(location)",ThresholdExceededEvent)

When the report threshold violation SPU is registered, theIT infrastructure knows that the demanded threshold exceededevent type is available:

EsptRegister(ReportExceededThreshold,ThresholdExceededEvent,ShipmentId)

11

3.2.2. ESPT CompletionFor the explicit completion of an ESPT instance, the process

execution engine has to advise the IT infrastructure to perform ashutdown of particular ESPT instances, e.g., the shipment mon-itoring of Shipment No. 42. The completion command is spec-ified as follows (→ R8):

EsptComplete(EsptName,SubStreamId)

The SubStreamId identifies the ESPT instance that shouldbe completed. In the monitoring example for Shipment No. 42,the following completion command is issued after the arrivalconfirmation task:

EsptComplete(MonitorShipment,42)

We distinguish between the control commands to manageESPTs and the ESPT execution semantics. The control com-mands to register, instantiate, and complete ESPTs follow arequest/reply pattern. Thus, our integration approach of eventstreams with BPs can be mapped to web service invocations.Web service invocation capabilities are part of most process ex-ecution engines so that ESPTs can be registered, instantiated,or completed; the ESPT name as well as further subscriptionand completion parameters are specified as variables in the ser-vice invocation. In addition to service invocation mechanisms,it might be necessary to implement a back channel for controlflow purposes. Implicitly completing ESPT instances mighthave to notify the process execution engine about completion.This is the case when the control flow waits for a completionof an ESPT, e.g., when an ESPT is used before a BPMN AND-Join.

3.2.3. ESPT Mapping in BPELBusiness process models that contain ESPTs can be mapped

to BPEL. However, the BPEL standard [8] does not supportall concepts required for a complete mapping of the differentinstantiation and completion strategies. ESPTs with explicitinstantiation and explicit completion can be mapped to stan-dard BPEL: the explicit instantiation is realized as web ser-vice call. The return from this call is blocked by the IT in-frastructure until the ESPT instance is explicitly stopped by anEsptComplete service invocation. Explicit instantiation andcompletion in BPEL are as follows:

<invoke partnerLink="EsptWebService"operation="EsptInstantiate"inputVariable="explicitInstantiateParams"outputVariable="completed"/>

<invoke partnerLink="EsptWebService"operation="EsptComplete"inputVariable="explicitCompletionParams"/>

With implicit instantiation, single ESPT instances are trans-parent to the process execution engine. The registration of ES-PTs has to be performed once with the registration of a process;the ESPT instances are then created automatically. The BPELstandard does not support hooks for service invocation upon theregistration of new processes. Thus, a BPEL execution engine

has to be extended with these capabilities to support implicit in-stantiation of ESPTs. The hook for execution at process regis-tration can be part of the BPEL code itself; when a new processis registered and checked, this part of the process is executedonly once:

<atRegistration><invokepartnerLink="EsptWebService"operation="EsptRegister"inputVariable=

"implicitInstantiateParams"/></atRegistration>

When an ESPT is invoked implicitly, there is no BPEL webservice invocation in each process instance. Thus, a blockingservice invocation cannot be used to interrupt the control flowuntil completion of an ESPT instance. Rather, the process exe-cution engine has to be notified externally about the completionof an ESPT instance so that the control flow can proceed. Ex-tensions to BPEL engines to react on such external triggers havebeen proposed, e.g., in [21] and [22]. The ESPT can be mappedto a barrier that is released when the ESPT instance signals itscompletion.

3.3. IT Infrastructure Layer

SPUs require a technical representation at the IT infrastruc-ture layer. In [14] we present a suitable component model andruntime infrastructure to encapsulate event stream processing.We introduce event applets, in short Eventlets, as service-likeabstraction for event stream processing. Our model benefitsfrom concepts known from services; it hides application logicso that Eventlets represent business functions. We extend theruntime environment presented in [14] to allow for the integra-tion with BP execution engines. We now introduce the mainconcepts of Eventlets to make this paper self-contained; we thenpresent the extensions to the Eventlet middleware. We adapt themore general Eventlet nomenclature of [14] to fit the terminol-ogy of this paper.

<EventletName>

CompletionCondition: <Validity of Eventlet> EventStreamFilter: <Precondition for event handling> SubStreamAttribute: <Distinction criteria for Eventlet instances>

Eventlet Metadata

onInstantiation(subStreamId id) { ... } onRemove() { ... } onCompletion() { ... } onEvent(Event e) { ... }

Eventlet Runtime Code <InstanceID>

Figure 16: Eventlet structure: Eventlet metadata and Eventlet runtime methods

Eventlets encapsulate event stream processing logic with re-spect to a certain entity, e.g., shipments (→ R10). An Eventletinstance subscribes to events of a certain entity instance, e.g.,Shipment No. 42 (→ R11). The basic structure of an Event-let is shown in Figure 16. The grouping attribute to define thesub stream of events associated with a certain entity instance

12

is specified as Sub Stream Attribute2 in the Eventlet metadata,e.g., the shipment ID. Further, the metadata holds the Comple-tion Condition3, e.g., a timeout, as well as the Event StreamFilter4 as a general subscription filter applied by all Eventlet in-stances, e.g., monitoring event. Eventlet instances are createdimplicitly or explicitly (→ R9). With implicit instantiation themiddleware ensures that an Eventlet instance is active for eachdistinct value of the sub stream attribute, e.g., for each shipmentin transport. With explicit instantiation, Eventlet instances arecreated manually by specifying a concrete sub stream attributevalue, e.g., Shipment No. 42. The completion of Eventlet in-stances is triggered implicitly by the completion condition orexplicitly by a command (→ R9). Eventlet instances run ina distributed setting and have a managed lifecycle; applicationlogic can be executed upon instantiation, removal, completion,and upon event arrival (→ R11).

In our monitoring example, an Eventlet holds applicationlogic to detect temperature violations. This can involve a lookupin a database at instantiation to retrieve the temperature thresh-old for a certain shipment. It can also involve issuing complexevent processing (CEP) queries to rely on the functionality ofa CEP engine for temperature violation detection. An evalua-tion of CEP queries encapsulated in Eventlets is presented in[14]; we show that Eventlets can process a couple of thousandsevents per second while being scalable across machines. Thesemantics of ESPT execution (cf. Section 3.2) are implementedby the Eventlet middleware. The EsptInstantiate andEsptRegister invocations provide the Eventlet middlewarewith the metadata to explicitly or implicitly create Eventlet in-stances. For implicit instantiation, the middleware creates a so-called Eventlet Monitor; it analyzes the event stream and de-tects the need to create Eventlet instances as soon as events ofa new entity instance, e.g., a new shipment, occur. Like ser-vices, Eventlets are managed in a repository and identified viathe EsptName.

3.3.1. Eventlet Middleware ExtensionThe Eventlet middleware infrastructure uses the Java Mes-

sage Service (JMS) for event dissemination. JMS supports pub-lish/subscribe communication with event content sensitive sub-scriptions. Our implementation supports events in attribute-value and XML representation. For attribute-value events, theEvent Stream Filter is specified as JMS message selector in aSQL-like syntax. The Sub Stream Attribute is the name of anattribute, e.g., shipmentID. For XML events, Event Stream Fil-ter and Sub Stream Attribute are specified as XPath expressionson the event content. For implicit completion of Eventlet in-stances, timeouts are supported.

We extended the Eventlet middleware in [14] to supportESPT execution. As shown in Figure 17, the Eventlet middle-ware is configured and controlled using a command bus. Thiscommand bus is realized as a set of JMS queues and topics towhich all middleware components connect. We added a web

2Referred to as Instantiation Expression in [14].3Referred to as Validity Expression in [14].4Referred to as Static Expression in [14].

Business Process Execution (e.g., BPEL)

Eventlet Instances

Eventlet Repository

Eventlet Monitors

Command Bus

JMS Interface

WSDL/SOAP interface

Native Client

Eventlet Manager

Eventlet Middleware

Figure 17: Eventlet middleware access via web service

service interface to the Eventlet Manager. The new interfaceaccepts service invocations as described in Section 3.2 and usesthe internal command bus to start or stop Eventlet Monitors andEventlet instances. The web service interface is implementedas Java Enterprise application. The Eventlet middleware canbe deployed on multiple application servers and use a JMS in-frastructure in place. It is designed for scalability: Eventletinstances can run on arbitrary machines.

4. Implementation: Process Modeling and Execution

We implemented SPU modeling capabilities for EPCs andBPMN in Software AG’s ARIS platform. ARIS is a businessprocess platform for business process analysis, enterprise ar-chitecture, and governance, risk & compliance. ARIS supportsmodeling of processes with EPCs as well as with BPMN. Forour implementation we used ARIS Design Server 9.0 and theARIS Architect 9.0. To support SPU modeling in EPCs andBPMN within ARIS, we added new notation element symboltypes and connection attributes for EPCs (see Figure 3) andBPMN (see Figure 8) to the configuration of the ARIS server;the ARIS server acts as central repository for process modelsand process model components.

For EPCs we added symbol types for:

• a cluster/data model object (derived from cluster symboltype) to model ESSs;

• a service type object (derived from business service sym-bol type) to model ESPSs; and

• an application system type object (derived from softwareservice symbol type) to model the technical representa-tion of ESPSs.

For BPMN we added symbol types for:

• two cluster/data model types (derived from data input/out-put symbol types) to model ESSs;

• a function type object (derived from service task symboltype) to model ESPTs; and

• two event object types (derived from signal intermedi-ate event symbol type) to model SPU signal intermediateevents (throwing and non-interrupting) required for ex-plicit completion.

13

Further, we added an attribute type and an attribute type symbolfor BPMN to model the condition for implicit completion.

With the added symbol types, attribute symbol types, andattribute types it is possible to model SPUs and event streams inEPC and BPMN diagrams. All new modeling elements are us-able in different diagram types as the symbols they are derivedfrom. They can be used, for example, in application systemtype diagrams, all types of EPCs, function allocation diagrams,and service allocation diagrams.

Process Model ExecutionOne goal of BPM is to enable the automated execution of

business process models. In Section 2 we introduce the differ-ent layers in such a model-to-execute (M2E) process and showthat a high coherence across the process modeling layer, theprocess execution layer, and IT infrastructure layer is neces-sary. Our approach of SPUs is a mechanism to encapsulateevent stream processing to achieve such a high coherence andto provide the foundation for M2E.

Our extensions to EPCs allow business experts to create ab-stract BP models that contain SPUs; our extensions to BPMNalong with the proposed EPC-to-BPMN mapping allow the trans-formation of abstract EPC models to technical BPMN models.These BPMN models are further refined during the M2E pro-cess and brought to execution. The execution as such is detailedin Section 3.2 where the mapping between ESPTs and serviceinvocations is presented.

We are working with Software AG on the implementationof M2E mechanisms that support SPUs. In the following weillustrate the M2E workflow and show how SPU integration isachieved. Our M2E approach is based upon the Software AGARIS, CentraSite, and webMethods product suites. Businessprocess analysis and process modeling is supported by the ARISArchitect; it provides an integrated platform where process mod-els are created and governed collaboratively. At the beginningof the M2E workflow EPC process models are created with theARIS Architect; these models reflect an abstract business per-spective. In the next step a transformation process is applied;abstract EPC process models are mapped into a logical pro-cess model represented with BPMN. In ongoing work we areworking on the customization of the ARIS model transforma-tion framework, which performs the EPC-to-BPMN mapping.We are integrating the mapping of ESPSs in EPCs to ESPTsin BPMN. This allows a partly automated transformation fromEPC models with ESPSs to BPMN models.

After the transformation the resulting BPMN model needsto be refined by a process engineer. This involves the adapta-tion to technical concepts and restrictions, e.g., adapting eventsfor inter and intra process communication and error handlingscenarios. Finally, changed process elements are linked to therelated elements in the original EPC model using the processalignment capability of ARIS. This allows a synchronization ofthe process between abstract and technical layer; refinements inthe EPC model are applied - if possible automatically - to theBPMN model and vice versa.

The next step in the M2E workflow is the transition from atechnical model in ARIS to an executable process representa-

tion that is deployed to a process execution system. For SPUsthis involves linking the Eventlet middleware via its web ser-vice interface to ESPTs of the BPMN model (see Section 3.2).In Software AG’s M2E the executable process is created withthe Software AG Designer. Process developers import the tech-nical process model from ARIS in the Software AG Designer.In the Designer the process is represented as a technical BPMNdiagram and technical implementations are mapped to processsteps. This is supported by the Software AG CentraSite servicerepository: the web service interface of our Eventlet middle-ware is registered with CentraSite. This allows an easy assign-ment of the Eventlet service (including invocation parameters)to ESPTs in the model. Currently, only explicit instantiationand completion of SPUs is supported. Implicit instantiationwould require a service invocation at process registration, im-plicit completion would require a feedback mechanism from theEventlet middleware to the process execution environment.

Processes are synchronized between the webMethods plat-form and the ARIS platform. Changes to technical processesare propagated to the abstract process models and vice versa.During this round tripping, approval steps ensure that processesat the IT level and at the business level remain synchronized.The executable process model is deployed to the webMethodsIntegration Server where the individual process steps are exe-cuted by the different components of the webMethods BPMS;SPUs are executed by the Eventlet middleware controlled byweb service invocations from webMethods BPMS.

5. Related Work

Events are part of various BP modeling notations like BPMNand EPCs [7, 3, 4]; they trigger functions/tasks and influencethe process control flow. Event processing is often applied tomonitor process execution. Events can be detected by a pro-cess execution engine and depict, for example, activation/com-pletion of activities or sending/receiving of messages; eventscan also be defined implicitly based upon object state changes,e.g., changes in data records [23, 24]. Based upon such events,control flow deviations in single process instances can be de-tected [25]; it is also possible to check conformance in cross-organizational processes based upon message exchanges [26].In contrast, our approach focuses on event processing as partof single process instances. Such incorporation of (complex)events leads to more reactive and dynamic processes. This isa core concept in event-driven architectures (EDA) [27, 28] orevent-driven SOA [29]. However, event streams do not haveexplicit representations in BPMN or EPCs. Currently, eventstreams have to be modeled explicitly as multiple events, e.g.,using loops that process events. Such explicit modeling of com-plex events and event processing is for example presented in[30, 31, 32, 33, 34]. The problem is, that process models areoften created by business experts without detailed knowledgeabout technical details of event processing. Further, to makemodels intuitively understandable, modelers should use as fewelements as possible with self-explaining activity labels [16].Thus, activities should represent business functions. Servicesare a successful abstraction mechanism to support this. Services

14

represent business functions and exhibit a data input/output in-terface [6]. Process models do not (and should not) contain theapplication logic of a service; this is left to service developerswho can use more appropriate modeling notations to describethe technical details. Thus, the approach in this work confersbasic service concepts [35] to event stream processing and in-troduces SPUs as an appropriate abstraction. We concentrate oncontrol flow oriented business process models represented withBPMN and EPCs. However, the SPU concept is also applicableto alternative approaches for managing business operations andprocesses, e.g., the Guard-Stage-Milestone (GSM) approach,which allows for a more declarative modeling of business ac-tivities [36]. In GSM, SPUs can be represented by stages. In-stantiation is modeled as guards: a stage is activated when anevent stream becomes available (implicit instantiation guard)or when an event triggers the start of event stream processing(explicit instantiation guard). Completion is modeled as mile-stones: an implicit completion milestone holds the SPU com-pletion condition; and explicit completion milestone waits foran event published by other stages.

At the execution layer, Juric [22] presents extensions toBPEL that allow service invocations by events. In [37], Spiesset al. encapsulate event sources as services. Both approaches donot address event streams as input/output to/from components;rather than a stream of events, single events are understood asbusiness relevant.

At the technical layer, event streams are well-known. CEPis supported by a variety of tools, e.g., the Esper CEP engine[38]. CEP is also part of BP execution environments like JBossjBPM/Drools [39]. In [40], BP modeling techniques are usedto express CEP queries. Event stream processing is integratedbottom-up; CEP queries and rules are specified at the technicallayer. In contrast, we propose a top-down approach where busi-ness entity-centric event streams are visible as input/output ofESPTs at the modeling layer. Event streams can be as businessrelevant as, e.g., input/output data of services. Thus, like ser-vice task input/output is explicit in models, event streams areexplicit at the modeling layer in our approach.

The event stream processing application logic inside Eventletscan be simple rules, CEP queries, or complex event process-ing networks as described in [41]. Our middleware instantiatesEventlets for each entity instance, e.g., one CEP query is issuedper shipment. This encapsulation of event stream processinglogic is related to design by units described in [42]. It improvesscalability and fosters elasticity; in [14] we show the scalabil-ity benefits of CEP query encapsulation in Eventlets. The moreprocess instances require entity-centric stream processing, themore Eventlets are instantiated and vice versa.

6. Conclusion

In collaboration with Software AG, we developed SPUs toprovide an abstraction for event stream processing. The contri-butions of this paper are:

• SPUs as abstraction to encapsulate event stream process-ing as business functions;

• extensions of EPCs and BPMN 2.0 to model SPUs;

• a mapping of SPU-containing process models betweenEPCs and BPMN;

• a conversion of technical BPMN process models to anexecutable process representation;

• an extension of our Eventlet middleware to interface withBP execution engines; and

• an integration of our EPC and BPMN extensions in Soft-ware AG ARIS and in the Software AG model-to-executeworkflow.

We take semantics of event processing into account and supportimplicit as well as explicit instantiation and completion strate-gies. Event stream processing techniques, like CEP, are widelyadopted. Our approach encapsulates them and makes eventstream processing available coherently across the BP modeling,BP execution, and the IT infrastructure layer.

SPUs in general and ESPSs and ESPTs in particular depicttools that enable modeling event stream processing in BPs. De-veloping a comprehensive understanding and description of theresulting execution semantics, however, is challenging. SPUsissue subscriptions; but successfully issued subscriptions donot guarantee that demanded events are published. Further,BP models can describe complex situations, which require, forexample, transactional behavior. In such cases SPUs requirecompensation functionality to support rollbacks although eventproducers and consumers are logically decoupled.

SPUs enable the combination of push- and pull-based inter-actions within BPs. Thus, the interplay of push- and pull-basedcomponents in the context of large and complex processes isa topic of further investigation. Design and interaction patternsneed to be derived to better understand the resulting interdepen-dencies at the BP modeling, the BP execution, and the IT in-frastructure layer. Especially in cross-organizational processesaspects like data integration and quality of service at the IT in-frastructure layer require novel solutions. At the BP modelinglayer, meta-model extensions that describe SPUs are necessaryto provide a basis for interoperability.

In ongoing work we are enhancing the integration betweenthe process execution layer and the IT infrastructure layer; abackchannel needs to be incorporated to fully support implicitinstantiation and completion semantics. We are also enhancingour Eventlet middleware. We implement support for more typesof completion conditions and investigate complex expressionsas triggers for the instantiation of Eventlets. We are also work-ing on automated transformations between EPC process modelsand an executable process representation to support a seamlessM2E workflow. The implementation of our approach with Soft-ware AG’s ARIS and webMethods platforms is also the basisfor an evaluation of our approach in a real-world environmentto investigate how the modeling of event stream processing bymeans of SPUs is adopted.

15

AcknowledgementsWe thank Dr. Walter Waterfeld, Software AG, Germany, for the

valuable feedback and insights into process modeling practice. Thiswork is partly funded by: German Federal Ministry of Education andResearch (BMBF) under research grants 01IS12054 (Software Cam-pus), 01IC12S01V (SINNODIUM), and 01IC10S01 (EMERGENT);LOEWE Priority Program Dynamo PLV supported by the LOEWE re-search initiative of the state of Hesse/Germany. The authors assumeresponsibility for the content.

References

[1] S. Frischbier, M. Gesmann, D. Mayer, A. Roth, C. Webel, Emergenceas competitive advantage - engineering tomorrow’s enterprise softwaresystems, in: 14th International Conference on Enterprise InformationSystems (ICEIS), Poland, 2012.

[2] A. Buchmann, S. Appel, T. Freudenreich, S. Frischbier, P. E. Guerrero,From calls to events: Architecting future BPM systems, in: 10th In-ternational Conference on Business Process Managment (BPM), Estonia,2012.

[3] W. van der Aalst, Formalization and verification of event-driven processchains, Information and Software Technology 41 (1999) 639 – 650.

[4] Object Management Group (OMG), Business process model and notation(BPMN), version 2.0, 2011.

[5] S. Appel, S. Frischbier, T. Freudenreich, A. Buchmann, Event streamprocessing units in business processes, in: 11th International Conferenceon Business Process Management (BPM), China, 2013.

[6] M. Papazoglou, Service-oriented computing: concepts, characteristicsand directions, in: 4th International Conference on Web Information Sys-tems Engineering (WISE), Italy, 2003.

[7] G. Keller, A.-W. Scheer, M. Nuttgens, Semantische Prozeßmodellierungauf der Grundlage ”Ereignisgesteuerter Prozeßketten (EPK)”, Inst. furWirtschaftsinformatik, 1992.

[8] OASIS Web Services Business Process Execution Language (WSBPEL)TC, Web services business process execution language (BPEL), version2.0, 2007.

[9] C. Ouyang, M. Dumas, W. van der Aalst, A. ter Hofstede, J. Mendling,From business process models to process-oriented software systems,ACM Transactions on Software Engineering and Methodology 19 (2009)2:1–2:37.

[10] M. K. Chandy, O. Etzion, R. von Ammon, 10201 executive summary andmanifesto – event processing, in: Event Processing, number 10201 inDagstuhl Seminar Proceedings, Schloss Dagstuhl - Leibniz-Zentrum furInformatik, Germany, 2011.

[11] A. Meyer, S. Smirnov, M. Weske, Data in business processes, EMISAForum 31 (2011) 5–31.

[12] J. Becker, M. Rosemann, C. Uthmann, Guidelines of business processmodeling, in: W. Aalst, J. Desel, A. Oberweis (Eds.), Business Pro-cess Management, volume 1806 of Lecture Notes in Computer Science,Springer, 2000, pp. 30–49.

[13] P. Eugster, P. Felber, R. Guerraoui, A.-M. Kermarrec, The many facesof publish/subscribe, ACM Computing Surveys (CSUR) 35 (2003) 114–131.

[14] S. Appel, S. Frischbier, T. Freudenreich, A. Buchmann, Eventlets: Com-ponents for the integration of event streams with SOA, in: 5th IEEE In-ternational Conference on Service-Oriented Computing and Applications(SOCA), Taiwan, 2012.

[15] M. P. Papazoglou, P. Traverso, S. Dustdar, F. Leymann, Service-orientedcomputing: State of the art and research challenges, IEEE ComputerJournal 40 (2007) 38–45.

[16] J. Mendling, H. Reijers, W. van der Aalst, Seven process modeling guide-lines (7pmg), Information and Software Technology 52 (2010) 127 – 136.

[17] J. Miller, J. Mukerji, MDA Guide, Version 1.0.1, 2003.[18] A.-W. Scheer, M. Nuttgens, ARIS Architecture and Reference Models

for Business Process Management, in: W. Aalst, J. Desel, A. Oberweis(Eds.), Business Process Management, volume 1806 of Lecture Notes inComputer Science, Springer, 2000, pp. 376–389.

[19] S. Stein, Modelling Method Extension for Service-Oriented Business Pro-cess Management, Ph.D. thesis, Christian-Albrechts-Universitat zu Kiel,Kiel, Germany, 2009.

[20] V. Hoyer, E. Bucherer, F. Schnabel, Collaborative e-business processmodelling: Transforming private EPC to public BPMN business processmodels, in: 5th International Conference on Business Process Manage-ment (BPM) Workshops, Australia, 2007.

[21] R. Khalaf, D. Karastoyanova, F. Leymann, Pluggable framework for en-abling the execution of extended BPEL behavior, in: International Con-ference on Service Oriented Computing (ICSOC) Workshops, Austria,2007.

[22] M. B. Juric, WSDL and BPEL extensions for event driven architecture,Information and Software Technology 52 (2010) 1023–1043.

[23] N. Herzberg, A. Meyer, O. Khovalko, M. Weske, Improving business pro-cess intelligence with object state transition events, in: 32nd InternationalConference on Conceptual Modeling (ER), China, 2013.

[24] N. Herzberg, A. Meyer, M. Weske, An event processing platform for busi-ness process management, in: 17th International Enterprise DistributedObject Computing Conference (EDOC), Canada, 2013.

[25] M. Weidlich, H. Ziekow, J. Mendling, O. Gunther, M. Weske, N. Desai,Event-based monitoring of process execution violations, in: 9th Inter-national Conference on Business Process Management (BPM), France,2011.

[26] A. Baouab, O. Perrin, C. Godart, An optimized derivation of event queriesto monitor choreography violations, in: 10th International ConferenceService-Oriented Computing (ICSOC), China, 2012.

[27] P. Chakravarty, M. Singh, Incorporating events into cross-organizationalbusiness processes, IEEE Internet Computing 12 (2008) 46 –53.

[28] B. M. Michelson, Event-driven architecture overview, Patricia SeyboldGroup (2006).

[29] O. Levina, V. Stantchev, Realizing event-driven SOA, in: 4th Interna-tional Conference on Internet and Web Applications and Services (ICIW),Italy, 2009.

[30] A. Barros, G. Decker, A. Grosskopf, Complex events in business pro-cesses, in: 10th International Conference on Business Information Sys-tems (BIS), Poland, 2007.

[31] B. Biornstad, C. Pautasso, G. Alonso, Control the flow: How to safelycompose streaming services into business processes, in: IEEE Interna-tional Conference on Services Computing (SCC), USA, 2006.

[32] A. Caracas, T. Kramp, On the expressiveness of BPMN for modelingwireless sensor networks applications, in: 3rd International Workshop onBusiness Process Model and Notation (BPMN), Switzerland, 2011.

[33] A. Estruch, J. Heredia Alvaro, Event-driven manufacturing process man-agement approach, in: 10th International Conference on Business ProcessManagment (BPM), Estonia, 2012.

[34] M. Wieland, D. Martin, O. Kopp, F. Leymann, SOEDA: A method forspecification and implementation of applications on a service-orientedevent-driven architecture, in: 12th International Conference on BusinessInformation Systems (BIS), Poland, 2009.

[35] A. Elfatatry, Dealing with change: components versus services, Commu-nications of the ACM 50 (2007) 35–39.

[36] R. Hull, E. Damaggio, F. Fournier, M. Gupta, F. T. Heath III, S. Hobson,M. Linehan, S. Maradugu, A. Nigam, P. Sukaviriya, R. Vaculin, Intro-ducing the guard-stage-milestone approach for specifying business entitylifecycles, in: 7th International Workshop on Web Services and FormalMethods (WS-FM), USA, 2010.

[37] P. Spiess, S. Karnouskos, D. Guinard, D. Savio, O. Baecker, L. Souza,V. Trifa, SOA-based integration of the internet of things in enterpriseservices, in: IEEE International Conference on Web Services (ICWS,USA, 2009.

[38] EsperTech Inc., Esper Complex Event Processing Engine, 2013.[39] JBoss.com, Drools - The Business Logic integration Platform, 2013.[40] S. Kunz, T. Fickinger, J. Prescher, K. Spengler, Managing complex event

processes with business process modeling notation, in: 2nd InternationalWorkshop on Business Process Model and Notation (BPMN), Germany,2010.

[41] O. Etzion, P. Niblett, Event processing in action, Manning PublicationsCo., 2010.

[42] S. Tai, P. Leitner, S. Dustdar, Design by units: Abstractions for humanand compute resources for elastic systems, IEEE Internet Computing 16(2012) 84 –88.

16

modeling and execution of event stream processing in ... · epc and bpmn extensions to model spus...

Documents