Event-driven architecture

An event-driven architecture , also called event-driven architecture , is a software architecture in which the interaction of the components is controlled by events.

Events

Events can come from outside, e.g. B. by user inputs or sensor values, as well as by the system itself (e.g. change notifications).

An event can trigger an event handling with which the system reacts. An event-driven architecture has little control over when data is processed. A simple example is the graphical user interface : Here the user determines which data is processed and when by executing actions and thereby triggering events.

The use of this architecture requires that all systems involved in the handling of the event can communicate with each other during planning and development. Typically, the event-driven architecture requires a definition of what is to be regarded as an event. To do this, computer systems or sensors monitor the status of objects and can trigger an event if necessary. This is followed by the processing of the event according to defined rules and the consequence of the event. If it is not possible to immediately achieve the defined sequence of the event during event processing, the event is temporarily stored in the status it has reached and only continued when the sequence can be achieved.

The event-driven architecture has the greatest benefit when it is already taken into account in the planning phase. Converting existing software to an event-driven architecture can lead to unacceptable effort due to the lack of the required interfaces.

The event-driven architecture complements the service-oriented architecture , since services can be triggered by events. On the basis of the event-driven architecture, systems for event-driven process chains in particular can be developed.

Event flow

An event usually comprises three pieces of information: the time it was created ( timestamp ), the triggering component (source) and the type of event (type), which specifies what essentially happened. Often the event type is not determined by a specific type of the respective programming language , but by hierarchical event topic , for example in the form of a pseudo URI such astopic://OptionsDialog/Controls/AcceptButton/Click

Events event handlers ( eventhandlers ) intercepted that in object orientation be implemented in methods or own classes. If a routine is responsible for an intercepted event type, it initiates appropriate processing steps. Independently of this, the routine can pass the event on to other routines or mark it as done or discard it.

Events are not messages that are sent to specific components in a targeted manner, but rather are passed on to the system “blindly”, so to speak. An event can trigger actions at one or more points in the system, but it can also be discarded completely unnoticed (because no processing routine was marked as responsible for the event). Since the time and sequence in which an event reaches various components are not initially specified, the routines each process independent, completed tasks. Event-driven architecture is basically designed for parallel processing .

Modeling

The event-driven architecture is based on four logical levels. It begins with the triggering of an event and ends with any reaction to the event. Sequence diagrams and similar process flow diagrams are used to design such systems.

Event producer ( event generator )

The first logical level of this architecture is the event producer ( event generator ) , which monitors the status of an object. Events can be produced by any software that can be used for status monitoring. Business intelligence solutions, e-mail clients, CRM systems or DMS systems are examples . In addition, sensors - for example temperature sensors, tachometers or microphones - can trigger the event. Converting the different data from the event producers used into a uniform format that can be used is the greatest challenge in the development and implementation of this level.

Event carrier ( event channel )

The medium that transmits the information about the event to the event set of rules is called the event carrier. This medium is often simply an area in the main memory of the computer (i.e. the entry address of the method or routine which will handle the event). However, it can also be a cable (e.g. for sensors), a database, a TCP / IP connection or any file (flat, XML etc.) can also be used. Any number of event carriers can be and become active at the same time.

Event processing rules ( event processing engine )

The event set of rules identifies, classifies and processes the event. For identification, it is necessary that the rules and regulations monitor the occurrence of events. Then the event is classified based on the event type. A set of rules is assigned to each classified event, which is run through after the specific event has occurred. The rules are implemented by program code, but can also be stored in relational databases by means of SQL statements, in special workflow management systems or special control software. When developing this layer, it must be ensured that the greatest possible degree of automatism is achieved. After running through the set of rules, a new event may arise, which in turn - as a different event - runs through a further set of rules.

Event activity ( downstream event-driven activity )

In this shift, the reaction to the event takes place, for example the sending of a letter, the triggering of a sound signal, the emergency shutdown of a machine, etc.

Types of event-driven processing

The event-driven architecture distinguishes three types of processes: simple, continuous and complex. In event-driven systems, all three types of processes usually occur.

Simple event processing ( simple event processing )

Simple event-driven processes directly trigger specific results. If, for example, every customer is to receive a birthday card, all affected customers can be selected using an SQL query, the address data can be linked to a form letter template and printing can be initiated.

Processing of event streams ( event stream processing )

Event Stream Processing (short: ESP, German: 'Processing of event streams ') is the umbrella term for a number of technologies for visualizing and storing events, for event- controlled middleware and event processing languages.

Processing of complex events ( complex event processing )

If several events that have a causal, spatial or short-term connection are combined in a common process, one speaks of a complex event-driven process. In a complex event-driven process, a structure is required that identifies the decisive event from the list and processes it up to the next step in the set of rules. The development of event producers, event carriers and the definition of the set of rules for complex event-driven processes are usually challenging. A potential field of application for CEP in operational practice is e.g. B. the monitoring function of supply chain event management (SCEM) systems: CEP can help companies by analyzing the increasing volume of data in supply chain management (including through the increased use of advanced planning and scheduling - Systems, tracking & tracing systems, RFID infrastructures, etc.) to detect critical deviations in the supply chain .

Decoupling of components

When software components are loosely coupled, component A, which uses the functionality of a further component B , does not "know" anything about the inner workings of the disclosure of the interface , i.e. the concrete implementation of the functionality of component B, but something about the signatures of the methods that provide these functionalities. In a purely event-oriented system, this knowledge is no longer necessary, since events, as shown above, can be triggered “blindly” and “into the air”. However, the event producer must not rely on the event being taken into account, captured and processed anywhere else in the system insofar as the program flow of the event producer must be independent of any handling of the event. (This requirement is independent of the fact that failure to observe an event may impair the functionality of the software product.)

Universal connection of systems

The event-driven architecture allows the compact connection of systems and can be used universally. The advantage of this open architecture: An event can be anything and can occur anywhere. When an event occurs, however, it is often not regulated how the event should be dealt with. The approach of looking for the cause of business processes in specially defined events leads to a wealth of options from which target-oriented organizational models can be derived.

literature

Ralf Bruns, Jürgen Dunkel: Event-Driven Architecture. Software architecture for event-driven business processes , X.pert Press (Springer) 2010, ISBN 978-3-642-02438-2
Thomas Buckel: On the potential of event-driven architecture for complex corporate networks, in: Dirk Christian Mattfeld, Susanne Robra-Bissantz (Ed.): Multikonferenz Wirtschaftsinformatik 2012, proceedings of the MKWI 2012
Josef Schiefer, Szabolcs Rozsnyai, Christian Rauscher, Gerd Saurer: Event-Driven Rules for Sensing and Responding to Business Situations . In: DEBS '07 Proceedings of the 2007 inaugural international conference on Distributed event-based systems . ACM, New York 2007, ISBN 978-1-59593-665-3 , pp. 198–205 ( online at CiteSeer - presentation of a “rule management system” in EDA).