Wednesday, October 22, 2008

Event Stream Processing (ESP). Java got it all, where does .NET guy go?

I'm a great believer in enterprise wide distributed events and traces/logs processing.

One of my personal projects that I abandoned few years ago was focused on the distributed tracing/logging, visualizing the traces and providing trivial correlation analysis.

I'm trying to reanimate it right now, so I looked around to avoid the wheel reinvention and found out that as I was reading only .NET news for the last few years I totally missed the evolution of Event Stream Processing in the Java world. It is apparent to me now that it is what I want, BUT there is no .NET story for it. Or should I say there is always some kind of a story?

There is a Java open source project named ESPER and there is its .NET clone named NESPER, both licensed under GPL. Other licensing options? - exist, but with a price tag deeply hidden. When we talk about a .NET clone we should say if this is a .NET code it was compiled from or it is just a conversion from the java byte-code.

In the case of NESPER it is the latter option which makes it very hard to recommend in real enterprise applications (at least from my viewpoint). Another example is Drools.NET, go and offer you customer rule engine which they can't really change/fix regardless its open source character as change would require a java recompile following the byte-code conversion (and this is not anything for faint of heart which customers normally are). Normally it chains you to some older version that you have been lucky enough to get converted from java byte-code once.

As it looks, there is no 1st class citizen ESP/CEP solution in .NET. It leaves me pretty with a blank piece of paper to start with and I'll just implement something very, very lightweight. Although it was a very good read on the ESP to understand the domain, see the basic requirements and challenges.

Few links I found interesting are:

Who is who and what is what in the ESP and CEP (complex event processing) - I'd start from this link and drill down. At this early stage I found the glossary there to be very good (EPTS Event Processing Glossary v1.1), but I'll be digging more, place has got a value.

ESPER documentation
Discussion on msdn forum:
Provides more technical view on the subject and helps to fill the gap between the business domain from the above mentioned glossary and the implementation domain.

An article on ESPER I found interesting to read:

InfoQ on ESPER, but mostly on the performance/throughput promises of different engines:

Very concise review of ESP and CEP:, only good if you don't want to dedicate more than 10 minutes to the subject.

My addiction to instrumentation, logs and traces makes me a "service-level agreement" user according to the ESP/CEP areas of applicability classification. I'm fascinated how simple SLA abbreviation hides all that fun and hard work you do to make your application available, maintainable and fast. But I guess, that is how business people see it :)!

Now I need to map what I learned to my simplified requirements (and I didn't want to keep them that simple!) and .NET technology stack available. Will be back with analysis!


Marco Seiriö said...

If you like the concept of using event processing as a services instead of installing local software, I could suggest taking look at the ruleCore CEP Server which is delivered as a service. One benefit is that is takes a single web service call to add event processing to your system.

Stanislav Dvoychenko said...

Thanks Marco, I actually found documentation on the web site you refer to be quite interesting ( Providing ESP/CEP as a service should be very viable business model. Thanks for the pointer!