Abstract. In this article we describe how Complex Event Processing (CEP) can be smoothly integrated into Subject-oriented Business Process Management (S-BPM). This approach is grounded on communication patterns between acting systems (i.e. subjects), such as people and software systems. The integration is done twofold. Firstly, complex event processing units can be seen as one way to instantiate a process. Secondly, CEP units can be integrated into subjects as internal functions. Based on evaluating various data patterns the subject containing the CEP function can inform other subjects by sending corresponding messages. In this way, nondeterministic (since not predictable) events can be dealt with at runtime. An informed subject may actively influence further system behavior by delegating further observation tasks to the subject containing the complex event processing unit. Based on the introduced concepts and their straightforward implementation actual business operations can not only be represented, but also processed more accurately.

1. Nondeterministic Events in Business Processes
Albert Fleischmann1, Werner Schmidt2, Christian Stary3, Florian Strecker1
1
Metasonic AG, Münchner Str. 29, 85276 Hettenshausen, Germany
Albert.Fleischmann | Florian.Strecker@metasonic.de
2
Ingolstadt University of Applied Sciences, Esplanade 10, 85049 Ingolstadt, Germany
werner.schmidt@haw-ingolstadt.de
3
Johannes Kepler University Linz, Freistädterstraße 315, 4040 Linz, Austria
Christian.stary@jku.at
Abstract. In this article we describe how Complex Event Processing (CEP) can
be smoothly integrated into Subject-oriented Business Process Management (S-
BPM). This approach is grounded on communication patterns between acting
systems (i.e. subjects), such as people and software systems. The integration is
done twofold. Firstly, complex event processing units can be seen as one way to
instantiate a process. Secondly, CEP units can be integrated into subjects as
internal functions. Based on evaluating various data patterns the subject
containing the CEP function can inform other subjects by sending
corresponding messages. In this way, nondeterministic (since not predictable)
events can be dealt with at runtime. An informed subject may actively influence
further system behavior by delegating further observation tasks to the subject
containing the complex event processing unit. Based on the introduced concepts
and their straightforward implementation actual business operations can not
only be represented, but also processed more accurately.
Keywords: events, message guard, implementation, CEP, S-BPM
1 Introduction
In this paper we describe how the specification of business processes and event
processing can be combined in order to handle deterministic and non deterministic
business situations. Additionally we will show how such specifications with non
deterministic events can be implemented in a straight forward way.
Business processes are the behavioral parts of organizations. Business process
specifications describe which event causes the instantiation of a business process,
which parties in a process execute which activities, using which tools and which
communication acts they perform in order to synchronize work in a world with a high
degree of division of work. Business processes can be instantiated for various reasons
and must be able to handle deterministic and nondeterministic events during its
execution. Deterministic events are those which occurrence in time can be specified
accurately, i.e. it is known that they will occur and when they will occur. In case of
nondeterministic events it is not known whether they occur at all and in case of
occurrence when they actually occur.
In this paper events are considered to be messages sent from a sender to a receiver.
Messages may transport some data from the sender to the receiver. In Business
Process Management (BPM) we distinguish between events which cause the creation
of a process instance and events which are created during the execution of a process
instance.

2. 2 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.
Events which cause process instances
Depending on the source of an event which causes a new process instance we
distinguish we four types:
 Human actor interference
A human initiates the execution of a process. For example somebody calls a
service center because he/she has problems with a certain device. The service
center creates a process instance of a process which handles such incident
calls.
 Time
An instance of a process must be created regularly in order to produce certain
results which are required by various people. Every day in the evening a
process is executed which collects data from several service organizations,
creates a report and distributes that report to several employees interested in
that report.
 Other business processes
An instance of a business processes triggers the instantiation of another
business process. A sales process causes the instantiation of a corresponding
production process if a customer accepts an order.
 Data state
