|By Colin Clark||
|September 18, 2011 12:56 PM EDT||
As much as I disagree with much of what Curt Monash writes, he did actually ask a good question recently in his post, “Renaming CEP… or not”
Without getting into a rehash of the hash over there, let’s look at things a bit differently. Let’s talk about what CEP is not.
I left trading to join a firm called NEON. I was an early investor in this company, my mentor had started the firm, and to me it looked like the cat’s meow. It was a great time, a lot of people made a ton of money, and I was introduced into the world of software via Enterprise Application Integration (EAI). Using EAI, one could centralize the business logic associated with plugging different systems into each other, convert the format of one system into another, and pass messages around seamlessly between these applications. There weren’t a lot of competitors at that time, we were arguable #1 in the space, and the technology became MQ Series Integrator (think Websphere, like I said, we made a lot of money.)
Well, CEP isn’t EAI because there’s no concept of format libraries – sure CEP engines use input/output adapters but sure does every program ever written (I’m waiting for the first salesperson to licence the keyboard/screen adapter set – available in different languages soon!). We’re going to come back to EAI in a moment.
Throughout my career, the teams I’ve worked with have used a variety of 4th generation languages. Stuff like Powerbuilder, SQL Windows, Paradox, etc. Each of those environments had some common elements, screen designers, a domain specific language designed to make bizapp dev faster, and abstractions for common data stores. Often times, our groups wrote servers that integrated with these front ends via RPC, a streaming connection, or databases.
CEP isn’t a 4th generation bizapp dev environment – there’s no facility for building gui’s. Although some of the CEP platforms out there do have DSL’s, some also use SQL derivations. I’ve used the SQL derivations (I’ve worked at two of those co’s) and guess what? The people in those firms hated using the language themselves. ”Yes, you could do a covariance matrix with <insert proprietary get-me-sued-for-naming-it-here> but I could do it faster and easier in a different language.
I’ve also used many databases. But you don’t use CEP to store data – you only process the data in flight.
So, CEP isn’t EAI, it’s not a database, and it’s not an application development environment. Where, then, did CEP come from? Let’s look at a couple.
The work out of Berkeley and the work out of Brown, Brandeis and MIT focused on event stream processing. Here’s a blurb about Berkeley’s Telegraph:
Telegraph is an adaptive data-flow system, which allows individuals and institutions to access, combine, analyze, and otherwise benefit from this data wherever it resides. As a data-flow system, Telegraph can tap into pooled data stored on the network, and harness streams of live data coming out of networked sensors, software, and smart devices. In order to operate robustly in this volatile, inter-networked world, Telegraph is adaptive – it uses new data-flow technologies to route unpredictable and bursty data-flows through computing resources on a network, resulting in manageable streams of useful information.
And here’s one about Aurora (Brown, Brandeis, & MIT):
Aurora addresses three broad application types in a single, unique framework:
- Real-time monitoring applications continuously monitor the present state of the world and are, thus, interested in the most current data as it arrives from the environment. In these applications, there is little or no need (or time) to store such data.
- Archival applications are typically interested in the past. They are primarily concerned with processing large amounts of finite data stored in a time-series repository.
- Spanning applications involve both the present and past states of the world, requiring combining and comparing incoming live data and stored historical data. These applications are the most demanding as there is a need to balance real-time requirements with efficient processing of large amounts of disk-resident data.
Hmm. I’ve worked with both of those packages – no mention of Complex Event Processing in there at all. So where did that phrase even come from? Well, that’s the title of David Luckham’s book, “The Power of the Event” in which the good professor describes not so much an implementation, but a set of processes designed to help us all run our businesses and missions more effectively. In the book though, David references a language that deals with streaming data. Oh oh….
Around 2005-2006, a couple of firms were struggling trying to describe what Event Stream Processing was and why it was important and more importantly, why you should be spending money on it. I was the CTO of one of those firms. We competed mostly against Streambase at the time. Somewhere during that time frame, the phrase Complex Event Processing was adapted in an effort to differentiate. At that time, Aleri wasn’t CEP – they were OLAP. Streambase, formerly Grassy Brook, probably choose that name in homage to Stream Processing. Kaskad is Swedish for waterfall, or where a bunch of rivers and/or streams collide. I don’t think Apama ever used the phrase ESP, they were focused on trading from the start. Starting to get the picture?
So, if CEP isn’t EAI, and it’s not a 4th generation bizapp tool, what is it? I’ve probably kicked this dead horse enough, but one more time and it’s not going to notice. CEP needs 4 things to be called CEP (or ESP…):
- Domain Specific Language
- Continuous Query
- Time or Length Windows
- Temporal Pattern Matching
These 4 things, in my opinion, don’t make up a separate space, let alone a market. What they describe is Event Stream Processing. What they describe are features found in larger, more complete event processing environments from IBM, SAP, TIBCO, and Progress. And TIBCO, for example, just added the missing features described above to their Business Events Platform, and had instant CEP (sarcasm mine). Those offerings look a lot like the traditional EAI platforms – or where all of this began roughly 20 years ago.
So, I don’t think what a couple of vendors sell as Complex Event Processing is really CEP at all. If you want an idea of what CEP is really all about, read David’s book to get started. Then take a look at Tim Bass’s blog thecepblog.com.
In my next post, I’ll describe what CEP means to me and talk about some of the current offerings in that space. But for now, let’s just drop the phrase CEP (because it’s mostly just Stream Processing) because it means so little to so many and fails to impart any meaningful message to the people who actually write checks for this stuff.
Thanks for reading!
- My Top Five Cloud Predictions for 2011: Colin Clark
- Erlang, RabbitMQ, & Redis
- Just When I Thought I Was Done… Bring on the Visualization!
- Writing Bad Code in Map/Reduce
- CEP in the Cloud
- IaaS and Building a Private Cloud
- Cloud Aware or Cloud Built
- Twitter, DarkStar & Telescope – Delivering Sentiment to an Equities Broker
- Let’s Get Esper Up & Running
- Event Processing in the Cloud – DataSift is a Big Proof Point
- Building a Back Testing Platform for Algorithmic Trading
- Cloud vs Grid