Components of Event-Driven Architecture

Event Driven Architecture Table of Contents:


 

Making a request and getting a response is a common occurrence both in programming and in the real world. You walk up to an elevator and press the call button. The elevator shows up a few seconds later, the doors open, and you step in. You press the button for the floor you’re going to and the elevator takes you to that floor. Two button presses, both requests, and two responses from the elevator. Simple.

In an equally simple digital example, you click on a weblink which issues a request that takes your browser to the desired website.

As new applications emerge, especially in the Internet of Things (IoT) space, it becomes clearer all the time that the interactive, interoperable world won’t wait for requests.

“Things” in the IoT tend to fall into two categories, sensors that detect things happening, and switches that enable responses to make other things happen. For example, a thermometer may detect that the temperature has risen above 80° F. in a given space. Exceeding that threshold is the event. Turning on the air conditioning is the result.

Features of Event-Driven Architectures

First developed almost twenty years ago, Event-Driven Architecture (EDA) creates an environment in which there’s no waiting for requests. Instead, they detect when any of many various items changes state sufficiently to warrant a response. Then they perform that response. The architecture is asynchronous and distributed. Events may occur while resources are unavailable to respond to them. EDA makes provision for storing such event notifications until resources become available. It is also highly decoupled. None of the event producers or consumers, or the processors and data transport that connect them are aware of each other and remain so even after the transaction is completed.

In our air conditioning example, the air conditioner may want to know whether to turn it on low, medium, or high based on the current temperature. The notification of the event can include specific data about that event which may be useful in determining how to respond.

EDA is not a specific software language, it is an architecture, an approach to programming, a model for more efficient solution for the capture, communication, processing, and persistence of events. As such, event-driven applications may really be created in any programming language. EDA processes are highly decoupled and can be scaled independently, which makes it a good option for modern, distributed and cloud-enabled applications that are horizontally scalable and resilient to failure.

Fundamentally, EDA detects something significant and meaningful happening and distributes useful information to all humans and automated systems that would be interested in having it. Those interested parties may or may not take action in the form of launching other services, commencing specific business processes, or obtaining further information.

Extremely Loose Coupling

EDA is extremely loosely coupled, and highly distributed. The producer of any event only knows the event occurred, with no knowledge of subsequent processing, or even the identity or existence of the interested parties. This loose coupling enables great flexibility, but makes tracing errors in a dynamic multipath event network challenging. EDA is best used for asynchronous workflows.

Choice of Topologies – Mediator

Use mediator topology when orchestrating multiple steps within an event through a central mediator.

Choice of Topologies – Broker

Use broker topology to concatenate events without using a central mediator.

Event Processing Styles

Events may be processed in any of several styles. Mature EDA systems often combine more than one.

Simple Event Processing

Typically used to take latency and cost out of business processes, simple event processing simply initiates action further down the application stream whenever a significant and meaningful change of state occurs in any hardware or software component of the system.

Stream Event Processing

Stream event processing detects ordinary events as well as significant and meaningful ones, screening them to determine significance and streaming them downstream to information subscribers. This aids in enabling in-time decision-making.

Complex Event Processing

Complex event processing (CEP) is used when evaluating multiple events and taking action as necessary. The events involved need not be of the same type or even occur at the same time. CEP uses far more sophisticated interpreters, pattern definitions, and correlation techniques. Correlation may be casual, temporal or spatial. It is typically used to identify and act on business anomalies, threats, and opportunities.

Publish/Subscribe (Pub/Sub) Processing

Pub/sub simply denotes publishers pushing messages to subscribers. In EDA, pub/sub provides instant event notifications for distributed applications. Given the extremely loose decoupling of EDA this is especially useful in distributing event information to many separate systems.

Event-Driven Architecture Flow Layers

Since EDA is a software development architecture it exists as a series of flow layers made up of components each of which plays an important part of application design. The sequence of an EDA event flow consists of four fundamental layers, each of which contains multiple components:

Event Channels

An Event Channel is a messaging backbone that transports events in a standard format between Event Generators, Event Processors, and downstream subscribers.

Event Processing

Actions taken by event processing are based upon evaluation of each event against established processing rules. Possible actions include invocation of a specific service, launching of a business process, publication of the event to subscribers, generation of another event, or simple storage of the event.

Event-Driven Downstream Activity

Events may initiate a variety of activities downstream. Activities such as commencing a service or business process may be pushed by the event processing engine while subscribers may pull event publications as needed. Possible subscribers include applications, data warehouses, automated agents, active business processes, dashboards, or humans.

Event-Driven Architecture Flow Components

Although it has been in use for almost two decades there are still many varying descriptions, definitions, and nomenclature. In the following components list great effort has been made to include as many different names for each component as could be found.

