September 20, 2021
Event Processing Approaches In Event-Driven Architecture
If you’ve been following this series of blog posts on Event-Driven Architecture (EDA), you already know that the flow of an event begins with the event producer. It senses an event and creates an event message that flows through event channels to event processing. The event flow then sends instructions and pertinent data to an event consumer that takes specific actions.
These actions include taking no action at all, depending on the nature of the event. This approach 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 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 the 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 that’s needed to facilitate a 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 require a 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 take action on 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 the real-time flow of information around the enterprise by 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 at 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.
The 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. The flow also detects relationships among 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, which is especially important when sharing with many separate systems that are 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.
Enabling Disparate Applications to Interact
Event processors are critical to the ability of EDA to enable interaction and interoperability among 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 and complex multiple event dependencies as well as selective monitoring.
Event-Driven Architecture is just one of the methods our product development teams use to drive your success. Contact 3Pillar Global today to learn how we can do it for you.
