Event Oriented Architecture

An event can consist of two parts: the title of the event and the body of the event. The title of the event may include information such as the name of the event, timestamp for the event, and type of event. The body of the event describes what actually happened. The body of an event should not be confused with a template or logic that can be applied as a reaction to events.

Event-driven architecture consists of four logical layers. It begins with actual sounding, its technical presentation in the form of an event, and ends with a non-empty set of reactions to this event. ^[four]

Event Generator

The first logical layer is an event generator that registers a fact and represents this fact as an event. Since a fact can be practically everything that can be perceived, it can be an event generator. As an example, the generator may be an email client, an e-commerce system, or some type of sensor. The conversion of various data received from sensors into a single standardized form of data that can be evaluated is the main problem in the development and implementation of this layer. ^[4] However, given that the event is strictly declarative, any transformation operation can be easily applied, thereby eliminating the need to ensure a high level of standardization.

Event Channel

An event channel is a mechanism by which information is transmitted from an event generator to an event-processing mechanism ^[4] or sink.

This can be a TCP / IP connection or an input file of any type (plain text, XML format, e-mail, etc.) Several event channels can be opened at the same time. Usually, due to the requirements of event processing in near real-time mode, event channels are read asynchronously. Events are queued, waiting for subsequent processing by the event processing engine.

Event Processing

The event processing engine is the place where the event is identified and the corresponding response to it is selected, which is then executed. It can also lead to a series of statements. For example, if an event that arrives at the processing engine reports that “Product N is ending,” this fact may give rise to the reaction “Order Product N” and “Notify Personnel”. ^[four]

Event Follow-up

The consequences of the event are manifested here. It can manifest itself in various ways and forms; for example, a message sent to someone, or an application that displays a warning on the screen. ^[4] . Depending on the level of automation provided by the sink (event processing engine), these actions may not be required.

There are three main styles of event handling: simple, streaming, and complex. Often these three styles are used together in a large event-driven architecture ^[4] .

Simple event handling

Simple event processing concerns events directly related to specific, measurable changes in conditions. With simple event processing, well-known events occur that trigger the aftereffect. Simple event processing is usually used to control workflow in real time, thereby reducing latency and cost ^[4] .

For example, simple events are generated by a sensor that detects a change in tire pressure or ambient temperature.

Event Flow Processing

During event stream processing (ESP), both ordinary and known events occur. Ordinary events (commands, RFID transmissions) are checked for fame and transmitted to information subscribers. Event flow processing is usually used to control the flow of information in real time and at the enterprise level, allowing timely decision-making ^[4] .

Handling Complex Events

Processing complex events allows us to consider sequences of simple and ordinary events and draw a conclusion about the onset of a complex event. Complex event processing evaluates the mutual influence of events and then takes action. Events (known or ordinary) may not be typified and occur over long time periods. The correlation of events may be causal, temporal or spatial. Processing complex events requires the use of complex event interpreters, the definition of event patterns and their comparison, as well as correlation methods. Complex event processing is commonly used to identify and respond to abnormal behavior, threats, and opportunities ^[4] .

Event driven architecture is extremely loosely coupled and well distributed. The best distribution of this architecture is due to the fact that an event can be anything that exists anywhere. The architecture is extremely loosely coupled, since the event itself does not know about the consequences of its occurrence, that is, if we have a security system that records information when the front door is opened, the door itself does not know that the security system will add information about the door opening. ^[four]

Java Swing

The Java Swing library is based on an event driven architecture. This blends in especially well with Swing's motivation to provide user interface components and functionality. The interface uses naming conventions (for example, "ActionListener" and "ActionEvent") to organize relationships between events. A class that needs to be notified of an event simply implements the corresponding listener, overrides inherited methods, and is added to the object that generates the event. The following is a simple example:

  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!" );
     }
 }

An alternative is to inject the listener into the object as an anonymous class . Below is an example.

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

         JButton btn = new JButton ( "Click Me!" );
         btn .  addActionListener ( new ActionListener () {
             public void actionPerformed ( ActionEvent ae ) {
                 System  out .  println ( "Button has been clicked!" );
             }
         });
     }
 }

The same code in the functional style of Java 8, using a lambda expression instead of an anonymous class:

  public class FooPanel extends JPanel {
     public FooPanel () {
         super ();
         JButton btn = new JButton ( "Click Me!" );
         btn .  addActionListener ( ae -> System . out . println ( "Button has been clicked!" ));
     }
 }

Node.js

Server-side JavaScript platform actively uses event generators ( EventEmitter ). A lot of objects in Node generate events: net.Server raises an event for every incoming request, fs.readStream raises an event when a file is opened. An example of working with EventEmitter:

bar.js:

  var Foo = require ( "./foo.js" ).  Foo ,
     foo = new Foo ();

 foo .  addListener ( "write" , function () {
     console .  log ( "Bar" );
 });

foo.js:

  var EventEmitter = require ( "events" ).  EventEmitter
     Foo = function () {
         var foo = this ;
         foo .  write = function () {
             console .  log ( "Foo" );
             foo .  emit ( "write" );
         };
         setTimeout ( this . write , 3000 );
     };

 Foo .  prototype = new EventEmitter ();

 exports .  Foo = Foo ;

• Event Oriented Programming
• Service Oriented Architecture
• en: Event-driven SOA
• en: Space based architecture
• Handling Complex Events
• Event Stream Processing
• en: Staged event-driven architecture (SEDA)

• Difference between EDA and SOA: How EDA extends SOA and why it is important by Jack van Hoof.
• A real-life example of the flow of business events in SOA: SOA, EDA, and CEP - a winning combo by Udi Dahan.

• Industry website on Event Processing
• Website for the Event Processing Technical Society
• 5th Anniversary Edition: Event-Driven Architecture Overview, Brenda M. Michelson