If certain conditions become valid in some data storage a process instance is
instantiated. An observer realizes that a defined condition becomes true and
creates an instance of a process which handles that situation. Data changes
can be caused by human interactions or software programs like complex event
filters. A complex event processing unit discovers a certain constellation in the
external event stream which has to be handled by a business process. The filter
triggers the instantiation of the corresponding business process (see [4]).
Events which are created during process instance execution
Process instances created for certain reasons are executed according to the process
specification. During process execution several deterministic and nondeterministic
communications (events) can occur. For deterministic communication it is defined
when and by whom they are sent and how the receiver reacts. Non deterministic
events are messages randomly sent from parties in a process. We call these types of
messages process instance execution events or, for short, internal process events. An
example of such an internal event can be a cancelation message. A customer informs
the service center that he could solve the problem by his own and the incident ticket
can be closed.
During the execution for those events it is unclear whether they occur at all, and if
so, when they occur. Reactions differ depending on the state the process instance is in
by the time the event occurs.
Process models are templates for creating and executing process instances. Thus a
model not only needs to describe the sequence of activities being executed and the
messages being sent and received with regard to deterministic events. The challenge
is to also include internal events into the model and have them handled at runtime.
In this article we show how internal events can be easily integrated in subject-
oriented business process models. After this introduction we shed some light on
related work regarding event handling in business process management. After that we
briefly introduce Subject-oriented Business Process Management (S-BPM) and
discuss the integration of Complex Event Processing (CEP) into S-BPM. Complex
events are built out of lots of simple events which as a group serve as an element in a
specific situation for a particular purpose [17]. We will show how complex event

3. Nondeterministic Events in Business Processes 3
processing units can be integrated into subject-oriented process specifications. Our
goal is to integrate complex event processing at process instance execution rather than
on the process instance creation level. This approach better matches actual business
operation which is characterized by nondeterministic events, e.g. the change of an
order or purchases stocks if certain prices are reached. Chapter 4 presents the concept
and a prototype implementation of the message guard concept in S-BPM, suitable to
handle process instance execution events. We end with the conclusion in chapter 5.
2 Challenges to Capture Nondeterministic Events in BPM
Being able to flexibly react on unforeseen events when executing business processes
is both a constraint and a valuable asset for an agile organization. We look at the way
how state-of-the-art approaches to business process modeling and execution cope
with the representation and execution of event-driven actions.
2.1 Event-driven Process Chains (EPC)
The flow-oriented EPCs are the major model type of the control view in the ARIS
methodology of business process modeling. Per definition, events drive the control
flow, but the possibility to model events is limited to deterministic ones. The method
does not offer concepts to handle asynchronous, nondeterministic events as mentioned
in section 1. As a consequence those events are not considered when EPCs are
transferred to executable code during IT implementation.
2.2 Business Process Model and Notation (BPMN)
BPMN 2.0 includes ‘catching events’ (trigger has fired) and ‘throwing events’ (event
fires) as flow elements in the description of a process. Those events can be of various
type (e.g. message event, timer event, signal event, terminate event, cancel event),
each represented by a dedicated symbol [13, 14, 19].
Nondeterministic events can be modeled as so-called exceptions. They can be used
to interrupt a running sub process. The overall process is then continued on the higher
level of the calling process. It is not clearly defined who can be the source of such an
exception and it is difficult to describe the way back to the interrupted process after
the exception was handled.
If, for example, a customer changes an order the change request message (e.g.
increasing the number of products ordered) can arrive in any execution state on the
seller side of the order process. This means the seller must be able to react to it at
many different points in a suitable way. If the message arrives before picking and
packing the goods the reaction can just be changing the number and continuing the
process instance in the state where the change request had arrived. In case delivery
has already been started the reaction might be to create a new instance with the
missing number of goods causing a second delivery. BPMN 2.0 falls short in clear
semantics to precisely express such situations as well as the message exchange [18]. It
is limited in its expressiveness for conditional event-driven reaction logic [20] and
does not offer possibilities to integrate facilities which are able to handle process
external event patterns (see p. 376 in [4]). In order to generally tackle BPMN 2.0
shortcomings, some additional definitions beyond the standard are necessary, like
proposed by Silver [19].

