Keep in mind, blogs are opinions and it behooves you to understand the writer’s biases. That being said there is always useful information after it has been properly ‘sifted’ – mine included, BTW, 
.
http://magmasystems.blogspot.com/
Oracle CEP Blog (by Seth White)
In case you are wondering what my background is in CEP/Distributed Caches, etc. …
I’ve spent part of the last two years:
There are some links that have some more public info:
Oracle’s CEP Server product page
Waters Webinar – “Effective trading strategies through CEP technology”
There are several CEP vendors out there. I think they fall into some interesting classes – where each class has some easily recognizable features/use cases. I’ll expand on that some more in later posts.
CEP, Distributed Caches, In-Memory Databases – these (as vendor supplied products) are all ‘newish’ technologies that have some rather interesting overlaps. In addition, there are aspects of these technologies that could definitely be used together for many problems going forward – but those are posts for another day.
The way I like to think about CEP is if you have high volume/low latency inbound data that you would like to apply ‘rules’ to, that then can spin out ‘actions’ based upon matching said rules. These ‘actions’ can also be inbound flows into other sets of rules, and so on, forming EPNs (Event Processing Networks).
There are certainly aspects of this that start to sound an awful lot like SOA/ESB at a high level. If SOA/ESB is the flow of information between systems and/or system groups, CEP is more micro – its value is literally at the more granular level. The emphasis (and the reward) is ‘ high volume/low latency’.
Whenever someone states words like high usage, high volume, low latency, etc., one should always ask the values to be quantified. A while ago, I thought 8,000 concurrent users on one of my web products was ‘high usage’, then I was handed a different project whose initial number of concurrent users was 250,000. It’s all a matter of scale. ‘High volume’ in regards to CEP technology two years ago meant processing >65,000 events/sec. Nowadays it can mean processing millions of events/sec. Average latencies can be in the microseconds, and it is common to have SLAs – guaranteed minimum latencies – in the single digit milliseconds.
To process that level through a single server requires architecting things differently than most general trends over the past decade. For a large body of problems, extensive threading is the way to go. Whether you talk about high number of connections per server, pooling, multi-threading processes, etc., the predominant coding model today is lots of threads. The one area where too many threads hurts is if you loose too much time on context switching between the threads. For a much smaller class of problems, limiting the number of threads is better for overall throughput rates. Processing business logic on 65,000 events/sec on a single server is such an example.
CEP vendor solutions start from the basis that you want to minimize and easily tightly control the threading in your system. Part of the value (and ROI) is not having to code all that infrastructure to easily do so. The other part of the ROI is the obvious one – easily defining inbound adapters for different data sources, easily defining business logic in rules, and easily defining user defined actions based on rule hits.
So in short, if some part of your system benefits from easily being able to ingest tens of thousands of events per second or more on a single server and be able to quickly and easily define sets of business logic – especially if you may want to change said rules easily – and perform actions based on those rule hits, then take a look at CEP.
CEP, EP, CESP…
Complex Event Processing, Event Server, Event Processing, Stream Processing, Complex Event Stream Processing, and so on…
These are all acronyms and names to describe the same functional area. I hate buzz words, BUT… I absolutely understand the value of saying a few simple letters to get the audience you are talking to immediately centered in roughly the right area. Especially now when this topic is new enough that it is not ‘mainstream’, but old enough that there are many people trying to get an idea of what this buzz is about. So even though I may have ‘ivory tower roots’, I certainly have mellowed in my immersion in the ‘mass market’, .
In my opinion, the term that has the best traction is ‘CEP’. Especially after the last two years, this seems to be the acronym that most analysts, vendors, practitioners have settled on.
If you are interested in hearing a thorough discussion about why it may not be semantically or technically correct – check out Tim Bass. Yes, the ‘events’ are not complex, but if you are marketing a product, CEP sounds much more interesting than EP, . And if you are paying a premium price, CEP works better in business cases to your CFO…
Theme: Rubric. Blog at WordPress.com.