What things are called is not nearly as important as how they work together to enable software to very effectively respond to a wide variety of events happening internally, externally, and in the “real” world.

These components are presented in as close to the sequence in which they are involved as possible.

Event

In common programming parlance, the basic attributes of an event include time, source, key, header, metadata and payload. In terms of EDA, an event is simply a significant and meaningful change of state in an object and any specific data that may be relevant to it. That data is often referred to as the event payload.

The object need not be aware and usually is not aware of any of the other components in the EDA system. Put simply, it just does what it does.

Users may be the source of an event as in when they press a key or click a mouse. Sensors may detect an event in the physical world and generate an event as a result. The system itself may generate events, for example when software is loaded. An event may signify a problem, an opportunity, crossing of a threshold or some other deviation from normal. Significant and meaningful events must be specified and evaluated in business terms rather than data or application terms.

Event Producer (Generator)

Every event is generated from a source. The source might be an application, data store, service, business process, transmitter, sensor, or collaboration tool (IM, email). An ordinary event may be evaluated for notability by an event preprocessor (router, filter), resulting in the generation of a new notable event.

Because of the variety of event generators, not all events will be generated in the required format for event processing. In those cases, the events need to be transformed to the required (enterprise standard)3 format prior to being deposited in the event channel.

Event Emitter (Agents)

Event Emitters detect, gather, and transfer events. They, too, don’t know anything about event consumers, their existence or how events are processed which contributes to keeping components loosely coupled.

Event Notification

An event happens when a significant change in state occurs for any system hardware or software. The system then sends a message to tell other parts of the system that the event has happened. The event itself and the event notification are often mistakenly referred to interchangeably, which is incorrect. The event notification is a result of the event.

The event notification is configured in two parts. The event header provides a name for the event, a time stamp and an indication of what type of event it is. The event body includes additional details about the event that will be useful further along.

To maintain low coupling, the event notification does not anticipate any response.

From a DevOps perspective it’s worthwhile to note that while the event notification is relatively easy to set up, it can become difficult to trace in the event of program failure. The event notification flows through various systems each of which is independent from others. With no fixed workflow to trace, debugging and modification can be challenging.

Event Handler

An Event Handler is a software routine which handles the occurrence of an event.

Event Loop

The Event loop manages interaction between events and event handlers.

Event Carried State Transfer

To reduce system latency an event notification includes all details required to process the event. As it travels between systems, each maintains a copy of this data. The latency reduction occurs when the system doesn’t need to make remote calls for information as it makes updates of its own copy. This also enables rapid reconstruction and reprocessing of an event.

The hazard is that this will create different copies of the same data which can lead to data inconsistency across the system.

Event Store

The Event Store is a database containing all stored events for future use when necessary. Events are published to an Event Stream or Message Broker which allows subscribing consumers to access and process them as needed.

Event Sourcing

Event Sourcing stores every change in state as an event in the Event Store which adds significant resilience as any event can be rebuilt at any time in the future. This has the effect of making the Event Store the principal source of truth. Event Sourcing adds strong audit capability but cannot be depended upon as a sole solution as dependence upon other systems may make rebuilding difficult.

Event Queues

The flow of every event begins when a client sends an event to an event queue. This is, in turn, used to transport each event to the event mediator.

Event Mediator

When an event requires that multiple steps be taken some level of orchestration is required to send additional asynchronous events to various event channels. The Event Mediator provides that orchestration.

Event Channels

An Event Channel is a messaging backbone that transports events in a standard format between Event Generators, Event Processors, and downstream subscribers.

Event Processors

Actions taken by event processing are based upon evaluation of each event against established processing rules. Possible actions include invocation of a specific service, launching of a business process, publication of the event to subscribers, generation of another event, or simple storage of the event.

Event Consumer (Sinks, Subscribers)

Events may initiate a variety of activities downstream. Activities such as commencing a service or business process may be pushed by the event processing engine while subscribers may pull event publications as needed. Possible event consumers or subscribers include applications, data warehouses, automated agents, active business processes, dashboards, or humans.

Event Consumers may choose from a wide variety of responses to each event or may choose to not respond to a given event or store that event for later processing.

Understanding EDA is Just the Beginning

As you’ve read through these various processes, layers, and components you’ve traced the flow of events through an event-driven architecture. EDA enables systems to respond to events occurring in other systems through extremely loose coupling, as discussed. But this loose coupling also brings a concomitant challenge in that there is no one established workflow that can be traced in an effort to resolve system challenges. Troubleshooting will undergo transformation, but that’s a natural follow-on to the profound development change embodied in EDA.

 


Event Driven Architecture Table of Contents: