THE CONVERGENCE OF WORKFLOWS, BUSINESS RULES AND

COMPLEX EVENTS

Deﬁning a Reference Architecture and Approaching Realization Challenges

Markus D

ohring, Lars Karg, Eicke Godehardt and Birgit Zimmermann

SAP Research, Bleichstraße 8, Darmstadt, Germany

Keywords:

Workﬂow management, Business rules, Complex event processing, Business process management.

Abstract:

For years, research has been devoted to the introduction of ﬂexibility to enterprise information systems. There

are corresponding concepts for mainly three established paradigms: workﬂow management, business rule

management and complex event processing. It has however been indicated that the integration of the three

paradigms with respect to their meta-models and execution principles yields signiﬁcant potential for more

efﬁcient and ﬂexible enterprise applications and that there is still a lack in conceptual and technical guidance

for their integration. The contribution of this work is a loosely coupled architecture integrating all three

paradigms. This includes a clear deﬁnition of its building blocks together with the main realization challenges.

In this context, an approach for assisting modelers in solving the question which paradigm should be used in

which way for expressing a particular business aspect is presented.

1 INTRODUCTION

The proper integration of workﬂow management

(WfM), business rule management (BRM) and com-

plex event processing (CEP) paradigms is a major

concern for future enterprise applications. Those are

expected to improve the overall organizational ﬂex-

ibility and performance as well as to provide self-

adaptivity capabilities in terms of tailoring them-

selves to the business needs of an enterprise over time

(Gualtieri and Rymer, 2009). One aspect in this re-

gard is the increased semantic expressiveness of the

meta-models e.g., by combining workﬂows and busi-

ness rules (Zur Muehlen et al., 2008). However, since

each ﬁeld has evolved separately and usually targets

a deﬁnite class of business problems, there is also a

particular overlap in modeling constructs by means of

the three paradigms. This may lead to confusion re-

garding the question what to model where—and how.

Generally, the provision of a properly deﬁned inte-

grated architecture for WfM, BRM and CEP together

with speciﬁc modeling guidelines is still a long way

off (Brett and Gualtieri, 2009). The highlighted gaps

are addressed by this work as follows: In Section 2,

related work on the combination of WfM, BRM and

CEP is discussed. Based on the identiﬁed lack of

holistic integration concepts, an architecture for the

proper interplay of the three paradigms is presented

and its building blocks are formalized in section 3.

The section also discusses the main architectural re-

alization challenges in terms of meta-model mapping

and extension as well as the provision of model rec-

ommendations. A basic example illustrates ideas for

their solution in section 4. Section 5 concludes this

work.

2 RELATED WORK AND

MOTIVATION

The work of (Knolmayer et al., 2000) describes

the use of reaction rules as an integration layer be-

tween different workﬂow modeling languages. They

show how typical workﬂow constructs, for example

XOR branching, can be realized by Event-Condition-

Action (ECA) rules. The approach is reﬁned in

(Van Eijndhoven et al., 2008), where a methodology

for manually identifying variability points in a work-

ﬂow (parts which are likely to change in the future)

and applying a pattern-based transformation to ECA

rules is proposed. The combination of rule and work-

ﬂow meta-models is targeted by (Milanovic and Ga-

sevic, 2009), who also provide a graphical integration

of industry standard modeling languages for the two

paradigms. (Decker et al., 2007) present a graphical

338

Döhring M., Karg L., Godehardt E. and Zimmermann B. (2010).

THE CONVERGENCE OF WORKFLOWS, BUSINESS RULES AND COMPLEX EVENTS - Deﬁning a Reference Architecture and Approaching

Realization Challenges.

In Proceedings of the 12th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

338-343

DOI: 10.5220/0002972903380343

 SciTePress

notation for modeling complex events in workﬂows.

The notation consists in a temporal extension for

BPMN

, e.g., introducing precedence relationship

connectors for event nodes. (Paschke and Kozlenkov,

2008) implement whole workﬂows based on rules, es-

pecially leveraging eventing paradigms. Their efforts

are of more technical nature on the implementation

layer and do not target the special requirements of a

business analyst regarding the overall understandabil-

ity and efﬁciency of business logic. (Bry et al., 2006)

provide a case study realizing a ﬁctive car rental pro-

cess completely with ECA rules, stating that this bears

