Plugtree has over 30 years of combined experience in healthcare applications, and over a decade of complex event processing experience as well. As times and technologies change, Business Rules and Business Processes have gained a decisive edge of decision making, and cloud environments have gained a decisive edge in adaptability. It is a combination of both that leads to gaining a clear advantage at making intelligent systems that adapt and grow over time in an organic, yet maintainable manner. Over the last few years we have applied our knowledge in deriving different solutions for recurring problems in combining these concepts and technologies, and in this talk we will try to cover as much as possible a compendium of good practices related to implementing CEP on continuously changing environments. This talk has the intention of explaining how to integrate a CEP server with all sorts of enterprise level middleware, such as ESBs, legacy applications, different communication protocols such as SOAP, REST and JMS, and being able to process all events in a way that makes sense in a cloud environment. This integration goes on to cover integrating outgoing events from the CEP servers to the rest of the application world. We intend to cover as many best practices as possible, from defining and upgrading the event definitions to its transformations, from the data gathering to the information generation, and from the coding to the business ROI.

1. Cloud-based CEP
on Healthcare
Modeling CEP for the
cloud
www.plugtree.com
info@plugtree.com

2. Agenda
● What is Complex Event Processing?
○ Definitions and examples
● Event Driven Architecture
○ EDA and BPM, SOA, BAM, BRMS
○ CEP as a component of EDA
● Cloud Case
○ Business Rule Management Systems
○ Cloud-wide event streaming modes
○ Handling CEP on the cloud
○ Knowledge Engineering lessons
○ Future improvements

3. What is Complex Event Processing?
● Event Definition
○ A significant change in state at a particular point in time,
in a specific domain
○ Events can be embedded in a situation, where
sometimes we want to react to some type of events.
● Complex Event Definition
○ Non-atomic event: An abstraction, composition, or
aggregation of other events called its members

4. Complex Event Examples
● 1929 stock market crash: Composition of individual stock
trades
● Natural disasters: Aggregation of many natural events
perceivable through sensors
● DDOS attack detection: Aggregation of each HTTP request
basic information and temporal relation

5. What is Complex Event Processing?
● Complex Event Processing
○ The ability to detect, correlate, abstract or aggregate
simple events to react to complex events
○ Uses temporal reasoning: Discrete sequence of points in
time (or intervals) to correlate simple events between
each other
● Event Streaming Processing
○ Events come in streams: Related to mostly filtering and
finding events within streams
○ Once they started adding constraints to such events, they
started calling it CEP

6. Event Driven Architecture
● Building applications focused on the generation of events
● Proposes a set of building blocks
○ Event producers: They send new events into the Event
Driven System
○ Event consumers: They listen to specific events from
the Event Driven System
○ Event processing agents: Works using Complex Event
Processing
○ Event channels: Connections and protocols for
transmitting events

7. Event Driven Architecture

8. Characteristics of EDA
● Applications are naturally centered on events
● Decoupled design
○ The event producer doesn’t know the consumer
○ The processing agents don’t know consumers or
producers
● The application will have the possibility to react based on
events
● Proposes a non invasive approach to extending applications
○ Provides scalability and fault tolerance for free
○ Ideal for dynamic nature of cloud environments

9. EDA and SOA
● SOA proposes a design based on shareable and reusable
components with well defined interfaces
● Each of the services inside SOA can generate events that
can be consumed by EDA components to analyse or extend
the system
○ Example: system monitoring of ESBs

10. EDA and BPM
● The Business Process activities can serve as event
producers, sending events outside the process’ scope
● Business Processes can also wait to receive events from
external sources to change its internal state

11. EDA and BAM
● Business Activity Monitoring Systems are always related with
KPIs
● How we aggregate events will allow us to provide better
feeds for new indicators

12. EDA and BRMS
● BRMS: Business Rule Management Systems
● Business Rules can be used to filter, route and compose
events
● Event Processing Agents can be written using rules
○ Events can trigger which rules are fired

13. Cloud case

14. Architecture Overview

15. Characteristics
● Rule based CEP engine
● Business Rule Management System (BRMS) for storing and
populating rule definitions
○ Rules updated on runtime after tests pass
● Handling thousands of events from multiple sources
○ Generic events
○ Typed events
● Receiving events from multiple applications
○ Event streaming framework based on AOP
● Event subscribers, persistent (with SLA) and non-persistent
(without SLA)

16. Cloud vs CEP
● Cloud Servers: Limited size, Unlimited amount
○ Scalability is key
● Drools-based CEP: All events in one common processing
network
○ Requires a large amount of memory
○ Usually runs all rules inside one server
● Compromise: Creating a distributed Event Processing
Network based on responsibility grouping of rules
○ Architecture based on splitting CEP environment into
several servers depending on demand

17. Domain-splitted CEP nodes
● Distributed Event Processing Network
○ Based on responsibility grouping of rules
○ Broker CEP node: quick distribution of events to
corresponding domain-based nodes

18. Domain-splitted CEP nodes
● Implemented with Drools Fusion
○ Rule engine based, with support for temporal operators
○ BRMS provides editors for rules, processes, and data
■ Exposes definitions through Git and Maven

19. What are rules?
● Basic structure to diagram requirements as isolated
conditions and their correspondent actions
rule "rule name"
when
a condition is met
then
an action is taken
end

