Event-driven architecture

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

• 4.1 Simple event processing (simple event processing)
• 4.2 processing of event streams (event stream processing )
• 4.3 complex event processing (complex event processing)

Events

Events, both from the outside, for example, (eg change notifications ) can be triggered by user input or sensor values ​​, and the system itself.

An event can be a trigger for an event-handling, with the system responds. An event- driven architecture has little control over when data is being processed. A simple example is the graphical user interface: Allows the user to determine when the data to be processed by executing actions and thus raises events.

The use of this architecture requires in the planning and development that all systems that are involved in the execution of the event, can communicate with each other. Typically, sets the event-driven architecture requires a definition of what is to be regarded as an event. For computer systems or sensors monitor the status of objects and may optionally raise an event. This is followed by the processing of the event according to defined rules and the consequence of the event. It is during the event processing is not possible to achieve the defined sequence of the event once the event is cached in the reached position and will continue, if the sequence can be achieved.

The greatest benefit is the event-driven architecture, if it is already taken into account in the planning phase. Convert existing software on an event-driven architecture, in the absence of the required interfaces can lead to an unacceptable effort.

The event-driven architecture complements the service-oriented architecture, as services can be triggered by events. Based on the event-driven architecture systems can be developed for event-driven process chains in particular.

Flow of events

An event usually consists of three lines: the creation time (time stamp), the triggering component (source) and the event type (type ) that indicates what happened in essence. Often, the event type is not defined by a specific type of programming language, but. Ized by hierarchical event theme, for example in the form of a pseudo - URIs such as topic :/ / Options dialog / Controls / AcceptButton / click

Events are event handlers (event handlers ) intercepted that are implemented with object orientation in methods or with your own classes. Is a routine for an intercepted event type responsible, it initiates appropriate processing steps. Regardless, the routine may pass the event to other routines or Mark or discard as done.

Events are no messages that are sent targeted to specific components, but the system will be to some extent "blind" pass. An event can trigger actions at one or more points in the system, but are also completely ignored discarded ( because no processing routine has been identified as responsible for the event ). Since the timing and order in which an event reaches various components are generally not initially set, the routines in each independent, completed tasks from work. Event-driven architecture is so designed in principle to parallel processing.

Modeling

The event-driven architecture is based on four logical levels. It begins with the triggering of an event and ends with an arbitrary response 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. Examples include business intelligence solutions, e- mail clients, CRM systems or DMS systems. In addition, sensors - for example, temperature sensor, tachometer or microphones - trigger the event. To convert the data collected from the used event producers in a uniform format to be used, is the greatest challenge in the development and introduction of this level dar.

Event carrier (event channel)

As an event, the carrier medium is known, transmits the information about the event to the event rules. This medium is often simply an area in the main memory of the computer (ie the entry point of the method or routine to handle the event ). But it can (for example, sensors ) can also be a cable, as well as get a database, TCP / IP connection or any file (flat, XML, etc.) in question. Any number of event support can be active and at the same.

Event processing rules (event processing engine)

The event rules identifies, classifies and processes the event. For the identification, it is necessary that the control station monitors the arrival of events. Subsequently, the event is classified based on the event type. Each classified event is assigned a set of rules that is run after the occurrence of the particular event. The rules are implemented by program code, but can also be stored in relational databases through SQL statements, in particular workflow management systems or special control software. In the development of this layer is to be noted that as far as possible automatism is achieved. After passing through the rules may lead to the potential a new event, which in turn - as another event - passes through another set of rules.

Event activity (downstream event-driven activity )

In this layer, the response to the event, such as the dispatch of a letter, the triggering of a sound signal, the emergency shutdown of a machine is, etc.

Types of event-driven processing

The event-driven architecture distinguishes three types of processes: simple, continuously and complex. In event-driven systems usually come before all three process types.

Simple event processing (simple event processing)

Simple event-driven processes trigger directly from specific results. If, for example, each customer will receive a birthday card, so you can for example via SQL query selects all affected customers, the address data associated with a form letter template and pressure are raised.

Processing of event streams (event stream processing )

Event Stream Processing (short: ESP, German: , processing of event streams ') is the umbrella term for a set of technologies for visualization and storage of events for event-driven middleware and event processing languages.

Complex event processing (complex event processing)

If several events that are in a causal, spatial, or short-term context, combined in a common process, we speak of a complex event-driven process. In a complex event-driven process, a structure is needed that identifies the respective key event from the list and edited down to the next step in the rule set. The development of event producers, event sources and the definition of the rules for complex event-driven processes designed to challenging usually. A potential field of application for CEP in practice is, for example, the monitoring function of Supply Chain Event Management ( SCEM ) systems is: CEP can help companies by analyzing the increasingly growing in supply chain management data volume (eg through the increased use of Advanced Planning and Scheduling systems, tracking and tracing systems, RFID infrastructures, etc.) to detect critical differences in the supply chain.

Decoupling of components

For loose coupling of software components "knows" the component A, the functionality of a further component B used, on the disclosure of the interface, although nothing of the interior, that is the specific implementation of the functionality of component B, but some of the signatures of the methods that provide these functionalities. In a purely event-driven system, this knowledge is no longer necessary, as events, as shown above, "blind" and " in the air " can be triggered. However, the event producer must not in accordance assured that the event ever observed anywhere elsewhere in the system, collected and processed is so far as the execution of the event producer must be independent of handling the event. ( This requirement is, however, notwithstanding the fact that the non -observance of an event may affect the functionality of the software product. )

Universal connecting systems

The event-driven architecture allows compact connection of systems and can be used universally. The advantage of this open architecture: An event can be anything and can appear anywhere. When an event occurs, however, are often not regulated, is how to deal with the event. The approach to determine the cause of business transactions in specially defined events, leading to a plethora of options can be derived from the target is controlled organizational models.