potential drawbacks for instance regarding the capa-

bilities of monitoring a business process.

In summary, much related work addresses meta-

model integration issues. Yet confusion is caused by

an improper mixing of the paradigms best suited to

express a particular business problem. This multiplies

with an insufﬁcient conceptual separation of model-

ing paradigms and their implementation within an en-

terprise system. All approaches lack a convenient

methodological support for ﬁnding the joint balance

for employing elements from WfM, BRM and CEP.

For this reason, (Zur Muehlen et al., 2008) present a

framework comprising decision criteria for choosing

rule or workﬂow concepts, however neglecting event-

ing aspects. Those criteria for instance include how

frequently the business aspect changes in its deﬁni-

tion. Even though the criteria are principally mea-

surable to a restricted extent, no formal procedure is

provided on how to determine thresholds and to offer

speciﬁc model recommendations. Consequently, an

important lack in research is the provision of the con-

ceptual facility for using the paradigms together and

appropriate guidance to deal with semantic overlaps

of the meta-models.

3 JOINT ARCHITECTURE FOR

WFM, BRM AND CEP

Imagine a business analyst who wants to represent a

customer solvency rating, whose outcome depends on

many interdependent criteria, in an IT system. Would

he models those checks as a sequence of workﬂow

steps? Or declaratively as business rules? Or would

he rely on events like customer has outstanding pay-

ments > 5000$ for more than 2 months? Could he

even use a combination of all of the paradigms? This

section lays the foundation for such a potential com-

bination in terms of architectural building blocks and

See http://www.omg.org/cgi-bin/doc?dtc/09-08-14 for

Business Process Modeling Notation V.2.

corresponding realization challenges, followed by a

formalization of the architecture components and in-

tegration points.

3.1 Building Blocks and Integration

To the best of our knowledge, there is no clear and

holistic deﬁnition of a loosely coupled architecture

supporting all three paradigms. Loosely coupled

means that it should be possible e.g., to only employ

a workﬂow management system and step-by-step ex-

tend it with a rule engine and ﬁnally a CEP engine if

needed. Consequently the architecture must specify

the paradigm integration points for industry standard

meta-models like BPMN2 and RIF

in a minimal-

invasive way, which means there should be preferably

no changes to the original meta-models. For an event

pattern language (EPL), there is no standard available

yet. Therefore the consideration of proprietary lan-

guages like Esper EPL

will be necessary.

A reference architecture that sufﬁces these re-

quirements is presented in ﬁgure 1. Its formal deﬁ-

nition is provided in section 3.3. The (meta-)model

layers are separated from the implementation layer

within the architecture to emphasize their partial inde-

pendence. This is because in practice, each paradigm

is realized with a favored set of implementation vari-

ants, as for example petrinet-based workﬂows, RETE

pattern matching for rule conditions or event-driven

backward chaining for CEP as in (Anicic et al., 2009).

If however the power of the distinct meta-models is

correspondingly constrained, all paradigms could be

implemented within one monolithic software compo-

nent. Neglecting implementation aspects for now, we

describe the features and interplay of the paradigms

in ﬁgure 1 from right to left.

CEP captures changes in the state of systems

(eventually from the real-world via sensors) as events

and provides a temporal algebra as well as data-

mining and pattern matching algorithms to detect

events of higher semantic meaning (Luckham, 2002).

These abilities in addition to facilities for handling

and ﬁltering masses of incoming events from dif-

ferent sources are the unique features of CEP. For

our reference architecture, all detected events which

are business relevant according to some conditions

are kept within an event cloud. This term is coined

by (Luckham, 2002) and expresses that events in a

business context usually do not stem from one orga-

nized stream, but from several sources causing a lot of

data noise. One important characteristic of the CEP

See http://www.w3.org/TR/rif-core

See http://esper.codehaus.org

THE CONVERGENCE OF WORKFLOWS, BUSINESS RULES AND COMPLEX EVENTS - Defining a Reference

Architecture and Approaching Realization Challenges

339

Workflow Model (WF)

Business Ruleset (R)

Event Cloud (C)

WFM

paradigm

Model

Implementation

layer

BRM

CEP

e.g. event-driven

backward chaining

e.g. RETEe.g. Token Passing

Business Logic (T)

Conditions (P)

+ Event Algebra

