But that isn’t the whole point of this post.
There are things that CEP engines are *really* good at. However, distributing events isn’t necessarily one of them. Now when it comes to interpreting the events in relationship to each other in a tight time window – now we are talking. When it comes to creating events out of that interpretation, we again have good cases. But that isn’t distribution either – that’s just notification.
But the nagging question is there. “How does the CEP engine (or indeed any other kind of event processor) get to hear about the events it is monitoring?”
A way of looking at that is in terms of the Event Distribution Network. Now that is serious architecture and infrastructure. Not to speak of some mental gymnastics on behalf of both the business and technology communities.
Conceptually, events are easy things. “Something happened”. Of greater trouble is making sure that the knowledge that “something happened” gets to the right place.
The right place might be a CEP engine – we want to see the implications of what happened with a whole bunch of other things that happened. Oh, and do it in Near Real Time (NRT) (Whatever that means!).
But another place might be at the next stage of a business process. “The customer paid their bill, let’s ship the goods”. In other words thge event as the trigger with a process call-to-action. These aren’t exclusive alternatives.
Of course there can be many things that need to know about the same event.
So just because you see a customer need that says “event” and you have a product that has the word “event” in its description, don’t make the mistake of assuming that one matches the other.
It’s as absurd as the trouble compilers have with English in examples like this. “Fruit flies like a banana”. “Time flies like an arrow”