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.
Last week, the Disney Channel arrived to the Israeli cable system and enriched the set of already existing children channels; so speaking about channels, it is a good time to discuss another type of channel -- an event channel, which is discussed in chapter 6 of the EPIA book draft. Some people view channel as an edge in the event processing graph, but we view channel as a type of node, since it has some processing associated with it. We define a channel as a processing element that receives events from one or more source processing elements (We refer to EPA, producer and consumer as processing elements), makes routing decisions, and sends the input events unchanged to one or more target processing elements in accordance with these routing decisions. Note that like the term Event Processing Agent, channels are abstractions and can be implemented in various ways (e.g. through messaging systems, through buffers, through persistent stores etc...). Channels are classified according to their routing schemes. Some of the common routing schemes are:
- Fixed routing scheme: The channel has predefined input terminals wired to predefined processing elements, and predefined output terminals wired to predefined processing elements. Every event that is received on any input terminals is sent to all output terminals. Note that this type of channels can be defined implicitly.
- Subscription-based: EPAs or consumers can subscribe to the channel dynamically. The routing decision is determined according to the list of subscribers that is valid at the time that a decision is made.
- Itinerary-based: The sink's input terminal identifier or identifiers are obtained from some attribute in the event's payload, this is used to send an event to a specific consumer instance, when the EPN node is the consumer class.
- Context-based: The channel makes routing decisions based on the context to which the EPA belongs. This is applicable for pattern detection ("complex event processing") type of EPA. The channel selects the appropriate run-time EPA based on the context defined in the pattern- I'll discuss contexts in length in one of the next postings, as this is the topic of the next chapter in the book.
- Type-based: The channel makes routing decisions based on the event type of the event that is being routed.
- Content-based: The routing decision is based on the event's content, this can be phrased as assertions, rules, decision trees or decision tables, and are based on the input event content, as well as context information.
This is just the basic definition, in one of the next postings I'll show example of how all these concepts fit together.