Business Logic (T,D)

Conditions (P)

Workflow Language

(e.g. BPMN2)

Workflow Language

(e.g. BPMN2)

Rule Definitions

(e.g. RIF)

Rule Definitions

(e.g. RIF)

Event Patterns

(e.g. Esper EPL)

Event Patterns

(e.g. Esper EPL)

Model Integration (Transformation or Weaving)

Meta-

Model

Model Guidelines and Recommendations

invoke (e, g)

Partly Shared Task Repository (T)

Partly Shared Data Model (S)

Sensor

Events

raise (e)

triggger / raise (e)

trigger (e)

Figure 1: WfM-BRM-CEP integration architecture.

paradigm is, that it is not responsible for conduct-

ing business logic. It is rather a mere event cruncher.

Events from the cloud can be used as signals to trig-

ger business rules or for catching event nodes within

workﬂows.

BRM aims at enabling the business domain expert

to express statements that deﬁne or constrain aspects

of the business (Hay and Healy, 2000). Being spec-

iﬁed in a modular and declarative way as relatively

simple and small ECA rules, the realization of com-

plex decision and action logic can be achieved by the

collectivity of a ruleset. In summary, the strength of

business rules is their easy comprehensibility and di-

rect separate changeability. Within our reference ar-

chitecture, business rules have at most one event at-

tached as a direct trigger. If constraints on multiple

events or temporal constraints need to be speciﬁed,

this should be achieved in the CEP environment yield-

ing a new single complex event. This has the advan-

tage of disburdening the business analyst (i.e. the rule

expert in this case) as well as the BRM engine from

having to deal with complex event algebra. The ac-

tion part of an ECA rule may contain manipulations

to the local data context or task executions, which in

turn can lead to the detection of new complex events.

Business rules in our architecture are of twofold rele-

vance: They can be explicitly invoked by a WfMS as

a decision service or they can be triggered by events

from the event cloud providing reacting resp. excep-

tion handling mechanisms.

WfM aims at the IT-based speciﬁcation and coor-

dination of tasks as units of work within an enterprise

and their allowed execution order to jointly realize a

business goal (Leymann and Roller, 1999). In prac-

tice, a workﬂow model is implemented by IT experts

in cooperation with domain experts and remains rel-

atively stable over a longer period of time. However,

in some niche areas, also adaptive WfMS as presented

by (Dadam and Reichert, 2009) have evolved. Such

WfMS allow for more ﬂexibility in terms of control

and data ﬂow changes at design- and runtime. The

strength of workﬂows lies in the overall comprehen-

sibility and traceability of business logic. A workﬂow

as part of our architecture may receive and commu-

nicate events with the event cloud. To be able to in-

tegrate business rule conditions with workﬂow task

execution, we assume that at least the ﬁnishing of

a task instance constitutes a business relevant event

comprised by the event cloud. As such, it can be

reused amongst others for triggering business rules.

The branching behavior of gateways can be realized

by invoking business rules.

For an efﬁcient integration of the three paradigms,

there must be a partly shared data model for all

paradigms, e.g., a customer ID must be uniquely de-

ﬁned. Furthermore, there must be a shared task repos-

itory for use in rules and workﬂows, i.e., a predeﬁned

task can be started within a WfMS as well as the ac-

tion part of a rule. The white arrows in ﬁgure 1 sym-

bolize the architectural integration points. The two

horizontal continuous arrows concern the main scope

of this work. The one on the meta-model layer rep-

resents the ability to model distributed business logic

combining all three paradigms (Section 3.2.1). The

one on the model layer relates to the provision of de-

cision and optimization support (Section 3.2.2).

3.2 Realization Challenges

3.2.1 Challenge #1 - Integration of the

meta-Models

Each distinct paradigm, WfM, BRM and CEP has

evolved from speciﬁc business domains and exist-

ing meta-models have been designed accordingly. It

is desirable to provide a loose coupling and there-

fore to allow for a stepwise extension of the sys-

tem landscape. Consequently the meta-model integra-

tion should be achieved preferably leaving their origi-

nal deﬁnition (almost) intact, using either weaving or

mapping concepts:

Meta-model Weaving. One option to realize the in-

tegration of meta-models without changing or reduc-

ing their original semantics is to deﬁne additional

bridge meta-elements. The resulting overall meta-

