On use of event processing in routing

Eric Roch, chief technologist of Perficient posted a question about the use of event processing for message routing rather than ESB, the router pattern is taken from the enterprise integration patterns by Gregor Hohpe and Bobby Woolf that we cite several times in the EPIA book.  Roch mentions several reasons to use event processing, some of it  relates to non-functional characteristics such as low latency,  and in-memory management.   


I think that there is some continuum that relates to the routing requirements -  some of the routing decisions are quite simple, they are based on a predicate, typically on a value of a single attribute;  some are more complex, and the routing is determined according to a pattern that involves multiple messages, in other cases the routing decision might involved a structure like decision-tree or decision-table, yet in other cases the routing is determined according to probabilistic reasons.    


The better solution is not to have ESB and EP systems in isolation, and chose in each case what should be used, instead it is better to use a single programming model that includes all types of routing, and autonomic translation to implementation in various building blocks,  some of them are taken from event processing and some from ESB or traditional messaging systems,  this is the approach I prefer for event processing in general,   not stand-alone,  but synergistic with other technologies.    In 2008 I had a posting about event processing and ESB,  arguing that ESB is a natural carrier of event processing within a SOA architecture,  and indeed I think that we'll see more and more ESB products that are enriched by event processing capabilities. 

On Enterprise Service Bus and Event Processing

This is one of the variations of Enterprise Service Bus (ESB) illustrations that I have taken from an article by one of my IBM colleagues. The topic of today is -- what are the relations between ESB and Event Processing ?

• An event processing functionality that runs Event Processing Agents in various sources, requires a that will take care of the routing and execution in a distributed environment. There are three alternatives here:

1. No native platform -- an engine that can run in multiple platforms (thus need to be integrated to each platform that it runs in by adapters etc...).
2. Dedicated event processing platform -- the event processing part has a dedicated platform that provides the infrastructure for the event processing functions.
3. Event Processing is built as part of an already existing platform.

All of these variations exist in the market today, and there are pros and cons for each of them, smaller vendors may prefer the first alternative as my friend Marco noted in his Blog.

When getting to the third alternative, if the environment is a SOA environment, then the ESB is a natural place in the SOA middleware to be the principle carrier of event processing functionality:

• It provides messaging infrastructure and routing capabilities
• It provides mediations like - validation, transformation and enrichment that can be reused for event processing (have a large intersection with the "mediated event processing" functions)
• It supports distributed environment.

While the principle usage of ESB in SOA has been to mediate between consumer and producer of services, being a carrier for event processing is now considered as a step in the evolution of ESBs.

This does not say that ESB is the ONLY place in which event processing functionality can run, which brings to a discussion about the Event Processing Conceptual Model- which I'll deal in a subsequent posting.

The ESB gets into the picture in alternative