Complex Event Processing (CEP) – Part 1

Both Service Oriented Architecture (SOA) and Event Driven Architecture (EDA) are architecture styles which promote the concept of loose coupling through distributed computing. Although SOA helps deliver a loosely coupled solution, the resulting solution is generally synchronous in nature. In contrast, EDA provides loose coupling using the asynchronous publish-and-subscribe pattern. Having said that, SOA and EDA are not mutually exclusive and they bring complimentary features to the table. Event-driven architecture can complement service-oriented architecture (SOA) because services can be activated by triggers fired on incoming events. So, what is an event? And how is it different from the existing units of work in other architectures? What differentiates event processing from the other architectural paradigms? Our goal is to shed some light on these questions in this article and hopefully, go a longer mile in the forthcoming version. An event can be defined as significant change in the state of a system, and a complex event is an abstraction of other events. What differentiates EDA from other paradigms is that the system is described as a succession of events and the subsequent processing/handling of these events. At a minimum, we are then looking towards “events” and “event handlers”. There are three well-defined event processing engines in EDA:
 Simple Event Processing (SEP) - is concerned with simple events that are directly related to specific, measurable changes of condition. The common example of SEP is a typical pub-and-sub pattern being used in industry.
 Event Stream Processing (ESP) - deals with the task of processing multiple streams of event data with the goal of identifying the meaningful events within those streams.
 Complex Event Processing (CEP) - deals with the task of processing multiple events with the goal of identifying the meaningful events within an event cloud (range of events generated from multiple systems).
Then, comes the perennial question – how is ESP different from CEP? We will strive to bring out some of the differences between ESP and CEP processing through the following illustration:

So, how is CEP changing the development/tools landscape? SOA middleware vendors have expanded their CEP capabilities in order to offer event-driven architecture as an alternative or supplement to SOA. More vendors are working to “CEP-enable” their BPM environments and BAM tools to support split-second response to changing business conditions. Moreover, enterprise service bus (ESB) vendors are investing in CEP to provide a user-friendly event aggregation, correlation and visualization overlay to their publish-and-subscribe environments. Aleri , Apama (Progressive), AptSoft (IBM), Coral8, Streambase, TIBCO Business Events, BEA Event Server, IBM’s InfoSphere Streams etc. are a few of the commercial ESP/CEP engine providers, whereas Esper is an Open Source ESP/CEP engine provider. An EDA is a core requirement for most CEP applications. When an organization has implemented an EDA and event-enabled their business-sensory information, they can consider deploying CEP functionality in the form of high-speed rules engines, neural networks, Bayesian networks, and other analytical models. In upcoming articles, we will be concentrating on functional reference architecture for complex event processing and event stream processing engine for event driven architectures.

--Amit G Piplani--