model is a superset of the original distinct meta-

models regarding its semantic expressiveness. For in-

stance, a new integrated meta-element could be de-

ﬁned using multiple inheritance from different meta-

model packages and subsequently be enriched with

additional properties. An example would be a rule-

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

340

gateway with joint semantics from BPMN and a rule

language.

Meta-model Mapping. Assuming that not all parts

of the meta-models can be reasonably combined by

model extension, it is required to be able to map par-

ticular constructs from one paradigm to those of an-

other paradigm. For instance, if a company has em-

ployed only a rule-based information system in the

past, it should be possible to smoothly migrate some

of the rules that in fact realize process logic to an

explicit workﬂow representation. The resulting over-

all meta-model is equal to the original distinct meta-

models regarding its semantic expressiveness. An ex-

ample would be the expression of workﬂow-patterns

via ECA rules.

3.2.2 Challenge #2 - Modeling Guidance

As model mappings will presumably play a chief part

within our meta-model integration efforts, we face the

problem of a semantic redundancy of some parts of

the overall meta-model. That means, when employ-

ing more than one paradigm at once within an enter-

prise information system, it might not be a-priori clear

which construct from what paradigm should be used

to model a particular business problem. Therefore,

we propose to continue and more substantiate work

like (Zur Muehlen et al., 2008) for providing speciﬁc

modeling guidelines in terms of grounding them on

solid comprehensible metrics. These can be subdi-

vided into design-time metrics relying on static model

aspects and log-based execution analysis metrics.

3.3 Formal Deﬁnitions

We formalize the architecture components mainly for

a deﬁnition of the paradigm intersections, e.g., where

modeling elements can be commonly reused. The

presented notation is also employed in section 4 for

sketching the solution approach.

Deﬁnition 1 (Event Cloud). Let C be an event cloud

consisting of events e. An event e can be represented

as a tuple e = (s, r,

→

,P), where:

• s is a stamp relating to a ﬁxed point in time when

the event occurred or has been detected

• r represents a boolean variable whether this event

is business relevant in terms of affecting the busi-

ness logic or not

•

→

as a potentially empty causality vector contains

all events that caused the detection of e

• P ⊆ M, M := A × V is a set which contains

attribute-value mappings at time s, which are ad-

ditional prerequisites constraining the business

data context the event may occur in.

For the deﬁnition of a workﬂow model we adopt for-

malisms from (Yongchareon et al., 2010), especially

considering the BPMN2 intermediate event construct.

Deﬁnition 2 (Workﬂow Model). A workﬂow model

is a set of connected tasks, events and gateways in

terms of an extended directed graph. It can be repre-

sented as a tuple W F =



O,T,E,G,F, T



, where

• O represents a set of workﬂow nodes, where:

– T ⊂ O is a set of tasks. For each t ∈ T,∃e ∈

= true,

K =

0 as an event indicating the

proper ﬁnishing of a task instance.

– E ⊂ O ∩C as a set of events E ∩ T =

0 with a

function type

event

: E →

{

start, intermediate

throw

,intermediate

catch

,end

}

– G ⊂ O is a set of gateways G ∩ E =

0 ∧ G ∩ T =

with a function type

gateway

: E →

{

or, xor, and

}

• F ⊆ O ×O represents the directed control ﬂow re-

lations, implying f (o

) 6= f (o

), ∀i 6= j.

• T

⊆ E ×T is a set of attachments of intermediate

events on tasks.

• X ⊆ M, M := A ×V is the valid data context in

terms of workﬂow variables and possible values.

Deﬁnition 3 (Business Rule). A business rule r from

a ruleset R in the ECA format is deﬁned as a triple

