Ereignisgesteuerte Architektur

Eine ereignisgesteuerte Architektur, auch Event-driven Architecture, ist eine Softwarearchitektur, in der das Zusammenspiel der Komponenten durch Ereignisse gesteuert wird.

Ereignisse

→ Hauptartikel: Ereignis (Programmierung)

Ereignisse können sowohl von außen, z. B. durch Benutzereingaben oder Sensorwerte, als auch vom System selbst (z. B. Änderungsbenachrichtigungen) ausgelöst werden.

Ein Ereignis kann Auslöser für eine Ereignisbehandlung 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 folgen 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 dann weitergeführt, wenn die Folge erreicht werden kann.

Den größten Nutzen hat die ereignisgesteuerte Architektur, wenn sie bereits in der Planungsphase berücksichtigt wird. Bereits vorhandene Software 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 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 meist drei Angaben: den Erstellungszeitpunkt (Zeitstempel), die auslösende Komponente (Quelle) und die Art des Ereignisses (Typ), die angibt, was im Wesentlichen vorgefallen ist. Häufig wird der Ereignistyp nicht durch einen spezifischen Typ der jeweiligen Programmiersprache festgelegt, sondern durch hierarchisiertes Ereignisthema, beispielsweise in Form eines Pseudo-URIs wie etwa topic://OptionsDialog/Controls/AcceptButton/Click

Ereignisse werden von Ereignisbehandlungsroutinen (event handlers) abgefangen, die bei Objektorientierung in Methoden oder auch eigenen Klassen implementiert werden. 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 oder 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 (weil keine verarbeitende Routine als verantwortlich für das Ereignis gekennzeichnet wurde). Da Zeitpunkt und Reihenfolge, in der ein Ereignis verschiedene Komponenten erreicht, grundsätzlich zunächst nicht festgelegt sind, arbeiten die Routinen jeweils unabhängige, abgeschlossene Aufgaben ab. Ereignisgesteuerte Architektur ist also prinzipiell auf Parallelverarbeitung ausgelegt.

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. Sequenzdiagramme und ähnliche Prozessflussdiagramme dienen dem Entwurf solcher Systeme.

Ereignis-Produzent (event generator)

Die erste logische Ebene dieser Architektur ist der Ereignisproduzent (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 Ereignisproduzenten 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 Ereignisträger wird das Medium bezeichnet, das die Informationen zum Ereignis an das Ereignisregelwerk überträgt. Dieses Medium ist häufig einfach ein Bereich im Hauptspeicher des Rechners (d. h. die Einsprungadresse der Methode oder Routine, die das Ereignis verarbeiten). Es kann aber (z. B. bei Sensoren) auch ein Kabel sein, ebenso kommen eine Datenbank, eine TCP/IP-Verbindung oder eine beliebige Datei (flat, XML etc.) in Frage. Beliebig viele Ereignisträger können gleichzeitig aktiv sein und werden.

Ereignis-Verarbeitungs-Regelwerk (event processing engine)

Das Ereignisregelwerk identifiziert, klassifiziert und verarbeitet das Ereignis. Zur Identifikation ist es notwendig, dass das Regelwerk das Eintreffen von Ereignissen überwacht. Anschließend wird das Ereignis anhand des Ereignistyps klassifiziert. Jedem klassifizierten Ereignis ist ein Regelwerk zugeordnet, das nach Eintreten des bestimmten Ereignisses durchlaufen wird. Die Regelwerke werden durch Programmcode implementiert, können aber auch in relationalen Datenbanken durch SQL-Statements, 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, das wiederum – als anderes Ereignis – ein weiteres Regelwerk durchläuft.

Ereignis-Aktivität (downstream event-driven activity)

In dieser Schicht erfolgt die Reaktion auf das Ereignis, beispielsweise der Versand eines Briefes, das Auslösen eines Tonsignals, die Not-Abschaltung 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 Ergebnisse aus. Soll beispielsweise jeder Kunde eine Geburtstagskarte erhalten, so können etwa 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 Liste identifiziert und bis zum nächsten Schritt im Regelwerk bearbeitet. Die Entwicklung von Ereignisproduzenten, Ereignisträgern und die Definition des Regelwerks für komplexe ereignisgesteuerte Prozesse gestaltet sich in der Regel anspruchsvoll. Ein potenzielles Einsatzfeld für CEP in der betrieblichen Praxis stellt z. B. die Monitoring-Funktion von Supply Chain Event Management (SCEM)-Systemen dar: CEP kann Unternehmen helfen, durch Analyse des im Supply-Chain-Management zunehmend anwachsenden Datenvolumens (u. a. durch den verstärkten Einsatz von Advanced-Planning-and-Scheduling-Systemen, Tracking-&-Tracing-Systemen, RFID-Infrastrukturen etc.) kritische Abweichungen in der Lieferkette zu erkennen.

Entkopplung von Komponenten

Bei loser Kopplung von Software-Komponenten „weiß“ die Komponente A, welche die Funktionalität einer weiteren Komponente B nutzt, über die Offenlegung der Schnittstelle zwar nichts mehr vom Innenleben, also der konkreten Implementierung der Funktionalität der Komponente B, aber doch etwas über die Signaturen der Methoden, die diese Funktionalitäten bereitstellen. In einem rein ereignisorientierten System ist dieses Wissen nicht mehr nötig, da Ereignisse, wie oben dargestellt, „blind“ und „in die Luft“ ausgelöst werden können. Der Ereignisproduzent darf sich jedoch entsprechend nicht darauf verlassen, dass das Ereignis überhaupt irgendwo an anderer Stelle im System beachtet, aufgefangen und bearbeitet wird insofern, als der Programmablauf des Ereignisproduzenten unabhängig von einer Behandlung des Ereignisses sein muss. (Diese Forderung ist unabhängig davon, dass das Nicht-Beachten eines Ereignisses möglicherweise die Funktionalität des Softwareprodukts beeinträchtigt.)

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.

Literatur

• Ralf Bruns, Jürgen Dunkel: Event-Driven Architecture. Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse, X.pert Press (Springer) 2010, ISBN 978-3-642-02438-2
• Thomas Buckel: Zum Potential von Event-Driven Architecture für komplexe Unternehmensnetzwerke, in: Dirk Christian Mattfeld, Susanne Robra-Bissantz (Hrsg.): Multikonferenz Wirtschaftsinformatik 2012, Tagungsband der 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, S. 198–205 (Online bei CiteSeer – Vorstellung eines „Rule Management Systems“ in EDA).