4. 4 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.
2.3 Event-driven Business Process Management (ED-BPM)
Event-Driven Business Process Management (ED-BPM) combines two different
disciplines: Business Process Management (BPM) and Complex Event Processing
(CEP) [4, 5, 17]. Basic idea is that single events occurring in an event cloud are
processed (mainly filtered) by an event processing platform and thus aggregated into
a complex event [14, 15], which can be modeled in a process execution language of a
BPMS triggering changes in the runtime behavior of a process. This view brings
together the abstract description of processes at design time with unforeseen events
(i.e. nondeterministic) affecting the execution of process instances during runtime.
Von Ammon et al. suggest a general framework for ED-BPM and discuss how
business process execution can be enhanced on the basis of ED-BPM, e.g. by
enhancing WS-BPEL, which in its “standard form cannot execute event-driven
processes” [4].
Paschke also mentions the limits of pure syntactic BPM languages like BPEL and
BPMN in the context of ‘complex decision logic and conditional event-driven
reaction logic’ [20]. For orchestration of business processes he proposes a declarative
middleware based on rules and events and combining CEP technologies with those
for declarative rule-based programming [22].
The CEVICHE framework presented by Hermosillo et al. [23] combines an XML-
based Standard Business Process Language (SBPL) with an aspect-oriented extension
to BPEL (AO4BPEL). The first allows to translate process information to different
CEP engines, the ladder makes it possible to adapt the process behavior at runtime
without redeploying the whole model before.
3 Subject-oriented Business Process Management
3.1 Fundamentals
The S-BPM approach roots in the observation that humans usually use standard
semantics of natural language with subject, predicate, and object when they describe
what they are doing in a business process. Consequently the S-BPM modeling
language allows for representing these building blocks of a complete sentence in
natural language, where the subject is the starting point for describing a situation or a
sequence of events, the activities are denoted by predicates and an object is the target
of an activity. Resulting models describe structural properties and behavioral
alternatives, including the message-based interaction occurring in the technical and/or
organizational environment. Thus S-BPM enriches flow concepts of function-driven
BPM approaches by active entities sending and receiving messages [1, 6, 8]. These
active entities are called subjects. In order to keep a process specification independent
from a special organizational and technical environment subjects are a more abstract
view on active entities than actors or agents. A subject abstractly models an
agent which executes some specified behavior; for example a subject can stand for a
person acting in a given situation (process) or for a thread in an IT system (software
agent). A concrete agent (when acting) instantiates (the behavior of) a subject. Thus
one agent may be able to execute the behavior of different subjects and vice versa
different agents may execute the same behavior, as defined by one subject. These
different executions are independent of each other. Assigning an actor or agent to a
subject is part of the implementation of a subject.
The graphical notation of the S-BPM modeling language with only a few symbols
is based on process algebra with a clear formal semantic allowing automated code
generation. This makes subject-oriented process descriptions executable and supports
seamless round-trip engineering [1, 8].

5. Nondeterministic Events in Business Processes 5
Using the Abstract State Machine (ASM) method Egon Börger [16] developed a
precise formulation for the semantics of the S-BPM constructs in form of a high-level
subject-oriented interpreter model and gave proof both of ground model and
refinement correctness of the interpreter (for details see [2] and pp. 346-395 in [1]).
3.2 Modeling
In order to demonstrate the mapping of a language-based representation to a subject-
oriented model we use the application for a business trip as a simple example. Figure
1 shows the natural language description of this process.
An employee applies for a business trip. His manager checks the request and
informs the employee whether he approves or rejects the request. The approved
request is forwarded to the travel office which does all the travel arrangements.
Fig. 1. Natural language description of the business trip application process
The subject-oriented description of the process starts with the identification of
process-specific roles involved in the process, the subjects, and the messages
exchanged between them. When sending messages, the required data is transmitted
from the sender to the receiver via simple parameters or more complex business
objects if necessary. Thus, with the message ‘business trip request’ sent by the
employee to the supervisor, among other things, the start and end date are transmitted.
Figure 2 depicts the interaction structure of the process, the so-called Subject
Interaction Diagram.
Fig. 2 The business trip application process with the involved subjects and their interactions
In a further refinement step, the modeler describes which activities and interactions
the subjects have to perform in which order during the execution of the process, i.e.,
he defines the behavior of individual subjects.
The so-called Subject Behavior Diagram in figure 3 shows the order in which the
employee sends and receives messages, or executes internal actions, and the states he
is in during his business trip application.