{

e ∈ E ∨e =

0,P

⊆ M,

A := a

∈

∈O

∀O

∪ D



where

A can be interpreted as an ordered list of ei-

ther task executions or data context change opera-

tions from the set D as a function d ∈ D : m

⊆ M →

⊆ M, m

6= m

Implications for Architecture Bindings.

• ∀g

[

(∀ f ∈ F

= g )

> 1 ∧ type

gateway

(g)

6= and], ∃ρ ⊆ R specifying the split behavior.

• The shared data model implies that ∃S ⊆ M, M :=

A ×V commonly used in C, R, O.

• The shared task model implies:

[

∈O

∀O

∩

[

∈R

∀R

4 APPROACHING THE

CHALLENGES: EXAMPLE

In this section, we concretize some suggestions for

approaching the architecture realization challenges.

For this purposes, we build upon our aforementioned

THE CONVERGENCE OF WORKFLOWS, BUSINESS RULES AND COMPLEX EVENTS - Defining a Reference

Architecture and Approaching Realization Challenges

341

Record Order

Check

Technical

Feasibility

Check

Economic

Feasibility

Check Credit

Rating

Check

Product

Availability

Determine

Alternative

Offer

Send Offer

Reject Order

Accept Order

Close Case

CFC=15; CFC

rel

=1,875

available

unavailable

bad

good

infeasible

CFC=0; CFC

rel

CFC=13; CFC

rel

=2,16

infeasible

feasible

profit margin < 5%

Figure 2: Workﬂow with decomposition and metrics.

Record Order

Determine

Alternative

Offer

Send Offer

Close Case

Decide on Request

(a) Abstracted workﬂow.

1. ON

technical_check_finished

credit_check_finished

availability_check_finished

economic_check_finished

RAISE

checks_finished

2. ON

credit_check_finished

creditCheck.result=failed

rejectTask.started=false

START

reject

(b) Workﬂow parts mapped to

Events&Rules.

Figure 3: Combination of workﬂow and rules.

example of a business analyst who wants to model

complex checks for a customer and present an order

processing workﬂow extended from (Seel et al., 2006)

in ﬁgure 2. After a customer order has been received,

the default continuation is to execute four checks, de-

pending on which the order is rejected or accepted. If

the proﬁt margin of the ordered product is not high

enough, an alternative offer is sent to the customer

without accepting or rejecting the actual order. The

decision logic encoded in the workﬂow diagram is

quite complex and hard to capture. It therefore makes

sense to outsource a part of the ﬂow decision logic to

a rule base.

To address challenge #2, design-time model com-

plexity metrics may contribute to the identiﬁcation

of model optimization potentials. For our example,

we are interested in complex parts of the workﬂow

which are hard to capture via ﬂow diagrams. There-

fore the workﬂow is ﬁrst decomposed by applying

mechanisms as presented in (Polyvyanyy et al.,

2009). The procedure identiﬁes workﬂow segments

as φ = (T

⊆ T, G

⊆ G,F

⊆ F). Characteristics like

intermediate events as permitted by deﬁnition 2 are

not contained within the example, but are however

considered in workﬂow segmentation work by

(Yongchareon et al., 2010). The detected segments

are marked with a dashed line in ﬁgure 2. To measure

the complexity of a workﬂow segment, (Cardoso,

2006) provides an intuitive and empirically validated

metric: the control-ﬂow-complexity (CFC), which

is based on the number of mental states a modeler

has to consider when modeling the workﬂow caused

by split gateway semantics. The metric can be set

in relation to the number of task nodes within a

workﬂow segment to express the “density” of deci-

sion complexity for φ as CFC

rel

= CFC (φ)





The corresponding values for CFC and CFC

rel

are indicated in the upper left corner of the work-

ﬂow segments. Having identiﬁed segments in the

workﬂow most appropriate for being outsourced as

rules, they can be transformed into the rule format

provided by deﬁnition 3 (relating to challenge #1)

by applying pattern-based transformations like

{

), f

)

}

,type

gateway

)

= XOR, type

gateway

) = AND → r =



f inish, P

, start (t

)



. As such, rules as

presented in extracts in ﬁgure 3(b) can be con-

structed. As shown in ﬁgure 3(a), the transformed

segment in the workﬂow is replaced by a placeholder

task, with the intermediate event checks f inished

attached for continuing the control ﬂow as soon as a

decision can be drawn from the checks.

As an intermediate conclusion, the beneﬁts of the

“outsourced” rules as provided by our approach are

manifold. There is a potentially better understand-

ability of single aspects of the decision logic (not

necessarily the whole logic!). One can see for ex-

ample immediately that a failed credit check directly

leads to an order rejection. Furthermore, process

extensions and exception handling mechanisms can

be added more conveniently. A complex event caused

by the customer overdrawing his account for more

than 2 months could raise a reject ﬁnished event for

all order processes of the customer and cause the

untimely closing of the instances.

