This document evaluates and compares several Complex Event Processing (CEP) products including Drools, Esper, and Sybase ESP. It discusses their rule definition, management, scalability, high availability, and ability to process events. Esper is highlighted as highly scalable and able to process 10 million events with just 300MB memory. Sybase ESP supports high availability configurations while Drools currently lacks a high availability solution. The document also provides customer examples and discusses scaling Esper through partitioning and using it with the Storm framework.

2. EVALUATION CRITERIA
Embeddable API vs SOA
Event Oriented vs Workflow / Production Oriented
Rule Definition (XML, POJO, flat file)
Rule Management
Open Source vs Commercial
Event format
Scalability
High Availability

3. CEP PRODUCTS
Drools
Esper
Sybase ESP
Oracle Event Processing
IBM WebSphere Business Events
TIBCO BusinessEvents & Streambase
Jess
Sqlstream

4. DROOLS
Drools does not have a High Availability solution.
Drools 6.0.1.Final version drops several actions to the events (As per the user
forum this issue has been fixed in 6.1.0.Beta2).
The events are not garbage collected, after running for some time, it throws out of
memory exception while processing 4 million events (Refer the picture below,
the memory usage never reduced).
Processes 1 million small events in 4 seconds with 2000MB memory.

5. ESPER
Esper software is the CEP engine in Oracle Complex Event Processing product.
Esper has High Availability solution (Hot-Standby).
Esper has very good memory management, cleans up the events and was able to
process 10 million events. (Refer the memory usage graph below)
Processes 1million small events in 4 seconds with just 300MB memory.

6. SYBASE ESP
Supports High Availability configuration
Always runs as a server, not embeddable in the application.
Must provide input adapters to feed the data into the engine.
Must provide output adapters to get the data from engine and perform
actions.
Custom adapters can be built in C, Java and .Net
Queries are written in CCL (Continuous Computation Language), which is
based on SQL.
Uses data-flow programming for processing event streams

7. COMPARISON
Rule Engine / Feature Drools Esper Sybase ESP
Capable of processing events
(Complex Event Processing)?
Yes Yes Yes
Workflow
(production/inference) rule
engine?
Yes No No
Embeddable in a Java
application?
Yes Yes No
Run the engine as a service? Yes Yes, only with
enterprise
edition.
Yes
Supports sliding window of
interesting events
Yes Yes Yes

8. COMPARISON CONTINUED…
Rule Engine /
Feature
Drools Esper Sybase ESP
Rule Definition Text files, GUI
editor is
available
EPL, it is SQL like
language, GUI
editor is available,
with enterprise
edition.
The schema is
created with
CCL, it is SQL
like language
Rule
Management
components
available?
Yes Yes, only with
enterprise edition.
No
Rule versioning
available?
Yes, with an
additional
component
Guvnor.
No No

9. COMPARISON CONTINUED…
Rule Engine /
Feature
Drools Esper Sybase ESP
Production and
development
support available?
Yes Yes Yes
Action execution
sequencing support
Available with
rule flow
group.
Available with
@Priority
annotation to the
statement.
The custom output
Adapter has to
manage this.
High Availability No Yes Yes
Hot deployment of
rules
Yes Yes, only with
enterprise edition.
No
Open source
software?
Yes Yes No

10. COMPARISON CONTINUED…
Rule Engine /
Feature
Drools Esper Sybase ESP
Scalability Not so much
scalable. Throws
out of memory
error while
processing 4
million events.
Yes, highly
scalable. It was
able to process 10
million events in 1
minute.
Yes, capable of
processing hundreds
of thousands of
events per second.
Event Format Java object Java object, Map,
XML
Events are inserted
with the input
adapter. Sybase
provides several
adapters. Ex: csv
inpt adapter, csv
output adapter.

11. CUSTOMERS
Esper
 PayPal
 Accenture
 InMobi
 Rackspace
 Huawei
 Oracle
Drools
 Information not available
Sybase ESP
 Information not available

13. SCALING ESPER
Partitioned Stream
 An Esper Enterprise Edition server acts as a dispatcher of input stream events
 Each server executes identical EPL statements on a subset of input stream events
 Partitioned based on hashing or key ranges

14. SCALING ESPER
Partition by Use Case
 Each server instance receives all the events.
 Each server executes a sub set of EPL statements.

15. SCALING ESPER
Pipeline model
 Each server in the pipeline performs a sub task.

16. SCALING ESPER WITH STORM
Strom Bolt lacks event aggregation capability
Storm Bolt can perform simple event processing tasks
Storm Bolt can leverage Esper to perform complex event processing tasks.
This configuration of Storm and Esper, can scale up to handle very large number of events
(close to million events per second with 10 server cluster).

17. REFERENCES
https://www.jboss.org/drools/
http://esper.codehaus.org/
http://www.espertech.com/
http://en.wikipedia.org/wiki/Business_rules_engine
http://srinathsview.blogspot.in/2012/05/how-to-scale-complex-event-
processing.html
http://storm.incubator.apache.org/
http://tomdzk.wordpress.com/2011/09/28/storm-esper/
http://www.plugtree.com/making-a-non-persistent-ha-knowledge-session/