6. 6 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.
Fig. 3 Graphical representation of employee behavior when applying for a business trip
The initial state is marked by a triangle in the upper left corner. It is a function state
in which the employees complete their business trip request. The state transition
'filled out Bt-request' leads to a send state in which they send the application to the
manager, before entering the receive state, in which an answer is received from the
manager. Here, the applicants wait for the response of the manager. In case they
receive a rejection message from the manager, the process comes to an end. In case
the employees receive the approval message from the manager, they go on the trip on
the agreed date and the business trip application process is completed.
The behavior of the manager is complementary to that of the employee (see figure
4). Messages sent by the employee are received by the manager, and vice versa. The
manager therefore first waits in a receiving state for a business trip request from the
employee. After receiving the application, he goes to a state of checking which leads
either to the approval or rejection of the request. In the second case, a send state
follows to send the refusal to the employee. In the first case, the manager first moves
to a send state for transmitting the approval to the applicant, and then proceeds to a
state of informing the travel office about the approved business trip request.
Fig. 4. Graphical representation of the manager’s behavior when handling a business trip request
The behavior of the travel office can be described analogous. This short example
illustrates the essential elements of a subject-oriented model as there are:
 The subjects involved in the process,
 The interactions taking place between them,

7. Nondeterministic Events in Business Processes 7
 The messages they send or receive during each interaction, and
 The behavior of the individual subjects
3.3 Integrating Complex Event Processing (CEP) in S-BPM
In the CEP context an event processing agent (EPA) denotes a unit processing
complex events [15, 17]. As in S-BPM we distinguish between abstract subjects and
actors/agents (see section 3.1) we need a term for a more abstract view on complex
event processing in the subject-oriented context. We introduce the event processing
functionality (EPF), which becomes an event processing agent as defined in [15] and
[17] once the functions are assigned to an entity (software, people etc.) able to
perform them. This means we want to consider event processing functionality
independent from the executing ‘technology’.
Complex Event Processing can be easily integrated in S-BPM in a twofold manner:
Complex event functionality triggers process instances. It observes the incoming
events in the event cloud. When it discovers a defined constellation a corresponding
business process instance is created to handle that constellation.
Complex event processing is part of processes. Event processing functionality can
be considered as functions in the behavior of a subject and if the subject is assigned to
an agent we have an EPA. As soon as a process is instantiated this agent is also
instantiated and can start working. When a predefined event pattern is discovered the
internal function of the related exit transition is executed. Due to the fact that the
modeler can define several exits for each internal function, this function can search
for different patterns. The following figure shows a subject with event processing
functionality.
Fig. 5. A subject with event processing functionality
The subject receives a message ‘start_watching_stocks’. After accepting that
message the subject is in state ‘watch_stock_exchange’. If ‘Stock price low’ is
discovered the corresponding transition is executed and in the following send state the
message ‘buy_stocks’ is sent to the subject ‘trader’. If the result ‘stock price high’ is
discovered the corresponding message is sent. With these messages the corresponding
buy or sell processes are started. After that the subject can do some other work
depending on the behavior specification.
As the function discovers events it passes the information on to other subjects in
the process which handle the activities to be accomplished because of an event. This
type of events (i.e. messages) is nondeterministic. It is unclear whether the message is
sent and when it will be sent. Other subjects can also send messages to the event