5 CONCLUSIONS

This paper presented an integrated reference archi-

tecture for the combined modeling of business logic

with workﬂows, business rules and complex events.

The provision of an integration layer for the different

meta-models as well as the supply of modeling guide-

lines were identiﬁed as the two main realization chal-

lenges for the architecture. To provide a starting point

on how the challenges can be tackled, a procedure

to identify complex decision logic within a workﬂow

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

342

and outsource it to rules was presented. The proce-

dure is based on design-time complexity metrics for

workﬂows and pattern-based transformations. As fu-

ture work, existing standards for the three paradigms

like RIF and BPMN2 are to be examined to deter-

mine their meta-model compatibility. Furthermore, it

is required to conduct a study on which granularity

for each paradigm is appreciated by business analysts

and how this can be related to metrics.

ACKNOWLEDGEMENTS

Thanks to Anis Charﬁ and Todor Stoitsev for helpful

comments. The work presented in this paper was de-

veloped in the context of the project Allianz Digitaler

Warenﬂuss (ADiWa) that is funded by the German

Federal Ministry of Education and Research. Support

code: 01IA08006.

REFERENCES

Anicic, D., Fodor, P., Stuhmer, R., and Stojanovic, N.

(2009). Event-Driven Approach for Logic-Based

Complex Event Processing. In CSE 2009, Vancouver,

Canada. IEEE.

Brett, C. and Gualtieri, M. (2009). Must You Choose Be-

tween Business Rules And Complex Event Processing

Platforms? Forrester.

Bry, F., Eckert, M., Patranjan, P., and Romanenko, I. (2006).

Realizing business processes with ECA rules. In PP-

SWR 2006, volume 4187, pages 48–62, Budva, Mon-

tenegro. Springer.

Cardoso, J. (2006). Process control-ﬂow complexity metric:

An empirical validation. In SCC ’06, pages 167–173,

Chicago, USA. IEEE.

Dadam, P. and Reichert, M. (2009). The ADEPT Project.

Computer Science - R&D, 23(2):81–97.

Decker, G., Grosskopf, A., and Barros, A. (2007). A graph-

ical notation for modeling complex events in business

processes. EDOC ’07, page 2736.

Gualtieri, M. and Rymer, J. R. (2009). The Forrester

Wave: Complex Event Processing (CEP) Platforms,

Q3 2009. Forrester.

Hay, D. and Healy, K. (2000). Deﬁning business rules -

what are they really. Business Rules Group.

Knolmayer, G., Endl, R., and Pfahrer, M. (2000). Modeling

Processes and Workﬂows by Business Rules. In BPM,

pages 16–29. Springer.

Leymann, F. and Roller, D. (1999). Production Workﬂow -

Concepts and Techniques. Prentice Hall.

Luckham, D. (2002). The Power of Events. Addison-Wesley

Professional.

Milanovic, M. and Gasevic, D. (2009). Towards a Lan-

guage for Rule-Enhanced Business Process Modeling.

In EDOC ’09.

Paschke, A. and Kozlenkov, A. (2008). A Rule-based Mid-

dleware for Business Process Execution. In Multikon-

ferenz Wirtschaftsinformatik.

Polyvyanyy, A., Smirnov, S., and Weske, M. (2009). The

triconnected abstraction of process models. In BPM

’09, pages 229–244, Ulm, Germany. Springer.

Seel, C., Simoin, B., and Werth, D. (2006). Business

Rule-enabled Process Modelling. In e-Challenges,

Barcelona, Spain.

Van Eijndhoven, T., Iacob, M.-E., and Ponisio, M. L.

(2008). Achieving Business Process Flexibility with

Business Rules. In EDOC ’08, pages 95–104, Mu-

nich, Germany. IEEE.

Yongchareon, S., Liu, C., Zhao, X., and Kowalkiewicz, M.

(2010). BPMN Process Views Construction. In DAS-

FAA ’10, Tsukuba, Jaban.

Zur Muehlen, M., Indulska, M., and Kittel, K. (2008). To-

wards Integrated Modeling of Business Processes and

Business Rules. In 19th Australasian Conference on

Information Systems.

THE CONVERGENCE OF WORKFLOWS, BUSINESS RULES AND COMPLEX EVENTS - Defining a Reference

Architecture and Approaching Realization Challenges

343