Event Driven Architecture

Eine Ereignisgesteuerte Architektur (von engl. Event-Driven Architecture, EDA) ist ein Softwarearchitektur-Muster, in dem das Zusammenspiel der Komponenten durch Ereignisse (Events) gesteuert wird.

Ereignisse (Events)

Hauptartikel: Ereignis (Programmierung)

Als Event versteht man ein Ereignis, das sowohl von außen (z.B. Benutzereingaben), als auch vom System selbst (z.B. Änderungsbenachrichtigung) ausgelöst werden kann. Zu beachten ist, dass man im Fachgebiet der ereignisgesteuerten Architektur unter Event immer die Software-mäßige Abbildung des tatsächlichen Ereignisses meint und nicht das Ereignis selbst.

Ein Ereignis kann Auslöser (Trigger) für eine Ereignisbehandlung (Event Handling) sein, mit der das System reagiert. Eine ereignisgesteuerte Architektur hat kaum Kontrolle darüber, wann Daten verarbeitet werden. Ein einfaches Beispiel ist die grafische Benutzeroberfläche: Hier bestimmt der Benutzer, wann welche Daten verarbeitet werden, indem er Aktionen ausführt und damit Ereignisse auslöst.

Der Einsatz dieser Architektur setzt bei der Planung und Entwicklung voraus, dass alle Systeme, die an der Abwicklung des Ereignisses beteiligt sind, miteinander kommunizieren können. Typischerweise setzt die Ereignisgesteuerte Architektur eine Definition voraus, was als Ereignis anzusehen ist. Dafür überwachen Computersysteme oder Sensoren den Status von Objekten und können gegebenenfalls ein Ereignis auslösen. Es folgt die Verarbeitung des Ereignisses nach definierten Regeln und die Folge des Ereignisses. Ist es während der Ereignisverarbeitung nicht möglich, sofort die definierte Folge des Ereignisses zu erzielen, wird das Ereignis im erreichten Status zwischengespeichert und erst weitergeführt, wenn die Folge erreicht werden kann.

Den größten Nutzen erreicht die Ereignisgesteuerte Architektur, wenn sie bereits in der Planungsphase berücksichtigt wird. Bereits vorhandene Lösungen auf eine Ereignisgesteuerte Architektur umzustellen, kann mangels der benötigten Schnittstellen zu inakzeptablem Aufwand führen.

Die Ereignisgesteuerte Architektur ergänzt die Serviceorientierte Architektur, da Dienste durch Impulse, wie zum Beispiel Ereignisse ausgelöst werden können. Auf Basis der ereignisgesteuerten Architektur können insbesondere Systeme für Ereignisgesteuerte Prozessketten entwickelt werden.

Ereignisfluss

Ein Ereignis umfasst mindestens drei Angaben: Den Erstellungszeitpunkt (Zeitstempel), die auslösende Komponente (Quelle) und die Art des Ereignisses (Typ), die angibt, was im Wesentlichen vorgefallen ist. Ereignisse werden von Ereignisbehandlungsroutinen (event handlers) abgefangen, die bei Objektorientierung eigene Klassen darstellen. Ist eine Routine für einen abgefangenen Ereignistyp verantwortlich, so stößt sie passende Verarbeitungsschritte an. Unabhängig davon kann die Routine das Ereignis an andere Routinen weiterreichen oder als erledigt markieren und verwerfen.

Ereignisse sind keine Nachrichten, die zielgerichtet an bestimmte Komponenten versandt werden, sondern werden dem System gewissermaßen „blind“ übergeben. Ein Ereignis kann an einer oder mehreren Stellen im System Aktionen auslösen, aber auch völlig unbeachtet verworfen werden. Da Zeitpunkt und Reihenfolge, in der ein Ereignis verschiedene Komponenten erreicht, mitunter nicht vorhersehbar sind, arbeiten die Routinen jeweils unabhängige, abgeschlossene Aufgaben ab.

Modellierung

Die Ereignisgesteuerte Architektur basiert auf vier logischen Ebenen. Sie beginnt mit dem Auslösen eines Ereignisses und endet mit einer beliebigen Reaktion auf das Ereignis. Auch Sequenzdiagramme und ähnliche Prozessflussdiagramme dienen dem Entwurf solcher Systeme.

Ereignis-Produzent (Event Generator)

Die erste logische Ebene dieser Architektur ist der Ereignis Produzent (event generator), der den Status eines Objektes überwacht. Ereignisse können von jeder beliebigen Software produziert werden, die zur Statusüberwachung eingesetzt werden kann. Beispielhaft seien Business Intelligence Lösungen, E-Mail-Clients, CRM-Systeme oder DMS-Systeme genannt. Darüber hinaus können Sensoren – beispielsweise Temperaturfühler, Drehzahlmesser oder Mikrofone – das Ereignis auslösen. Die unterschiedlichen Daten aus den verwendeten Ereignis Produzenten in ein einheitliches, zu verwendendes Format zu konvertieren, stellt bei der Entwicklung und Einführung dieser Ebene die größte Herausforderung dar.

