Event Processing Approaches in Event-Driven Architecture

Event Driven Architecture Table of Contents:


 

If you’ve been following this series of blog posts on Event-Driven-Architecture you already know that the flow of an event begins with the event producer sensing an event and creating an event message that flows through event channels to event processing which sends instructions and pertinent data to an event consumer that takes specific actions, including no action, depending on the nature of the event. This allows for real-time interactive processing to support inter-operable scenarios such as the Internet of Things (IoT). As evidence of how loosely coupled these components are, the event producer has no knowledge of the consumer or consumers, nor the outcome of any given event.

Event Processing Styles and Approaches

In this post we examine the processing of each event. Processing results in producing the correct response to the received event and then sends the activity downstream to the right consumer or consumers finally resulting in the desired outcome. To accommodate the wide variety of possible events and desired outcomes several different processing approaches or styles have emerged. As EDA solutions evolve, they may frequently combine more than one of these:

Simple Event Processing (SEP)

Many events are very basic. For example, the sensor in your car that tells you when your tire pressure varies by more than 2 psi. Detecting that event will trigger a yellow light on your dashboard. Simple.

A simple event occurs when some notable, significant, and meaningful change of state or condition occurs. This makes simple event processing ideal for real-time flow of work coordination as it reduces latency and cost of processes. It simply serves to initiate action further down the application stream.

Simple events do not generate summaries but happen independently from other events. The resulting event message may contain additional data needed to facilitate response.

Complex Event Processing (CEP)

Picture the tumblers of a combination lock. For the lock to open all three tumblers must be properly aligned. Similarly, complex event processing is used when multiple events must take place before action is taken. Each individual event need not be similar to the others, nor even occur at the same time. Some may be ordinary events that don’t themselves require response. Others may be notable, significant, and meaningful.

CEP waits until all criteria are fulfilled before creating an event message to communicate action instructions. To accomplish this, CEP uses far more sophisticated interpreters, pattern definitions, and correlation. CEP is used most often to identify and action business anomalies, threats, and opportunities. It is also used to detect a specific series of events occurring within a continuous stream of incoming events.

Event Stream Processing (ESP)

Event Stream Processing drives real-time flow of information around the enterprise, processing streams of event data with the goal of identifying meaningful patterns, and helping support time-critical decision making. Ordinary as well as notable, significant and meaningful events are written to a log in ESP. Event consumers don’t subscribe, they simply read from any part of the stream any time they choose to join it. Ordinary events are passed downstream through event channels to event consumers. This makes ESP ideal for IoT workloads where decisions need to be made instantly.

ESP flow includes four steps of event processing; Collect, Enhance, Analyze and Dispatch. This flow creates a process in which events detected by the system generate a response using several different services. It detects relationships between multiple events, performs event correlation, establishes event hierarchies, and evaluates other aspects such as causality, membership and timing.

Publish/Subscribe (Pub/Sub) Processing

Think of Pub/Sub as the very familiar act of publishers pushing out messages to their subscribers. As such, pub/sub provides instant event notifications to distributed applications, especially important when sharing with many separate systems all loosely coupled in an EDA.

A pub/sub channel has one input channel which then splits into multiple output channels, one for each subscriber. After an event is sent out to all subscribers they only get to access it once, and any new subscribers joining subsequently will not be able to replay it, similar to SMS messaging.

Conclusion

Event processors are critical to the ability of EDA to enable interaction and inter-operability between various disparate applications. Sensors connecting to the Internet of Things depend upon it to determine what actions need to be taken automatically in response to their event reports. The variety of event processors available enables rapid response to simple single events, complex multiple event dependencies, as well as selective monitoring where required.

 


Event Driven Architecture Table of Contents: