Event-driven architecture

The first logical layer is the event producer, which senses a fact and represents that fact as an event message. As an example, an event producer could be an email client, an E-commerce system, a monitoring agent or some type of physical sensor.

Converting the data collected from such a diverse set of data sources to a single standardized form of data for evaluation is a significant task in the design and implementation of this first logical layer.[6] However, considering that an event is a strongly declarative frame, any informational operations can be easily applied, thus eliminating the need for a high level of standardization.

This is the second logical layer. An event channel is a mechanism of propagating the information collected from an event generator to the event engine[6] or sink. This could be a TCP/IP connection, or any type of an input file (flat, XML format, e-mail, etc.). Several event channels can be opened at the same time. Usually, because the event processing engine has to process them in near real time, the event channels will be read asynchronously. The events are stored in a queue, waiting to be processed later by the event processing engine.

The event processing engine is the logical layer responsible for identifying an event, and then selecting and executing the appropriate reaction. It can also trigger a number of assertions. For example, if the event that comes into the event processing engine is a product ID low in stock, this may trigger reactions such as “Order product ID” and “Notify personnel”.[6]

This is the logical layer where the consequences of the event are shown. This can be done in many different ways and forms; e.g., an email is sent to someone and an application may display some kind of warning on the screen.[6] Depending on the level of automation provided by the sink (event processing engine) the downstream activity might not be required.

Simple event processing concerns events that are directly related to specific, measurable changes of condition. In simple event processing, a notable event happens which initiates downstream action(s). Simple event processing is commonly used to drive the real-time flow of work, thereby reducing lag time and cost.[6]

For example, simple events can be created by a sensor detecting changes in tire pressures or ambient temperature. The car's tire incorrect pressure will generate a simple event from the sensor that will trigger a yellow light advising the driver about the state of a tire.

In event stream processing (ESP), both ordinary and notable events happen. Ordinary events (orders, RFID transmissions) are screened for notability and streamed to information subscribers. Event stream processing is commonly used to drive the real-time flow of information in and around the enterprise, which enables in-time decision making.[6]

Complex event processing (CEP) allows patterns of simple and ordinary events to be considered to infer that a complex event has occurred. Complex event processing evaluates a confluence of events and then takes action. The events (notable or ordinary) may cross event types and occur over a long period of time. The event correlation may be causal, temporal, or spatial. CEP requires the employment of sophisticated event interpreters, event pattern definition and matching, and correlation techniques. CEP is commonly used to detect and respond to business anomalies, threats, and opportunities.[6]

Online event processing (OLEP) uses asynchronous distributed event logs to process complex events and manage persistent data.[7] OLEP allows reliably composing related events of a complex scenario across heterogeneous systems. It thereby enables very flexible distribution patterns with high scalability and offers strong consistency. However, it cannot guarantee upper bounds on processing time.

Event-driven architectures have loose coupling within space, time and synchronization, providing a scalable infrastructure for information exchange and distributed workflows. However, event-architectures are tightly coupled, via event subscriptions and patterns, to the semantics of the underlying event schema and values. The high degree of semantic heterogeneity of events in large and open deployments such as smart cities and the sensor web makes it difficult to develop and maintain event-based systems. In order to address semantic coupling within event-based systems the use of approximate semantic matching of events is an active area of research.[8]

The Java Swing API is based on an event-driven architecture. This works particularly well with the motivation behind Swing to provide user interface related components and functionality. The API uses a nomenclature convention (e.g. "ActionListener" and "ActionEvent") to relate and organize event concerns. A class which needs to be aware of a particular event simply implements the appropriate listener, overrides the inherited methods, and is then added to the object that fires the event. A very simple example could be:

public class FooPanel extends JPanel implements ActionListener {
    public FooPanel() {
        super();

        JButton btn = new JButton("Click Me!");
        btn.addActionListener(this);

        this.add(btn);
    }

    @Override
    public void actionPerformed(ActionEvent ae) {
        System.out.println("Button has been clicked!");
    }
}

Alternatively, another implementation choice is to add the listener to the object as an anonymous class and thus use the lambda notation (since Java 1.8). Below is an example.

public class FooPanel extends JPanel {
    public FooPanel() {
        super();

        JButton btn = new JButton("Click Me!");
        btn.addActionListener(ae -> System.out.println("Button has been clicked!"));
        this.add(btn);
    }
}

