Event-Driven Architecture

Team 4 – Idris Callins, Jestin Keaton, Bill Pegg, Steven Ng

IntroductionWhat is Event-Driven Architecture?

An architecture style, which uses an event dispatcher to mediate between components.

Components communicate with an event dispatcher, which then sends communication to other components to notify all related components of its completion.

In many cases the event dispatcher is built into the system such as a button, which uses an actionListener to notify the event dispatcher that the button has been clicked and to execute some task.

This style is often used in dynamic/real-time environments.

Overview

What are some characteristics?

System is loosely coupled.

System must be designed to support interoperability.

Events must be captured and processed at the most granular level.

System must be modular.

High-Level Diagram of the Event-Driven Architectural

Style

Determined Output

Event Stimulu

s

Event Stimulu

s

Event Stimulu

s

Event Stimulu

s

Determined Output

Determined Output

Event Stimulu

s

Event

Cloud

Event Stimulu

s

Trigger

Trigger

Trigger

Style VariationsEvents may be dispatched synchronously or

asynchronously.

Events may be simple notifications, or they may carry packets of data from the event announcer to the event responders.

Events may have priorities or timing constraints honored by the event dispatcher, or the event dispatcher may manipulate events.

Registering interest in events may be constrained in various ways. Components may be allowed to register and unregister with the event dispatcher arbitrarily during execution, or registrations may have to be set up when the program is coded.

Where are the Events?

Events, though often invisible to users, are all over the place. Some can be seen in the example below.

Illustration of Event Driven

Architecture In SocietyA Network Intrusion Detection System (NIDS) is a

piece of software that automates the network intrusion detection process to detect intrusion attempts.

For years, NIDSs were not flexible and could not react correctly to mutating viruses. This is because the systems were comparing incoming viruses to exact instances of previously encountered viruses, instead of tracking events.

In the following diagrams, observe how an Event-Driven Architecture provides the foundation for the system to function.

System Design

DB with IDSRules

DB with Events

DB with Decision List

Detection Engine

Event Engine

Decision Engine

Input from Network

Rules in Packet Format

Rules in Event Format

Decision List

Translator

to IDML

Interesting Events

Incidents

Preprocessing Layer

Event Detection Layer

Decision Layer

Process DescriptionThe system depicted in the previous diagram behaves as follows:

1. The Preprocessing layer examines in real-time the packets of interest that are transmitted through the protected network. Based on the information in the rule database, if the packet is deemed interesting, the Detection Engine passes it through a translator to the Event Engine.

2. The Event Detection layer must determine if the events from the previous layer represent a complex attack or if they are safe network packets. If the event is included in a predetermined, directed path of attack, the event is stored in memory as the current state of the attacker and if the attacker hasn’t yet reached the final state in that path, will wait until the next event. If the final state is reached, the Event Detection layer informs the Decision Engine.

3. In the Decision Layer, the Decision Engine must determine how to handle an encountered attack based on the rules listed in the appropriate database.

Advantages of Event-Driven Design

• Loosely-coupled architecture permits a lower level subject to communicate with higher level entities.• Easier to understand and maintain• Adds a great degree of flexibility to the

system• Promotes component and service reuse• Extremely useful for GUI development

Disadvantages of Event-Driven Design

• Harder to control• Potential for slow transactions depending on

the number of events executable for an operation• Components don’t know if or when events will

be handled.• Different components might register for the

same events, causing conflicts when the event handling results are made available.• Difficult/time-consuming to implement