20. CEP Rule events: Drools Fusion
● Simple event declaration
○ define a point in time event
■ by default, when added
○ define an interval event
● Can create new types of events on
demand
● Usually immutable, but not enforced
● Events can come from different
sources
● Drools provides 13 temporal operators
to compare events between each other
import some.package.VoiceCall;
declare VoiceCall
@role( event )
@timestamp( callTime )
@duration( callDuration )
end
declare StockTick
@role( event )
symbol: String
price: double
@expires( 2h30m )
end

21. Temporal Operators

22. CEP Rule example
● Drools provides ways to collect and accumulate different
groups of facts and events by the conditions they meet
rule "5 voice calls in two hours by same client"
when //we have over 4 calls from the same client within 2 hours since first call
$vc: VoiceCall($cn: clientNumber)
$c: Client(clientNumber == $cn)
$count:: Number(intValue > 4) from accumulate(
VoiceCall(this != $vc, clientNumber == $cn,
$vc before this, this after $vc, this meets[2h] $vc
),count())
then //mark his problem as urgent and requiring advanced treatment
globalHelper.sendAlert("user called over and over");
globalHelper2.markCallsAsUrgent($cn);
globalHelper2.setDifficulty(DifficultyLevel.ADVANCED);
end

23. BRMS and CEP nodes
● JBoss BRMS 6
○ Open Source project. Prepared for cloud
○ Manage rule groups as Maven projects stored on Git
■ Automatic CI for all environments

24. Handling the volume of events
● Scalable Message Broker: cloud
based (can grow with necessity)
● Multiple CEP nodes
○ Drools works in memory
○ Domain divided environments
○ n CEP nodes - m servers
● Reduced global domain for cross
reference problems
● Old events: persisted in scalable cache (MongoDB)
○ Discard policies more long-lived than in-memory events
○ Queried when new events trigger retrieval rules

25. Event subscriptions
● Persistent subscribers
○ SLA previously agreed
○ No message loss
○ Policy on SLA breaching
■ Drop messages
■ Store for a while and notify
action required
● Non-persistent subscribers
○ No SLA needed
○ Possible message loss
○ Ideal for quick project kick-off

26. Cloud Integration
● Fuse ESB: Cloud based and scalable, but couldn’t take the
varying volume of events
○ Events handled through RabbitMQ

27. App Integration
● Java: if you use AOP based architecture
○ Events sent through an interceptor of your services
○ Your applications gain the capacity of sending events
without adding any code!

28. BPM Engine Integration (cloud-based)
● JBoss BPM Suite: jBPM6 based
○ BPMN2: Extensible definitions
○ jBPM6: Extensible parsing for
runtime modification
○ Added event sending to all
relevant steps of processes
● Added special handling for complex
events in relevant process
definitions (i.e. human task
automatic management based on
SLAs)

29. BPM Engine Integration (cloud-based)
● JBoss BPM Suite and CEP engine
run on the same technology stack
● Splitting based on:
○ CEP gets events from many
other sources than BPM
○ Non-functional requirements
● Processes delegate fast and persist
long running processes
● CEP handles thousands of events
in memory (mostly) and very
closely related in time.

30. Cloud Operational Tasks
● SLA breach handling
○ Cloud plan that allows spikes in use
○ DevOps lesson: Continuous monitoring is key!
○ : : When SLA is breached, message increase can be
handled and actions taken
■ Message discarding
■ SLA changed
● All cloud components are monitored continuously
○ Monitoring results can be fed back to the CEP engine

31. Knowledge Engineering Lessons
● Knowledge Engineering: Discipline that involves
transferring, modeling, and integrating knowledge from
humans into artificial intelligence systems.
● Experience on gathering information from healthcare
experts led to the following maturity stages definitions:
○ Stage 1: Analysts translate expert knowledge into rules
○ Stage 2: Analysts teach experts basic rule structures
○ Stage 3: Provide tools to experts to improve and write
rules directly
■ DSL: Domain Specific Languages
■ Decision Tables

32. Knowledge Engineering Lessons
● Stage 1 and 2: Defining knowledge into structures
BASIC RULES CEP RULES
when
a condition is met
then
take a specific action
detect
a correlation of events
and
take a related action
● Stage 3
○ DSL: Providing translations from natural language to
specific technical implementation for rule executions
○ Decision Tables: Ideal for highly structured rules with
specific delimiters.

33. Risk Factors
● Environment allocation is still done manually
● Memory allocation problem
○ Event after splitting in nodes by domain, some
domains might require too much memory. Currently
suggested for private cloud
● Nodes are not replicated
○ In case of a node failure, a node is restarted
○ The in-memory events are lost
○ Small time window where event correlations can be
missed

34. Future Improvements
● Automatic node generation
○ Cloud PaaS providers have APIs to create new
environments
○ Based on new detected complex events, new
environments could be created
■ i.e. New rule domain created → Automated
environment generation
● DSL Coverage: Extend usage for Business Analysts

35. Future Improvements
● Automatic node replication
○ In-memory events replicated on extra nodes
○ Rule execution conditioned to one node at a time
○ Continuously update events and rule activations
between nodes
○ Drools: Agenda Filters and WM Event Listeners

36. Briefing up
● CEP can be handled in cloud environments
○ Special understanding of domain and processing size are
needed to avoid crashes
○ Special operational tasks must be created
■ Integration on existing enterprise administration
“accepted good practices” is possible
■ Continuous Delivery is a very real possibility
● CEP interactions with enterprise architecture can provide a huge
added value
○ Automatic control of near to SLA breach operations
○ Better detection of unexpected behaviour in event producers

37. questions?
please come next to the computer :)

38. Thank you!
www.plugtree.com
info@plugtree.com