(() => {
  'use strict';

  class EventEmitter {
    constructor() {
      this.events = new Map();
    }

    on(event, listener) {
      if (typeof listener !== 'function') {
        throw new TypeError('The listener must be a function');
      }
      let listeners = this.events.get(event);
      if (!listeners) {
        listeners = new Set();
        this.events.set(event, listeners); 
      }
      listeners.add(listener);
      return this;
    }

    off(event, listener) {
      if (!arguments.length) {
        this.events.clear();
      } else if (arguments.length === 1) {
        this.events.delete(event);
      } else {
        const listeners = this.events.get(event);
        if (listeners) {
          listeners.delete(listener);
        }
      }
      return this;
    }

    emit(event, ...args) {
      const listeners = this.events.get(event);
      if (listeners) {
        for (let listener of listeners) {
          listener.apply(this, args);
        }
      }
      return this;
    }
  }

  this.EventEmitter = EventEmitter;
})();

Usage:

const events = new EventEmitter();
events.on('foo', () => { console.log('foo'); });
events.emit('foo'); // Prints "foo"
events.off('foo');
events.emit('foo'); // Nothing will happen

Events are one of the fundamental elements of the Object Pascal language. The uni-cast model (one-to-one) is used here, i.e. the sender sends information to only one recipient. This limitation has the advantage that it does not need a special event listener. The event itself is a pointer to a method in another object. If the pointer is not empty, when an event occurs, the event handler is called. Events are commonly used in classes that support GUI. This is not the only area of application for events, however. The following code is an example of using events:

unit MyCustomClass;  

interface

uses
  Classes;
  
type
  {definition of your own event}
  TAccidentEvent = procedure(Sender: TObject; const AValue: Integer) of object;

  TMyCustomObject = class(TObject)
  private
    FData: Integer;              // an example of a simple field in a class
    FOnAccident: TAccidentEvent; // event - reference to a method in some object
    FOnChange: TNotifyEvent;     // event - reference to a method in some object 
    procedure SetData(Value: Integer); // a method that sets the value of a field in the class 
  protected
    procedure DoAccident(const AValue: Integer); virtual; // a method that generates an event based on your own definition 
    procedure DoChange; // a method that generates an event based on a definition from the VCL library 
  public
    constructor Create; virtual;   // class constructor 
    destructor Destroy; override;  // class destructor
  published
    property Data: TAccidentEvent read FData write SetData; // declaration of a property in a class
    property OnAccident: TAccidentEvent read FOnAccident write FOnAccident; // exposing the event outside the class
    property OnChange: TNotifyEvent read FOnChange write FOnChange;         // exposing the event outside the class
    procedure MultiplyBy(const AValue: Integer);  // a method that uses its own definition of the event
  end;
  
implementation

constructor TMyCustomObject.Create;
begin
  FData := 0;
end;

destructor TMyCustomObject.Destroy;
begin
  FData := 0;
  inherited Destroy;
end;

procedure TMyCustomObject.DoAccident(const AValue: Integer);
begin
  if Assigned(FOnAccident)
   then FOnAccident(Self, AValue);
end;

procedure TMyCustomObject.DoChange;
begin
  if Assigned(FOnChange)
   then FOnChange(Self);
end;

procedure TMyCustomObject.MultiplyBy(const AValue: Integer);
begin
  FData := FData * AValue;
  if FData > 1000000
   then DoAccident(FData);
end;

procedure TMyCustomObject.SetData(Value: Integer);
begin
  if FData <> Value
   then
    begin
     FData := Value;
     DoChange;
    end;
end.

The created class can be used as follows:

...
procedure TMyForm.ShowCustomInfo(Sender: TObject);
begin
  if Sender is TMyCustomObject
   then ShowMessage('Data has changed.');
end;

procedure TMyForm.PerformAcident(Sender: TObject; const AValue: Integer);
begin
  if Sender is TMyCustomObject
   then ShowMessage('The data has exceeded 1000000! New value is: ' + AValue.ToString);
end;
...
{declaring a variable that is an object of the specified class}
var
  LMyObject: TMyCustomObject; 
...
{creation of the object}
LMyObject := TMyCustomObject.Create;
...
{assigning a methods to an events}
LMyObject.OnChange := MyForm.ShowCustomInfo;
LMyObject.OnAccident := MyForm.PerformAcident;
...
{removing an object when it is no longer needed}
LMyObject.Free; 
...