This page is work in progress and helps us organize our PR activities around the 1.0 release
We are planning to release a news item such as below to TheServerSide, InfoQ, Information Week, CEP-Interest@groups.yahoo.com, perhaps dev2dev.bea.com, where else?
Status
- DONE: lists announcement
- DONE: CEP-Interest@group.yahoo.com announcement
- DONE: InfoQ
- DONE: CodeHaus blog
- DONE: TheServerSide
- DONE: Intelligent Enterprise
Proposed
The Esper development teams is proud to announce the release of Esper 1.0 final. Esper is an event stream processing and event correlation engine written in Java.
Esper performs grouping, aggregation, sorting, filtering, merging and joining of event streams using a tailored SQL-like query language. Applications can define time-based, interval-based, length-based and sorted windows and perform inner-joins and outer joins of an unlimited number of windows and event streams. Esper also performs complex event pattern matching allowing logical and temporal event correlation.
Esper is open-source software available under the LPGL license. Please visit Esper at Codehaus for tutorial, case studiesand downloads.
On the roadmap for the next major Esper release in October are native XML event support, JMS and CSV adapters and engine enhancements.
Q&A for Intelligent Enterprise
_See published news on IntelligentEnterprise
Q: What's the advantage of using Esper over other products?
A: Esper can easily be embedded in any Java runtime including J2EE application servers or standalone Java applications. Events in Esper can be represented as plain Java objects (POJO) eliminating the need to format, feed and receive events into a separate possibly remote engine process. Esper is an entirely free open-source component available under the LPGL license. The open-source nature of Esper helps in tailoring the event processing language and other community driven features.
Q: Who's using Esper?
A: With the Esper 1.0 release and given it's shorter history most users are at the evaluation stage. A major financial institution is looking at Esper for realtime monitoring of proprietary options trading. A network monitoring application had success with Esper, and Esper is also playing a role in RFID research. Our user community is growing rapidly.
Q: What business areas/problems is Esper best suited for?
A: Esper is best suited for realtime event driven applications. Typical application areas are business process management and automation, finance, network and application monitoring and sensor network applications. Esper take much of the complexity out of developing applications that detect patterns among events, filter events, aggregate time or length windows of events, join event streams, trigger based on absence of events etc. A primary difference with system relying on classical SQL databases is that we do not query a repository for events matching some conditions, but instead trigger customized actions as the flow of events come in matching event conditions - hence drastically reducing the latency.
Q: What are the most significant roadmap elements?
A: On the roadmap for the next major Esper release in October are native support for XML event, input and output adapters and engine enhancements. Beyond that we would like to address robustness by providing a fail-safe hot-hot configuration, and would like to make the engine easier to use by adding a GUI.
Q: What's your day job? Is is fair to characterize you as "Esper project lead"?
A: Yes I am the project founder and project lead. In my day job I work as a software architect for a major financial institution.
CodeHaus blog announcement
See published announcement on CodeHaus blog
The Esper development team is proud to announce the release of Esper 1.0 final.
Esper is an event stream processing (ESP) and event correlation engine (CEP) written in Java.
Esper is well suited for real-time event driven applications. It performs grouping, aggregation, sorting, filtering, merging and joining of event streams using a tailored SQL-like query language. Applications can define time-based, interval-based, length-based and sorted windows and perform inner-joins and outer joins of an unlimited number of windows and event streams. Esper also performs complex event pattern matching allowing logical and temporal event correlation.
A primary difference with systems relying on classical SQL databases is that events are not stored and later on polled in a massive hence underperformant repository. Instead as the flow of events come matching registered event conditions, Esper triggers customized registered actions (POJO) - hence drastically reducing the latency.
A more complete description of the project goals and history has been published on InfoQ.
Esper is open-source software available under the LPGL license.
Please visit Esper at Codehaus for tutorial, case studies and downloads.
Q&A for InfoQ
See what InfoQ published based on this Q&A at InfoQ announcement
How does Esper work? How does Esper allow you to search and match patterns on temporal events?
Esper is an event stream processing (ESP) and event correlation engine (CEP) written in Java.
Basically instead of working as a database where you put stuff in to later poll it using SQL queries, Esper works as real time engine that triggers actions when event conditions occurs among event streams.
A tailored Event Query Language (EQL) allows to register queries in the engine, using javabeans to represent events. A listener class - which is basically a POJO - will then be called by the engine when the EQL condition is matched as events come in. The EQL allows to express complex matching conditions that include temporal windows, and possibly join different event streams, as well as filter and sort them.
A simple example could be to compute the average stock price of the BEA tick on a sliding window of 30 seconds. Given a StockTick event bean with a price and symbol property and the EQL "select avg(price) from StockTick.win:time(30) where symbol='BEA'", a POJO would get notified as tick come in - and in real world millions of ticks can come in - so there's no way to store them all to later query them using a classical database architecture.
Statements can be much more complex, and also be combined together with "followed by" conditions.
The internals of Esper are made up of fairly complex algorithms primarily relying on state machines and delta networks in which only changes to data are communicated across object boundaries when required.
How does Esper hook into an existing event-based system?
Today, event based system are often confused with message based system such as JMS and alike backends or Enterprise Service Bus (ESB). Messaging system are event based but usually do not correlate events or process event streams at all. They simply process unitary events - and it becomes quickly complex if you need to correlate messages.
Esper can hook into any Java based system as a message consumer - whose main purpose would be to listen efficiently to everything whilst sending back other events when a matching conditions has occured. On the other hand, hooking Esper in a classic messaging system allows to have it correlate events even if those comes from non Java based systems. This is just an example. Esper is completely container agnostic, can run as a standalone component, and the 1.0 release simply assumes events to be POJO. We are currently working on providing native XML format support as well.
What are the best uses of Esper and what might be some mis-uses for it?
Esper is best suited for realtime event driven applications. Typical application areas are business process management and automation, finance, network and application monitoring and sensor network applications. Esper take much of the complexity out of developing applications that detect patterns among events, filter events, aggregate time or length windows of events, join event streams, trigger based on absence of events etc.
Esper is not designed for storing and retrieval of fairly static data - that is better left to conventional databases. In-memory databases may be better suited to CEP applications than traditional relational databases as they generally have good query performance. Yet they are not optimized to provide immediate, real-time query results required for CEP and event stream analysis.
Who developed Esper and what real world projects did it emerge out of?
Thomas Bernhardt is the project founder and project lead. He work as a software architect for a major financial institution. On a project in 2004 Thomas had been asked to evaluate different rules engines for use in an application for monitoring a trading system. The rules engines proved cumbersome and slow. There was no budget for a CEP product, thus a custom application to solve the monitoring problem was developed. The project lead's interest in CEP and ESP technologies lead to further independent research into the knowledge space followed by prototypes build for no particular organization or purpose. The prototypes evolved and the Esper project started.
Alexandre Vasseur, cofounder of AspectWerkz (now merged with AspectJ) and BEA' engineer is helping in growing the community and evangelising the concepts. Srdan Bejakovic is also taking an extensive role in the development and architecture. Our developper community is still small and the user community is growing rapidly so we welcome feedback or help.
How would you position Esper next to existing solutions (or hacks) in the industry?
Esper is the only open source Event Stream Processing out there - and this is not to be confused with classical rules engines. Compared to commercial ESP engines implementations such as StreamBase or Coral8, Esper may lack high availability options in the 1.0 release, but its open source nature is a driver to get the Event query language right, and get the Java community up to speed on those concepts - before tackling enterprise grade requirements in upcoming versions.
With the 1.0 release we have tutorials and case studies available online at http://esper.codehaus.org
News for TheServerSide
See what was published on TheServerSide at TheServerSide Esper 1.0 announcement
(note there is a slight mistake there in the sentence "In systems relying on classical SQL database, events are not stored and are later polled in a repository.". You should read: "In systems relying on classical SQL database, events are stored and are later polled in a repository - which increases latency and limits the scalability"