Ereignis-Träger (Event Channel)

Als Ereignis Träger wird der Mechanismus bezeichnet, der die Informationen über das Ereignis an das Ereignis Regelwerk überträgt. In der Regel wird es sich um ein Kabel, eine Datenbank, eine TCP/IP-Verbindung oder eine beliebige Datei (flat, XML, etc.) handeln. Beliebig viele Ereignis Träger können gleichzeitig aktiv sein und werden, für die weitere Verwendung im Prozess Regelwerk, in einer Warteschlange zwischengespeichert. Diese Warteschlange kann sich im Dateisystem oder in einer relationalen Datenbank befinden.

Ereignis-Verarbeitungs-Regelwerk (Event Processing Engine)

Das Ereignis Regelwerk identifiziert, klassifiziert und verarbeitet das Ereignis. Zur Identifikation ist es notwendig, dass ein Trigger die Warteschlange überwacht. Anschließend wird anhand der Kopfzeile das Ereignis klassifiziert. Jedem klassifizierten Ereignis ist ein Regelwerk zugeordnet, dass nach Auftreten des bestimmten Ereignisses durchlaufen wird. Die Regelwerke können in relationalen Datenbanken durch SQL Statements, sonst auch in speziellen Workflow-Management-Systemen oder spezieller Steuerungssoftware hinterlegt werden. Bei der Entwicklung dieser Schicht ist zu beachten, dass ein möglichst weitgehender Automatismus erreicht wird. Nach Durchlaufen des Regelwerks kann unter Umständen ein neues Ereignis entstehen, dass wiederum – als anderes Ereignis – das Regelwerk durchläuft.

Ereignis Aktivität (Downstream event-driven activity)

In dieser Schicht erfolgt die Reaktion auf das Ereignis. Die Darstellung kann in einer Anwendungsoberfläche erfolgen. Es können aber auch automatisierte Verfahren ausgelöst werden. Beispielsweise der Versand eines Briefes, das Auslösen eines Tonsignals, die Steuerung einer Maschine usw.

Arten von ereignisgesteuerter Verarbeitung

Die ereignisgesteuerte Architektur unterscheidet drei Arten von Prozessen: einfach, durchlaufend und komplex. In Ereignisgesteuerten Systemen kommen in der Regel alle drei Prozessarten vor.

Einfache Ereignis-Verarbeitung (Simple event processing)

Einfache ereignisgesteuerte Prozesse lösen direkt spezifische, messbare Ergebnisse aus. Soll beispielsweise jeder Kunde eine Geburtstagskarte erhalten, so können per SQL Abfrage alle betroffenen Kunden selektiert, die Adressdaten mit einer Serienbriefvorlage verbunden und der Druck ausgelöst werden.

Verarbeitung von Ereignisströmen (Event Stream Processing)

Event Stream Processing (kurz: ESP, deutsch: Verarbeitung von Ereignisströmen) ist der Überbegriff für eine Menge von Technologien zur Visualisierung und Abspeicherung von Ereignissen, für Ereignisgesteuerte Middleware und auch Ereignis-Verarbeitung-Sprachen.

Verarbeitung komplexer Ereignisse (Complex Event Processing)

Hauptartikel: Complex Event Processing

Werden mehrere Ereignisse, die in einem ursächlichen, räumlichen oder kurzfristigen Zusammenhang stehen, in einem gemeinsamen Prozess zusammengefasst, spricht man von einem komplexen ereignisgesteuerten Prozess. In einem komplexen ereignisgesteuerten Prozess ist eine Struktur erforderlich, die das jeweils entscheidende Ereignis aus der Sammlung identifiziert und bis zum nächsten Schritt im Regelwerk bearbeitet. Die Entwicklung von Ereignis Produzenten, Ereignis Trägern und die Definition des Regelwerks für komplexe ereignisgesteuerte Prozesse wird sich in der Regel anspruchsvoll gestalten.

Universelle Verbindung von Systemen

Die Ereignisgesteuerte Architektur erlaubt die kompakte Verbindung von Systemen und ist universell einsetzbar. Der Vorteil dieser offenen Architektur: Ein Ereignis kann alles sein und kann überall auftreten. Bei Auftreten eines Ereignisses ist häufig jedoch nicht geregelt, wie mit dem Ereignis umgegangen werden soll. Die Herangehensweise, die Ursache von Geschäftsvorgängen in eigens definierten Ereignissen zu suchen, führt zu einer Fülle von Optionen, aus der sich zielgesteuerte Organisationsmodelle ableiten lassen.

Artikel

• Artikel zur Vorstellung eines "Rule Management Systems" in EDA: Event-Driven Rules for Sensing and Responding to Business Situations by J. Schiefer, S. Rozsnyai, C. Rauscher, G. Saurer.