8. 8 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.
processor subject containing information which constellations should be observed (in
our example in the message ‘start event processing’) in order to make the complex
event function change its observation conditions. This means subjects must be able to
handle nondeterministic messages.
In the following chapter we present the Message Guard concept which details the
aforementioned possibilities S-BPM provides to handle asynchronous, nondeter-
ministic events.
4 Message Guard Concept in S-BPM
4.1 Specification
We use the term Message Guard as a synonym for handling an exception. It is a
behavioral description for a subject that is relevant when a specific, exceptional
situation occurs along executing a subject behavior specification. It is activated when
a corresponding message is received, and the subject is in a state being able to
respond to exception handling (see p. 147 ff. in [1]). In such a case, the transition to
exception handling has the highest priority and will be enforced.
Exception handling can occur in a process in many behavior states of subjects. The
receipt of certain messages, e.g., to abort the process, always results in the same
processing pattern. This pattern should also be modeled for each state in which it is
relevant. Exception handlings cause high modeling effort and lead to complex process
models, since from each affected state a corresponding transition has to be specified.
In order to prevent this situation, we introduce a concept similar to exception handling
in programming languages or interrupt handling in operating systems.
To illustrate the compact description of exception handlings, we enhance our
business trip example by introducing an additional subject ‘Service desk’. This
subject identifies a need for a business trip in the context of solving a customer
problem - an employee needs to visit the customer to provide a service locally.
According to the subject interaction diagram in figure 6 the subject ‘Service desk’
passes on a service order to an employee. Hence, the employee issues a business trip
request. The service order may be canceled up to its completion in principle at each
stage of processing. The cancelation message is passed on to all affected subjects to
bring the process towards a defined end.
Fig. 6. Subject interaction diagram of the business trip application process including
cancelation messages
As for the behavior we first describe what the model would look like without
applying the message guard concept of exception handling. A cancelation message
can be received by the employee either while filling in the application, or while
waiting for the approval or rejection message from the manager. With respect to the
behavior of the subject ‘employee’, the state ‘response received from manager’ needs
to be enriched with the possible input message containing the cancelation and the
associated consequences, too. The verification whether filling in the request is
followed by a cancelation is modeled through a receive state with a timeout. In case
the timeout is zero, there is no cancelation message in the input pool and the business
trip request is sent to the manager (for details of the input pool and timeout concept

9. Nondeterministic Events in Business Processes 9
(see p. 96 ff. in [1]). In the other case, the manager is informed of the cancelation and
the process terminates for the subject ‘employee’. A corresponding adjustment of the
behavior needs to be made for each subject, which can receive a cancelation message,
including the manager and the travel office.
This relatively simple example already shows that paying attention to such
exception messages can quickly make behavior descriptions extensive and confusing
to understand. The concept of exception handling, therefore, should enable supple-
menting exceptions to the default behavior of subjects in a structured and compact
form. Figure 7 shows how such a concept affects the behavior of the employee.
Fig. 7. Behavior of subject ‘employee’ with exception handling
Instead of modeling receive states with a time-out zero and corresponding state
transitions, the behavioral description is enriched with the exception handling ‘service
cancelation’. Its initial state is labeled with the states from which is branched to, once
the message ‘service cancelation’ is received. In the example, these are the states
‘business trip application complete’ and ‘receive answer from manager’. Each of
them is marked by a triangle on the right edge of the state symbol. The exception
behavior leads to an exit of the subject, after the message ‘service cancelation’ has
been sent to the subject ‘manager’.
Basically, a subject behavior does not need to stop here; it may be continued from
there as specified in some default behavior. Exception handling behavior in a subject
may vary, depending from which state or by what type of message (cancelation,
temporary stopping of the process, etc.) it is called. The initial state of exception
handling can be a receive state or a function state.
Messages that, like ‘service cancelation’, lead to exception handling always have
higher priority than other messages. Thus, modelers express that specific messages
are read in a preferred way. For instance, when the approval message from the
manager and shortly thereafter the cancelation message are received in the input pool
of the employee, the latter is read first. It causes corresponding abort consequences.
4.2 Implementation
Sections 3.2 and 4.1 demonstrated the concepts S-BPM offers to model nondeter-
ministic events in a transparent and efficient way. To have functions based on these

10. 10 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.
concepts available in a Business Process Management System (BPMS), extensions
are necessary in the design part and in the execution part of a tool suite supporting the
S-BPM approach.
Strecker presents a prototype solution enhancing the Metasonic Suite as a BPMS
by functionality allowing to model exception handling according to the message
guard concept and to perform the modeled behavior at runtime [3].
4.2.1 Extension for Modeling and Execution
Although Metasonic’s modeling environment ‘Metasonic Build’ is Eclipse-based and
can therefore easily being adapted or extended, Strecker did not alter the core of the
BPMS, but used out-of-the-box possibilities like modeling conventions (e.g. different,
multi-colored symbols) and existing custom modeling parameters [10] for his quick
and easy prototype implementation.
Figure 8 depicts how a message guard behavior is modeled with the mentioned
means:
 The message guard behavior is placed to the right of the standard behavior.
 The complete message guard behavior is shimmed with a light-blue box and
marked as “message guard behavior” with a text box.
 The start of the message guard behavior is a receive state; therefore, it is possible
to distinguish different messages there.
 The start of the message guard behavior is marked with a blue triangle on its top.
 In the standard behavior, all states which can be left to access the message guard
behavior, are marked with a dark-blue triangle on their upper right corner.
Fig. 8. A subject behavior employing a message guard behavior
The process engine ‘Flow’ as a part of the Metasonic Suite allows creating custom
extensions to enhance the runtime environment via so-called engine add-ons [10].
These extensions can react to certain, well-defined events, and are implemented using
the so-called observer pattern [11].
As we defined events as incoming messages an InputpoolObserver is needed to
react to message entries in the subject’s input pool. The StateChangeObserver is
applied for handling the message guard behavior. It checks the process model for

11. Nondeterministic Events in Business Processes 11
custom modeling parameters described in the previous section and reacts on the
parameter values as events. A certain parameter constellation for example can make
the observer switch a subject state and thus altering the subject behavior at runtime.
The implementation including some examples can be downloaded at [12].
5 Conclusion and Future Work
Business Process Management (BPM) recognizing complex events requires
corresponding representation and execution schemes, as those events reflect in situ
business settings and organizational behavior patterns. In particular, events that are
uncertain with respect to their occurrence and their time of occurrence, so called
nondeterministic events, require proper management at runtime. Approaches to
embed Complex Event Processing (CEP) into BPM neither support specification of
handling nondeterministic events, e.g., BPMN, nor reflect dynamic handling of those
events, e.g., EPC.
In this contribution we have introduced how CEP can be integrated into Subject-
oriented Business Process Management (S-BPM). In contrast to existing functional
approaches it is grounded on communication patterns between acting systems (i.e.
subjects). We started integration by considering CEP units as one way to instantiate a
process, i.e. creating a process instance. CEP units can then be integrated into subjects
as internal functions. At run time (process instance execution), based on evaluating
various data patterns the subject containing the CEP function can inform other
subjects by sending corresponding messages. This represents the basic concept for the
handling of nondeterministic events.
The informed subjects may then delegate further observation tasks to the subject
containing the CEP unit. In this way they dynamically influence the system behavior.
The prototype implementation provides the proof of concept. We have used the
message guard concept for straightforward implementation.
Future work should include detailing and evaluating the concept as well as the
prototype implementation, e.g. in terms of relating it to the standard event processing
architecture introduced by [17] or in terms of interaction with existing CEP solutions.
Questions still to be answered also refer to performance, limitations and a comparison
with existing approaches like mentioned in section 2.3.
References
1. Fleischmann, A., Schmidt, W., Stary, C., Obermeier, S., Börger, E.: Subjektorien-
tiertes Prozessmanagement, Hanser, München (2011), to appear in English at
Springer, Berlin Heidelberg in October 2012
2. Börger, E., The Subject-Oriented Approach to Software Design and the Abstract
State Machines Method, in: Düsterhöft, A., Klettke, M., Schewe, K.-D. (eds.),
Conceptual Modeling and its Theoretical Foundations, LNCS 7260, pp. 52-72,
Springer, Berlin Heidelberg (2012)
3. Strecker F.: New Modeling Concepts in S-BPM: The First Implementation of the
‘Message Guard’ and ‘Macro’ Behaviour Extensions in: Oppl, S. and
Fleischmann, A. (eds.), S-BPM ONE 2012, CCIS 284, pp. 121-134, Springer,
Berlin Heidelberg (2012)
4. von Ammon, R. Ertlmaier, T., Etzion, O., Kofman, A., Paulus, T.: Integrating
Complex Events for Collaborating and Dynamically Changing Business
Processes in: Dan, A., Gittler, F. and Toumani, F. (Eds.): ICSOC/ServiceWave
2009, LNCS 6275, pp. 370–384, Springer, Berlin Heidelberg (2010)

12. 12 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.
5. von Ammon, R., Etzion, O., Paschke, A., Stojanovic, N., Event-Driven Business
Process Management, in: ED-BPM Workshop, ServiceWave 2008, Madrid,
http://www.nessi-europe.com/Nessi/adminP/ArchivedPages/ServiceWave
2008Workshop BPM/tabid/468/Default.aspx, last access 2011-04-16 (2008)
6. Fleischmann, A., Stary, C.: Whom to talk to? A stakeholder perspective on
business process development, Universal Access in the Information Society, DOI
10.1007/s10209-011-0236-x (2011)
7. Weber, J., Schmidt, W., Weber, P., Using Social Network Analysis and
Derivatives to Develop the S-BPM Approach and Community of Practice, in:
Stary, C. (Ed.), S-BPM ONE 2012, LNBIP 104, pp. 205-217, Springer, Berlin
Heidelberg (2012)
8. Fleischmann, A., Schmidt, W., Stary, C., A Primer to Subject-oriented Business
Process Modeling, in: Stary, C. (Ed.), S-BPM ONE 2012, LNBIP 104, pp. 218-
239, Springer-Verlag, Berlin Heidelberg (2012)
9. Stary, C., Fleischmann, A.: Key Features of Subject-Oriented Modeling and
Organizational Deployment Tools, in: Stephanidis, C. (Ed.), HCII 2011, LNCS
6768, pp. 205–214, Springer, Berlin Heidelberg (2011)
10. Metasonic AG: Metasonic Suite Developer Documentation 4.4. http://www.
metasonic.de, Pfaffenhofen (2011)
11. Metasonic AG: ExecutionOrderWithinRefinementsAndObservers (com.jcom1.
documentation.refinements.ExecutionOrderWithinRefinementsAndObservers).
In: Metasonic AG: Metasonic Suite Developer Documentation 4.4. http://www.
metasonic.de, Pfaffenhofen (2011)
12. Strecker, Florian: http://www.floooooo.de/s-bpm/#sbpmone2012.
13. OMG, Business Process Management Initiative, BPMN, http://www.omg.org/
spec/BPMN/2.0/PDF/, last access 2012-05-26.
14. Freund, J., Rücker, B.: Praxishandbuch BPMN 2.0, Hanser, München (2010)
15. Luckham, D., Schulte, R. (Hrsg.), Event Processing Glossary Version 2.0/2011,
Event Processing Technical Society, http://www.complexevents.com/2011/08/23/
event-processing-glossary-version-2-0/, last access 2012-05-30
16. Börger E., Stärk R., Abstract State Machines: A Method for High-Level System
Design and Analysis, Springer Berlin Heidelberg (2003)
17. Etzion O., Niblett P., Event Processing in Action, Manning Publications,
Stamford (2011)
18. Börger E., Approaches to Modeling Business Processes. A Critical Analysis of
BPMN, Workflow Patterns and YAWL, Software & Systems Modeling 11
(2012) 3, pp. 305-318.
19. Silver B., BPMN Method and Style, 2nd Edition, with BPMN Implementer's
Guide: A Structured Approach for Business Process Modeling and
Implementation Using BPMN 2, Cody-Cassidy Press (2011)
20. Paschke, A., A Semantic Rule and Event Driven Approach for Agile Decision-
Centric Business Process Management, in: Abramowicz, W., et al. (Eds.),
ServiceWave 2011, LNCS 6994, pp. 254-267, Springer, Berlin Heidelberg (2011)
21. Janiesch, C., Matzner, M., Müller, O., A Blueprint for Event-driven Business
Activity Management, in: Rinderle, S., Toumani, F., and Wolf, K. (Eds.), 9th
International Conference on Business Process Management (BPM). LNCS 6896,
pp. 17-28, Springer, Berlin Heidelberg (2011)
22. Paschke, A., Kozlenkov, A., A Rule-based Middleware for Business Process
Execution, in: Bichler, M., Hess, T. et al. (Eds.), Proceedings of Multikonferenz
Wirtschaftsinformatik (MKWI) 2008, pp. 1409-1420, GITO, Berlin (2008)
23. Hermosillo, G., Seinturier, L., Duchien, L., Using Complex Event Processing for
Dynamic Business Process Adaptation, in: Proceedings of the 7th IEEE Inter-
national Conference on Service Computing (SCC), pp. 466-473, Miami (2010)