Event Processing vs. EDA vs. event-driven

I’ve been writing a series of posts on Event Processing, structured by a breakdown of the topic into two broad types. I’ve done two (here and here) posts on the business value of what I’m calling Detection Oriented Event Processing.

This post will be about Operations Oriented Event Processing. I started on a post about business value, but decided to start by clarifying the role of Event Processing in IT.

Recall that “Operations Oriented Event Processing applications want to take trigger an action based on incoming events.” In other words, in this post I treat Event Processing as a tool for implementing event-driven logic. But not just any event-driven logic: here we are interested in ”events” that represent real-world activities and conditions that are relevant to the business. I’ll develop this last idea later in the post.

First, I want to distinguish Event Processing from Event Driven Architecture (EDA). Operations Oriented Event Processing applications are the typical components of an EDA. Specifically, they are a type of Event Processing Agent (EPA) that receive incoming events and trigger business actions based on those events. You can read about EPAs at the blog of Opher Etzion.

But it is not necessary to adopt an entire IT architecture style, just to use Event Processing. In fact Event Processing has a definable value all its own, in additional to its own patterns, best practices and tools. Since an EDA is made up of lots of Event Processing Agents, everything about Event Processing can be projected in some way on to EDA. An Event Driven Architecture is what you get when you set out to use Event Processing in (almost) every IT service.

Also, I want to separate Event Processing from event-driven programming. Ask a pundit about the key benefits of an Event Driven Architecture, and a large part will boil down to decoupling. Although this benefit is highlighted in seemingly every book on EDA, it is not mentioned in the Wikipedia article on EDA. The upcoming book Event Processing in Action has a discussion of decoupling.

The decoupling that comes from an Event Driven Architecture, comes from the use of event-driven programming. As demonstrated by this article, every use of event-driven programming, from GUIs to email, gets the benefit of decoupling.  But, to get a little technical, there is more to the picture than event-driven programming.

There are logic patterns that arise when using events that represent real-world business activities and conditions. The patterns are the subject of an upcoming book called Event Processing in Action. These patterns could probably be applied to any event-driven computing scenario, but they are particularly useful when dealing with real-world, business-level events.

So Event Processing is a layer on top of event-driven programming. It captures patterns, practices and tools that may not be useful for every type of event-driven programming task, but are very useful for “real-world” events.

Now here is an example of how real-world, business-level events differ from other event-driven programming.

Most GUIs are event-driven, in that input is delivered as events and the component mostly communicate via events. But the usual logic of a GUI component is not concerned with understanding the meaning of multiple, related events. Rather each event is applied, in order, to the state of each component. The component is not at all stateless, but is generally unconcerned with events that happened before or events that will happen later. It may be the case that certain components are, in fact, worried about multiple events. But their concern is usually fairly simple: “wait for a button click” or similar.

Compare the GUI scenario to the kinds of events that are seen at a business level. Let’s say that an Enterprise Resource Planning system places orders as events. This is a fairly common scenario, all it means is that the ERP system sends a message to each vendor when it would like to place an order. But the systems that handle this “Order” event, use logic that would not enter into a GUI. Every system that touches this event considers multiple types of events that came before or after. For example, they may check for duplicate orders, they may wait for a statement of credit, they may ask for human approval. And the ERP system is also waiting for future events: it would like the supplier to confirm that the order will be delivered on time and it would like the receiving department to show that the order has indeed been received.

This consideration of multiple types of events that came before or will arrive in the future, is a pattern that regularly arises in the processing of business-level events. And it is a key focus of Operations Oriented Event Processing.

Also, underpinning all networked, event-based systems are very technical issues like load management, quality of service, failure recovery, threading, caching, persistence, algorithmic performance/complexity and inter-process communication. And all of this stuff needs to be put together properly in order for any event-based system to work properly. In fact, different use cases show radically different requirements in almost all of these technical areas.

Event Processing also looks at the tools that are used to implement event-based systems. The aim is to reduce the barrier to entry by allowing the tools to handle as much of the complex technical work as possible. This helps the IT architects and developers to focus on their main task: creating business value.

About these ads