Event-driven software architecture
Event-driven architecture is a type of software architecture based on the production, stopping, and processing of events and, if appropriate, the reaction to them. In most cases, the device that generates an event is not the same as the device that receives and processes it. For example, a sensor triggers an event when it detects motion and sends it to a server that receives it and acts as previously programmed or according to rules.
Such events are asynchronous, they can occur at any time. So the server cannot predict when one will receive or how many will arrive in a short period of time. For this reason, it is often necessary to use a queuing system to keep an event waiting until the server can attend it.
Well, what's an event? According to the RAE, an event is an "occurrence" and an occurrence is a "thing that happens. We will define an event as an instantaneous process with no duration in time that occurs at a particular moment. For the event to be useful in this architecture, a notification must be sent to a server as soon as it happens. In reality, the server does not receive the event, the event notification arrives, but for ease, when we talk about an event we will refer directly to the notification of that event.
Each event is composed of head and body. The header contains important information such as its type, its name, its generator and the time it occurred. And the body contains the data. For example, we have a thermostat that sends an event every 30 minutes at room temperature. A possible structure would be:
- Header:
- Type: Temperature.
- Name: Periodic Temperature
- Generator: Thermostat1
- Timestamp: 2019-03-05 9:23:00
- Body:
- Temperature: 23°C
When the event reaches the server, it must be processed. To study how one or more events are processed, we can differentiate in four layers, the total flow from the emission of the event to the triggering of the corresponding action. These four layers are:
- Event Generator: It is the source that throws the event. Any type of device or application could be the generator, the only requirement is that it is understandable, i.e., that the same structure is used. A generator can create a notable event (it is sent directly to the processor) or ordinary event (it must first go through a preprocessor where it is decided if it becomes notable). In the example above, the thermostat would be our generator.
- Channel of the event: It is the means of union between the generator and the processor. Your objective is to transport the messages.
- Event Processor: Is the server that receives events, processes them, compares them with pre-established rules and performs actions. The rules, and therefore the actions, are not defined by the event generators, but by the person who programs it. A possible rule for the above example would be that if the temperature exceeds 35°C the air conditioning is switched on. As we can see, the thermostat does not decide that temperature limit, it only sends what it reads.
- Response Activity: The action that is taken if any of the rules are met. It can be any type of action, from a warning to a person to an internal process completely transparent to the user. In some cases, users must subscribe to be notified of such activity.
In this architecture, we can distinguish three different types of event processing:
- Simple processing: Evaluate an event and immediately start a response activity. It is usually used to control the workflow in real time.
- Complex processing: Evaluates a series of events and then initiates a response activity. This type of processing compares events that arrive over a period of time looking for patterns and responds accordingly.
- Stream processing: An intermediate data transmission platform is used to which the events arrive and forward to the flow processors. Processors treat the flow or transform it. Used when there is constant data traffic.
Like any architecture we choose, it has its advantages and disadvantages. The weight they will have will depend on our requirements:
The main advantages of this architecture are:
- Disconnection of server and clients: Servers and clients should only use the same structure for event messages, but they can be programmed in different programming languages and be completely independent.
- Device decoupling: EDA has a star topology in which each device only has to communicate with the server. In this way, any device can be related to each other without limit. For example, a motion sensor could be connected directly to a light to turn it on, which would greatly limit possible actions. However, if the sensor sends an event to a server, this could perform any action with any device: turn on the light, display a welcome message on television, play music,...
- Highly scalable: Thanks to the decoupling between devices, any new service can easily be added to the system.
The main drawbacks are:
- The server could never know if a service has been down, as there is no real connection between them. Similarly, a device does not know if the server is down either.
- It is not possible to check whether an event has been attended.
