Sunday, January 11, 2009

Complex Event Processing & Rules Engines

I'm currently investigating complex event processors and rules engines.

Windows XP embedded has a rules engine available (through the Windows Workflow Framework). I'm currently trying to figure out what I may have to add to be able to move it into a complex event processor. I think the only thing I need is "state".

But what's state, other than remembered transactions from the past? Therefore, if I simply add a rule that allows some results of the rules engine to persist for a while after processing...

For example, if I need event A and B to happen "close" to each other, I can write something like:
within (1 min)
{
event A condition;
event B condition;
} result (create side effect C)
... is that all I need for a simplistic CEP? If so, why don't more people do it this way?

Still learning...

Wednesday, January 7, 2009

Diagnostics

I have just been put on a 5-person team that is writing diagnostics for a not-super-huge system.

That should raise alarm bells.

Not that their intention is bad. Not that they aren't following typical practices. Not that diagnostics aren't vital to any and every system.

Just that it's not that interesting.

To me, diagnostics should be one of those boring problems that just falls out when you have good design. Decouple, use standardized interfaces, and inter-class communication just becomes well-designed points where you can insert a multiplexer for logging, etc. - all on the fly. You use the interfaces to find points of diagnostics and you can even do this all on the fly (especially in languages/runtimes that support reflection).

So why should this be difficult? In my current case, it's totally legit - we're interfacing with legacy components that are inherently not very easy to log. 90% of our work is in refactoring the legacy code to easily log its data, not in the diagnostics code itself. Think of how easy logging/diagnostics/monitoring (all the same thing, really) would be if that legacy code were modular.

(Interesting side question - if "legacy code" is "modular" and therefore it can adapt and live, would it ever be "legacy"? Of course entropy would eventually age it towards legacy, but its lifetime would be much, much longer.)

So design well. Decouple often. And never, ever write diagnostics aspects.