Event-Driven Architecture: Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse (Xpert.press)

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Managem...

Author: Ralf Bruns | Jürgen Dunkel

29 downloads 1074 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Ralf Bruns · Jürgen Dunkel

Event-Driven Architecture Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse

123

Prof. Dr. Ralf Bruns Fachhochschule Hannover Abteilung Informatik Ricklinger Stadtweg 120 30459 Hannover Germany [email protected]

Prof. Dr. Jürgen Dunkel Fachhochschule Hannover Abteilung Informatik Ricklinger Stadtweg 120 30459 Hannover Germany [email protected]

ISSN 1439-5428 ISBN 978-3-642-02438-2 e-ISBN 978-3-642-02439-9 DOI 10.1007/978-3-642-02439-9 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet u¨ ber http://dnb.d-nb.de abrufbar. c Springer-Verlag Berlin Heidelberg 2010 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der ¨ Ubersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: KuenkelLopka GmbH Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Für Maria und Fritz Bruns, Keno, Lara und Sabine! Für Cristina!

Vorwort

Eine Vielzahl von internen und externen Ereignissen beeinflusst die Abläufe und Geschäftsprozesse in Unternehmen – eine Warenlieferung trifft verspätet ein, ein Kunde annulliert seine Bestellung, ein Temperatursensor misst einen erhöhten Wert oder eine Fertigungsmaschine fällt aufgrund eines Defekts aus. Die Unternehmen sind gezwungen, auf diese Ereignisse angemessen und möglichst zeitnah zu reagieren – die Unternehmen agieren demnach ereignisgesteuert. Ereignissteuerung in Unternehmen ist heutzutage eine selbstverständliche Praxis und Bestandteil der natürlichen Arbeitsweise von Unternehmen. Gegenstand des Buches Event-Driven Architecture (EDA) als Architekturstil und Complex Event Processing (CEP) als Softwaretechnologie rücken Ereignisse als zentrales Strukturierungskonzept in den Fokus der Softwarearchitektur. Die resultierenden ereignisgesteuerten Anwendungssysteme ermöglichen eine realitätsnahe Abbildung der ereignisgesteuerten Geschäftsprozesse eines Unternehmens. Ereignisse werden identifiziert, transformiert, korreliert und bewertet. Ereignisströme werden analysiert, komplexe Sequenzen von Ereignissen mit kausalen, temporalen und räumlichen Bedingungen erkannt sowie fachliche Aktionen abgeleitet, die aus diesen Ereignismustern resultieren. Obwohl die Ereignisse häufig in extrem großen Volumina auftreten können, steht mit Complex Event Processing eine leistungsfähige Technologie zur Verfügung, um diese in Echtzeit zu verarbeiten. Event-Driven Architecture als Architekturstil für Unternehmensanwendungen verfolgt das Ziel, die Agilität, Reaktionsfähigkeit und Echtzeitfähigkeit der Geschäftsprozesse eines Unternehmens zu erhöhen. Die Ereignisorientierung stellt einen wichtigen Schritt dar, um die bestehende Diskrepanz zwischen den realen Geschäftsprozessen und deren informationstechnischer Unterstützung zu vermindern. Event-Driven Architecture in Verbindung mit Complex Event Processing ermöglicht eine neue Qualität von Unternehmensanwendungen.

vii

viii

Vorwort

Ziele des Buches Dieses Buch widmet sich ausführlich dem Thema Event-Driven Architecture und seiner fortgeschrittensten Form, dem Complex Event Processing. Es behandelt das Thema aus drei unterschiedlichen Sichtweisen, die gemeinsam eine umfassende Gesamtsicht dieser noch sehr jungen, aber zukunftsweisenden Form von Softwarearchitektur vermitteln sollen: 1. Fachliche Sicht: Welchen Nutzen bringt EDA für ein Unternehmen? Bei Event-Driven Architecture handelt es sich um einen neuen Ansatz mit enormem fachlichen Potenzial. Das Potenzial wollen wir herausarbeiten, die Grenzen konventioneller Ansätze aufzeigen und besonders aussichtsreiche Anwendungsgebiete für EDA identifizieren. 2. Konzeptionelle Sicht: Was verbirgt sich softwaretechnisch hinter EDA? Die zentralen Ideen und Konzepte von EDA und CEP werden sowohl auf einer konzeptionellen als auch detailliert auf einer technischen Ebene erläutert. So ergibt sich ein vollständiges Gesamtbild der technologischen Grundlagen und es bildet sich ein tiefes Verständnis der konkreten Umsetzung. 3. Praktische Sicht: Wie können EDA-Anwendungen realisiert werden? Noch existieren relativ wenige EDA-Anwendungen im produktiven Einsatz in der Wirtschaft und folglich liegt wenig Erfahrungswissen vor. Anhand eines durchgehenden Fallbeispiels lässt sich die praktische Anwendung der Ereignisverarbeitung schrittweise nachvollziehen. Auch wesentliche Methoden für den Entwurf und die Entwicklung von professionellen EDA-Anwendungen werden vorgestellt. Insgesamt betrachtet, spannt dieses Buch den Bogen vom fachlichen Nutzen über die technischen Hintergründe bis zum praktischen Einsatz und liefert somit eine fundierte und umfassende Sicht auf das Thema Event-Driven Architecture. Leserkreis Das Buch wendet sich an einen breiten Leserkreis: Einerseits an Entscheidungsträger, Softwarearchitekten und Softwareentwickler aus der betrieblichen Praxis, die in ihren Unternehmen ereignisgesteuerte Geschäftsprozesse durch moderne und zukunftsfähige Softwaresysteme unterstützen müssen. Andererseits an Studierende und Hochschullehrer/innen der Informatik sowie der Wirtschaftsinformatik, die einen praxisbezogenen Einblick in die grundlegenden Konzepte von ereignisorientierten Softwarearchitekturen und deren praktischer Umsetzung erhalten möchten. Aufbau des Buches Teil I – Event-Driven Architecture – Einführung führt umfassend in die Thematik der Ereignisverarbeitung als dynamischer Architekturstil für Unternehmensanwendungen ein. Die große fachliche Bedeutung von Ereignissen für Unternehmensanwendungen wird aufgezeigt, auf die Unzulänglichkeiten von konventionellen Softwarearchitekturen in diesem Kontext eingegangen und das fachliche Potenzial der

Vorwort

ix

Ereignisorientierung herausgestellt. Es werden die grundlegenden Ideen, Prinzipien und Konzepte von Event-Driven Architecture und Complex Event Processing vorgestellt, bewertet und aussichtsreiche Anwendungsgebiete identifiziert. Dieser Teil des Buches wählt eine nichttechnische Betrachtungsweise, so dass die Leser, die nicht so sehr an der technischen Umsetzung interessiert sind, durch diesen Teil einen Gesamtüberblick über Event-Driven Architecture erhalten und das fachliche Potenzial einschätzen können. Teil II – Complex Event Processing – Konzepte vertieft die konzeptionellen Inhalte aus Teil I systematisch, indem Complex Event Processing als die zentrale Technologie einer Event-Driven Architecture ausführlich und detailliert vorgestellt wird. Die Repräsentation von Ereignissen durch Ereignismodelle, die Verarbeitung von Ereignissen mittels Ereignismustern und -regeln, der Aufbau einer CEP-Anwendung als Netzwerk von interagierenden, ereignisverarbeitenden Komponenten sowie die Behandlung der Ereignisse in den nachgelagerten Anwendungssystemen werden Schritt für Schritt erläutert. Die konkrete technische Umsetzung der präsentierten Konzepte wird einerseits anhand einer vereinfachten Regelsprache für die Ereignisverarbeitung, andererseits anhand der Open-Source-CEP-Engine Esper vorgestellt. Ein durchgehendes Fallbeispiel aus dem Bereich Verkehrskontrolle und -steuerung verdeutlicht exemplarisch, wie die vorgestellten Konzepte in einem größeren fachlichen Zusammenhang eingesetzt werden. Teil III – Entwurfsmuster und Architekturen für EDA stellt wichtige Konzepte für die professionelle Entwicklung von EDA-Anwendungen in der Praxis vor. Softwareentwicklungsprojekte im industriellen Maßstab sind äußerst komplexe Vorhaben. Das gilt selbstverständlich auch für EDA-Projekte. Diese Komplexität besteht auf zwei Ebenen: 1. Systemkomplexität: Wie wird das System richtig gebaut? 2. Prozesskomplexität: Wie wird der Entwicklungsprozess richtig gestaltet? Mit Entwurfsmustern und Referenzarchitekturen für EDA-Anwendungen werden in diesem Teil wesentliche Konzepte für den Entwurf und die Entwicklung von EDA-Anwendungen behandelt. Sowohl Entwurfsmuster als auch Referenzarchitekturen repräsentieren wichtiges Erfahrungswissen, um ein ereignisgesteuertes System richtig zu bauen, also um die Systemkomplexität zu beherrschen. Für die Gestaltung des Entwicklungsprozesses, also um die Prozesskomplexität zu beherrschen, werden Vorgehensschritte und ein Vorgehensmodell vorgestellt, die auf die spezifischen Anforderungen von ereignisgesteuerten Systemen zugeschnitten sind. Teil IV – Stand, Zusammenfassung und Ausblick beschließt das Buch. Der erreichte Entwicklungsstand von Event-Driven Architecture wird beleuchtet, die wichtigsten Inhalte des Buches zusammengefasst und ein Ausblick auf die Einführung von EDA in die Praxis gegeben.

x

Vorwort

Webseite zum Buch Natürlich gibt es auch eine Webseite zum Buch, auf der zusätzliche Informationen zum Buch sowie zu den Themen Event-Driven Architecture und Complex Event Processing bereitgestellt sind. Die URL der Seite lautet:

http://event-driven-architecture.org

Auf dieser Seite finden Sie unter anderem: • Dateien mit den Source-Code-Beispielen aus dem Buch • interessante Links zu den Themen EDA und CEP • Links zu wichtigen kommerziellen Herstellern von EDA-Plattformen und OpenSource-Produkten für CEP Für weitere Fragen, Hinweise auf Fehler, Meinungen und Anregungen stehen wir Ihnen sehr gerne zur Verfügung. Unsere Kontaktdaten finden Sie auf der Webseite. Entstehung und Danksagung Der Anstoß zu diesem Buch kam durch unsere Arbeiten im Bereich Softwarearchitektur in der Abteilung Informatik der Fachhochschule Hannover. Erste Berührungspunkte mit Event-Driven Architecture und Complex Event Processing ergaben sich über Abschlussarbeiten. Wir waren sofort von dem Thema überzeugt, so dass es zunächst Einzug in unsere Lehrveranstaltungen fand und schließlich zu Kooperationsprojekten mit industriellen Partnern führte. Wir hoffen mit dem vorliegenden Buch die Aufmerksamkeit für die Ereignisverarbeitung als Architekturstil zu erhöhen und damit einen Beitrag für die weitere Entwicklung des Themengebiets zu leisten. Es würde uns sehr freuen, wenn EventDriven Architecture in Zukunft einen signifikanten Platz im Kanon der Architekturkonzepte für die Entwicklung von zukunfts- und leistungsfähigen Anwendungsarchitekturen in der betrieblichen Praxis einnehmen würde. Zum Schluss möchten wir uns ganz besonders bei unseren Familien bedanken, die uns in den vergangenen Monaten mit so viel Geduld unterstützt haben – danke euch allen! Hannover, Dezember 2009

Ralf Bruns Jürgen Dunkel

Inhaltsverzeichnis

Teil I Event-Driven Architecture – Einführung 1

Einführung und Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 EDA und CEP – Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Historischer Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 5 9

2

Ereignisse in Unternehmensanwendungen . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Bedeutung von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Ereignisgesteuerte Geschäftsprozesse . . . . . . . . . . . . . . . . . . . 2.1.2 Herausforderungen im Umgang mit Ereignissen . . . . . . . . . . 2.1.3 Ereignismuster und -abstraktion . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Grenzen von konventionellen Softwarearchitekturen . . . . . . . . . . . . . 2.2.1 Geschäftssicht in konventionellen Architekturen . . . . . . . . . . 2.2.2 Technologiesicht in konventionellen Architekturen . . . . . . . . 2.3 Ereignisorientierung als Architekturstil . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Geschäftssicht in ereignisorientierten Architekturen . . . . . . . 2.3.2 Technologiesicht in ereignisorientierten Architekturen . . . . . 2.3.3 Fachliche Gesamtsicht der Ereignisorientierung . . . . . . . . . . . 2.4 EDA und SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Grundidee von SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Gegenüberstellung von SOA und EDA . . . . . . . . . . . . . . . . . . 2.4.3 SOA + EDA = Event-Driven SOA . . . . . . . . . . . . . . . . . . . . . . 2.5 Anwendungsgebiete für EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Sensornetzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 Analytik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.4 Enterprise Application Integration . . . . . . . . . . . . . . . . . . . . . .

13 13 14 15 18 23 24 26 28 28 30 31 34 34 36 38 39 40 41 44 45

xi

xii

3

Inhaltsverzeichnis

Event-Driven Architecture und Complex Event Processing im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 EDA – Grundkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Ereignisse – Ereignisgesteuert – EDA . . . . . . . . . . . . . . . . . . . 3.1.2 EDA mit CEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 EDA-Architektur und -schichten . . . . . . . . . . . . . . . . . . . . . . . 3.2 CEP – Grundkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Ereignismodelle, -muster und -regeln . . . . . . . . . . . . . . . . . . . 3.2.2 Netzwerk von CEP-Komponenten . . . . . . . . . . . . . . . . . . . . . . 3.3 EDA – Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Fallstudie: Verkehrskontrolle und -steuerung . . . . . . . . . . . . . . . . . . . .

47 47 48 56 61 65 66 68 72 76

Teil II Complex Event Processing – Konzepte 4

Ereignismodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Ereignisse und Ereignisströme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Ereignisbeziehungen und -hierarchien . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Ereignis-Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Fallstudie: Verkehrskontrolle und -steuerung . . . . . . . . . . . . . . . . . . . .

85 85 91 95 97 99

5

Ereignisverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.1 Regeln zur Ereignisverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.2 Konzepte zur Beschreibung von Ereignismustern . . . . . . . . . . . . . . . . 108 5.3 Aktionen in Ereignisregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.4 Ereignisregeln mit Esper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.4.1 Ereignisse in Esper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.4.2 Aufbau von Ereignisregeln in Esper . . . . . . . . . . . . . . . . . . . . . 128 5.4.3 Ereignismuster in Esper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.4.4 Aktionen in Esper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.5 Event Processing Agents und Event Processing Engines . . . . . . . . . . 139 5.6 Event Processing Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 5.7 Realisierungsplattformen und Sprachtypen . . . . . . . . . . . . . . . . . . . . . 145 5.8 Fallstudie: Verkehrskontrolle und -steuerung . . . . . . . . . . . . . . . . . . . . 149 5.8.1 Event Processing Network des Verkehrskontrollsystems . . . . 149 5.8.2 Ereignisregeln im Verkehrskontrollsystem . . . . . . . . . . . . . . . 153

6

Ereignisbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.1 Aufgaben der Ereignisbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.2 Integration der CEP-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 6.3 Ereignisgesteuerte Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.4 Visualisierung von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 6.5 Erzeugen von Geschäftsereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 6.6 Fallstudie: Verkehrskontrolle und -steuerung . . . . . . . . . . . . . . . . . . . . 172

Inhaltsverzeichnis

xiii

Teil III Entwurfsmuster und Architekturen für EDA 7

Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.1 Muster in Event-Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.2 Architekturmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 7.2.1 EDA-Schichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 7.2.2 Ereignisagenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 7.2.3 Verarbeitungs-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 7.3 Designmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 7.3.1 Konsistenz von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 7.3.2 Reduktion der Ereignismenge . . . . . . . . . . . . . . . . . . . . . . . . . . 188 7.3.3 Transformation von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . 191 7.3.4 Synthese von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

8

Referenzarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 8.1 Referenzarchitekturen für Event-Driven Architecture . . . . . . . . . . . . . 201 8.2 Allgemeine Referenzarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8.3 EDA für Sensornetzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 8.4 EDA für Analysesysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

9

Vorgehen bei der Entwicklung von EDA-Anwendungen . . . . . . . . . . . . 213 9.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.2 Prozessschritte für EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.3 Vorgehensmodell für EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Teil IV Stand, Zusammenfassung und Ausblick 10 Stand, Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . 223 10.1 Aktueller Entwicklungsstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 10.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.3 Ausblick: Einführung von EDA in die Praxis . . . . . . . . . . . . . . . . . . . . 226 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Abkürzungen

API BAM BI BPEL BPM BPMN CEP CQL CRM CSV EAI ECA EDA EPA EPL EPN EQL ESB ESP FIFO GPS GUI HTTP JMS LUW MOM OCL OWL POJO RDF RDF-S

Application Programming Interface Business Activity Monitoring Business Intelligence Business Process Execution Language Business Process Management Business Process Modeling Notation Complex Event Processing Continuous Query Language Customer Relationship Management Comma-Separated Value Enterprise Application Integration Event-Condition-Action Event-Driven Architecture Event Processing Agent Event Processing Language Event Processing Network Esper Query Language Enterprise Service Bus Event Stream Processing First-In-First-Out Global Positioning System Graphical User Interface Hypertext Transfer Protocol Java Message Service Logical Unit of Work Message-oriented Middleware Object Constraint Language Web Ontology Language Plain Old Java Object Resource Description Framework RDF Schema xv

xvi

RFID RIF RMI RPC SLA SOA SQL WSDL XML

Abkürzungen

Radio Frequency Identification Rule Interchange Format Remote Method Invocation Remote Procedure Call Service Level Agreement Service-oriented Architecture Structured Query Language Web Services Description Language Extensible Markup Language

Teil I

Event-Driven Architecture – Einführung

Teil I – Event-Driven Architecture – Einführung führt umfassend in die Thematik der Ereignisverarbeitung als dynamischer Architekturstil für Unternehmensanwendungen ein. Die große fachliche Bedeutung von Ereignissen für Unternehmensanwendungen wird aufgezeigt, auf die Unzulänglichkeiten von konventionellen Softwarearchitekturen in diesem Kontext eingegangen und das fachliche Potenzial der Ereignisorientierung herausgestellt. Es werden die grundlegenden Ideen, Prinzipien und Konzepte von Event-Driven Architecture und Complex Event Processing vorgestellt, bewertet und aussichtsreiche Anwendungsgebiete identifiziert. Dieser Teil des Buches wählt eine nichttechnische Betrachtungsweise, so dass die Leser, die nicht so sehr an der technischen Umsetzung interessiert sind, durch diesen Teil einen Gesamtüberblick über Event-Driven Architecture erhalten und das fachliche Potenzial einschätzen können. Kapitel 1 – Einführung und Motivation leitet in die Thematik der komplexen Ereignisverarbeitung ein. Es wird aufgezeigt, dass die Verarbeitung von Ereignissen für die realen Prozesse in Unternehmen und die Kommunikationsvorgänge zwischen Unternehmen alltägliche und gängige Praxis sind und sich daraus die Motivation für einen neuen, ereignisorientierten Stil der Softwarearchitektur ableitet. Die historische Entwicklung ereignisverarbeitender Systeme in der Informatik wird betrachtet und die jeweiligen Einflüsse auf EDA und CEP identifiziert. Kapitel 2 – Ereignisse in Unternehmensanwendungen beleuchtet das Thema Ereignisorientierung primär aus fachlicher Sicht. Die fachliche Bedeutung von Ereignissen für die Geschäftsprozesse eines Unternehmens ist Gegenstand dieses Kapitels. Insbesondere wird das fachliche Potenzial, das sich durch die Ereignisorientierung als Architekturstil in einer EDA ergibt, herausgestellt. Konventionelle Softwarearchitekturen und Service-orientierte Architekturen (SOA) werden mit EDA verglichen und potenziell vielversprechende Einsatzgebiete für EDA betrachtet. Kapitel 3 – EDA und CEP im Überblick erläutert die wichtigsten Begriffe, Ideen und Entwurfsprinzipien, die sich hinter Event-Driven Architecture und Complex Event Processing verbergen. Architekturschichten und -elemente einer EDA werden vorgestellt, so dass sich ein vollständiges Gesamtbild des Architekturstils, seiner Kernelemente und Haupteigenschaften ergibt. Das Kapitel schließt mit einer Bewertung von EDA für Unternehmensanwendungen und der Vorstellung einer Fallstudie.

Kapitel 1

Einführung und Motivation

Zusammenfassung Agilität und Effizienz der betrieblichen Geschäftsprozesse sind entscheidende Faktoren für die Leistungs- und Wettbewerbsfähigkeit von modernen Unternehmen. Ereignisse spielen hierbei eine entscheidende Rolle, da alle Abläufe in der realen Welt durch eine Vielzahl und Vielfalt von unterschiedlichen Ereignissen beeinflusst werden. Event-Driven Architecture (EDA) und Complex Event Processing (CEP) repräsentieren einen neuen Stil von Unternehmensanwendungen, bei dem Ereignisse in das Zentrum der Softwarearchitektur rücken. Dieses Kapitel führt in die Thematik der Ereignisverarbeitung mit EDA und CEP ein und motiviert die Bedeutung von Ereignissen für die realen Prozesse in Unternehmen bzw. Unternehmensnetzwerken. In verschiedenen Bereichen der Informatik werden Ereignisse schon seit einiger Zeit betrachtet. Der letzte Abschnitt geht auf diese Bereiche ein und zeigt deren Einflüsse auf die moderne Ereignisverarbeitung.

1.1 EDA und CEP – Einführung Unternehmen sind seit jeher einer permanenten Evolution ausgesetzt. Die Marktbedingungen und -teilnehmer ändern sich und es gilt, die sich wandelnden gesetzlichen Rahmenbedingungen einzuhalten sowie die Unternehmensziele neu zu definieren und umzusetzen. Deshalb streben Unternehmen nach Agilität und Effizienz ihrer Geschäftsprozesse, um auf diese Evolution angemessen reagieren und die sich daraus ergebenden Chancen aktiv gestalten zu können. Die Informationstechnologie (IT) bildet seit vielen Jahren die Basis für die Umsetzung der geschäftlichen Aufgaben und hat somit entscheidenden Einfluss auf die Realisierung der unternehmerischen Ziele. Trotz großer Fortschritte, wie sie beispielsweise in den letzten Jahren durch Service-orientierte Architekturen (SOA) erzielt wurden, besitzen die betrieblichen IT-Systeme jedoch häufig nicht die erforderliche Flexibilität, um die fachliche Agilität entsprechend abzubilden. Erschwerend kommt hinzu, dass die internen und externen Anforderungen an Agilität stetig wachsen, sei es durch erweiterte technische Möglichkeiten (z.B. durch R. Bruns, J. Dunkel, Event-Driven Architecture, Xpert.press, DOI 10.1007/978-3-642-02439-9_1, © Springer-Verlag Berlin Heidelberg 2010

3

4

1 Einführung und Motivation

mobile Endgeräte, die permanent online sind, oder den Einsatz von Sensoren zur Messung von physikalischen Werten) oder verändertes Kundenverhalten (z.B. der gestiegenen Erwartungshaltung an die Geschwindigkeit der Reaktion eines Unternehmens auf eine Kundenanfrage). Ereignissen kommt hierbei eine entscheidende Rolle zu, da alle Vorgänge und Abläufe in der realen Welt durch eine Fülle von unterschiedlichen Ereignissen beeinflusst werden. Event-Driven Architecture (EDA) und Complex Event Processing (CEP) repräsentieren einen neuen Stil von Unternehmensanwendungen, bei dem Ereignisse in das Zentrum der Softwarearchitektur rücken – Ereignisorientierung als Architekturstil. Während EDA einen ereignisorientierten Entwurfsstil für Anwendungsarchitekturen (enterprise application architecture) beschreibt, handelt es sich bei CEP um eine Technologie zur dynamischen Verarbeitung von großen Volumina von Ereignissen in Echtzeit. EDA ist demnach ein generelleres Konzept als CEP, und CEP kann als Kernbestandteil einer EDA angesehen werden, wie in Abbildung 1.1 symbolisiert. Aufgrund des noch jungen Fachgebiets der Ereignisverarbeitung (event processing) und der rasanten Entwicklung von EDA und CEP innerhalb der letzten Jahre haben insbesondere Business-Analysten und die Hersteller von Softwareprodukten diverse Schlagworte im Umfeld der Ereignisverarbeitung geprägt. Abbildung 1.1 listet eine Auswahl dieser Begriffe auf. Event Stream Processing

Intelligent Enterprise

EDA

Business Event Processing

SOA 2.0

CEP

Advanced SOA

Event-Driven SOA Enterprise Nervous System

Event Stream Intelligence

Real-Time Enterprise

Abb. 1.1 Schlagworte im Umfeld von EDA und CEP

Die Grundkonzepte, die sich hinter den diversen unterschiedlichen Bezeichnungen verbergen, sind jedoch immer die gleichen: Event-Driven Architecture und Complex Event Processing – die Themen dieses Buches.1 1

Mit Event-Driven Architecture und Complex Event Processing verwenden wir in diesem Buch die etablierte englische Fachterminologie, entsprechend eindeutige deutsche Bezeichnungen existieren bislang nicht. Übersetzungen wie ereignisgesteuerte Architekturen oder komplexe Ereignisverarbeitung sind nicht etabliert.

1.2 Motivation

5

Die Ereignisorientierung als Gestaltungsprinzip von Softwaresystemen bildet einen wichtigen Schritt auf dem Weg, die bestehende konzeptionelle Lücke zwischen den Geschäftsinteressen eines Unternehmens und den ITSystemen zu verkleinern. Ereignisorientierung besitzt das Potenzial, dass die Architekturen von Unternehmensanwendungen agiler, reaktionsschneller und echtzeitfähig werden.

1.2 Motivation Moderne Unternehmen agieren heutzutage in unternehmensübergreifenden Netzwerken von Partnerunternehmen, öffentlichen Institutionen, Dienstleistern, Informationsdiensten und diversen weiteren Institutionen. Die Qualität und Effizienz der Leistungserbringung eines Unternehmens hängt im wesentlichen Maße von der Qualität und dem Fluss der Informationen in diesem Netzwerk ab. Ereignisse in Unternehmensnetzwerken Ein verteiltes Unternehmensnetzwerk ist beispielhaft für ein Unternehmen aus der Logistikbranche in Abbildung 1.2 visualisiert. Das Logistikunternehmen muss im Rahmen der Erbringung einer logistischen Dienstleistung mit diversen anderen Institutionen bzw. mit deren Informationssystemen kommunizieren. Für ein Logistikunternehmen sind dies u.a. behördliche Institutionen wie Zoll oder Hafenbehörde, Fertigungsunternehmen, deren produzierte Waren transportiert werden sollen, Geschäftskunden mit vermittelten Transportaufträgen, Empfänger, zu denen die Waren gebracht werden müssen, Transportunternehmen, die als Subauftragnehmer Teilstrecken des Transportweges übernehmen, diverse weitere Partnerunternehmen und andere externe Institutionen wie Wetter- und Verkehrsinformationsdienste. Häufig bilden die Logistikprozesse wichtige Teilprozesse in einer komplexen Zulieferkette (supply chain) und müssen entlang der Prozesskette mit den involvierten Partnern integriert werden. Die an der Leistungserbringung beteiligten Institutionen kommunizieren durch den Austausch von Nachrichten miteinander, die zwischen den Institutionen bidirektional hin und her fließen. Als Medium der Kommunikation können sehr unterschiedliche Formen zum Einsatz kommen, z.B. persönliche Gespräche, Internet, Telefon, E-Mail, EDI oder Fax. Jede Nachricht enthält die Daten eines relevanten Vorkommnisses oder Sachverhalts, über das die interessierten Parteien im Netzwerk informiert werden sollen. Eine Nachricht lässt sich somit als Repräsentation eines eingetretenen Ereignisses interpretieren, über dessen Auftreten die Partner in Kenntnis gesetzt werden sollen. Die Kommunikation im Netzwerk besteht demnach aus dem Austausch von Nachrichten mit Ereignisdaten. Die Unternehmen reagieren auf die Ereignisse, die sie

6


Dienstleister

Kunden Fertigungsunternehmen

Spediteure

Verkehrsinformationen

Hafenbehörde Zoll

Wetterdaten

Logistikunternehmen

Abb. 1.2 Logistikunternehmen im Netzwerk mit verbundenen Institutionen

empfangen, und erzeugen neue Ereignisse, die sie an ihre Partner senden. Das ganze System ist “ereignisgesteuert“, da es auf dem Erkennen, Verarbeiten und Reagieren von bzw. auf Ereignissen beruht und die Ereignisse das Mittel der Kommunikation bilden. In einem realen Unternehmensnetzwerk können extrem große Volumina von Ereignissen ausgetauscht werden, tausende bis zu mehrere hunderttausend Ereignisse pro Sekunde. Das Logistikunternehmen in Abbildung 1.2 steht beispielhaft für ein verteiltes unternehmensübergreifendes System. Generell lässt sich festhalten, dass die Geschäftsprozesse global agierender Unternehmen, gleich welcher Branche, auf dem Austausch von Ereignissen durch Nachrichten innerhalb des Unternehmens und unternehmensübergreifend mit Partnerinstitutionen über ein verteiltes Netzwerk beruhen. Ereignisgesteuerte Unternehmen und Institutionen sind demnach in der Realität weit verbreitet. Ereignisgesteuerte Unternehmen sind dadurch gekennzeichnet, dass • sie Ereignisse erkennen, analysieren und darauf reagieren, • sie durch den Austausch von (Ereignis-)Nachrichten miteinander kommunizieren, • sie neue Ereignisse erzeugen und diese an ihre Partner senden und • ihre Aktivitäten durch Ereignisse ausgelöst werden. Abbildung 1.3 zeigt einen typischen Prozessablauf für ein Logistikunternehmen, in dem der Transport einer Ware mit unterschiedlichen Verkehrsträgern, ausgehend vom Versand der Ware bis zur Ablieferung bei einem Empfänger, dargestellt ist. Im Zuge der Prozessdurchführung können eine Fülle von höchst unterschiedlichen Ereignissen auftreten, die Einfluss auf die Leistungserbringung – sowohl po-

1.2 Motivation

7 Verkehrsstau auf Route

Techn. Defekt

Meeresströmung beschleunigt Fahrt

RFID-Tag-ID in Hafen gelesen

Container in falsche Richtung geleitet

Container wurde beschädigt

RFID-Tag-ID bei Umladung nicht gelesen

Versand

Lagerbestand Anfahrt einer unterschreitet weiteren Schwellenwert Produktionsstätte Verkaufszahlen Kunde in Region X um storniert 20% gestiegen Bestellung

Prüfung Frachtdokumente dauert unerwartet lange

Kunde

Kunde ändert Adressdaten auf FirmenHomepage

Expressbestellung eingegangen

Abb. 1.3 Logistischer Prozess mit Beispielen für Ereignisse

sitiv als auch negativ – haben können. In der Abbildung sind einige Ereignisse beispielhaft aufgeführt. Die Ereignisse können unvorhergesehen (z.B. technischer Defekt am LKW), erwartet (z.B. RFID-Transponder bei Umladung im Hafen gelesen) oder erwartet, aber nicht eingetreten sein (z.B. RFID-Transponder bei Umladung auf LKW nicht gelesen) und sowohl aus internen (z.B. Lagerbestand unterschreitet vorgegebenen Schwellenwert) als auch externen Quellen (z.B. Meldung über Verkehrsstau auf geplanter Route) stammen. Typische Fragestellungen Einzelne Ereignisse sind isoliert betrachtet häufig wenig aussagekräftig, z.B. das Lesen eines RFID-Transponders an einem bestimmten Standort. Entscheidend sind Fragestellungen auf der Ebene der betrieblichen Geschäftsprozesse, deren Antworten direkten Einfluss auf operative Entscheidungen haben. Um diese beantworten zu können, müssen jedoch oft mehrere Ereignisse im Zusammenhang betrachtet werden. Typische Fragen mit hohem fachlichem Informationswert sind beispielsweise die folgenden: • “Warum erfolgte die Lieferung einer Ware verspätet?“ Die Antwort könnte sowohl mehrere interne Transportereignisse als auch externe Ereignisse, z.B. Verkehrsstaus oder Wetterbedingungen, umfassen. • “Erreicht meine Ware heute noch den Bestimmungsort?“ Die Antwort könnte sich aus dem Zusammenhang von RFID-Ereignissen, die anzeigen, wo sich die Ware zurzeit befindet, und externen Ereignissen über gemeldete Verkehrsprobleme und Wetterprognosen ergeben. • “Wo wurde der Container fehlgeleitet?“ Die Antwort könnte aus den Beziehungen zwischen RFID-Ereignissen, die den

8


letzten Standort bestimmen, und Transportereignissen, wie z.B. LKW am Standort X zur Zeit Y entladen, abgeleitet werden. • “Halten unsere Abläufe die gesetzlichen Vorgaben ein?“ Die Antwort könnte aus Ereignissen resultieren, die Probleme mit behördlichen Institutionen signalisieren, z.B. Verzögerungen beim Zoll oder bei der Prüfung der Frachtdokumente. • “Besteht eine Chance, die gleichzeitig ablaufenden Prozesse zu optimieren?“ Beispielsweise lassen sich Transporte durch die Zusammenfassung von Lieferungen aufgrund von räumlichen Korrelationen, den Austausch von Gütern zwischen gleichzeitigen Lieferprozessen durch die Nutzung freier Kapazitäten oder die kurzfristige Umleitung von Waren aufgrund von Expressbestellungen effizienter durchführen. • “Laufen unsere derzeitigen Prozesse störungsfrei?“ Beispielsweise deutet das Nicht-Lesen eines erwarteten RFID-Transponders an einer Umladungsstation auf eine Fehlleitung des entsprechenden Gegenstands hin. Geeignete Maßnahmen zur Wiederauffindung des Gegenstands können zeitnah eingeleitet werden. In einem Unternehmen existieren natürlich diverse weitere Fragestellungen der obigen Art. Diese Fragen reichen von der operativen Steuerung der Unternehmensabläufe, dem Erkennen von Marktchancen und Optimierungspotenzial, dem Erkennen von Störungen bzw. unerwarteten Situationen bis zur Sicherstellung der Konformität zu gesetzlichen Richtlinien. Die Beantwortung dieser Art von Fragen setzt ein Verstehen der Ereignisse und ihrer Zusammenhänge entlang der Prozesskette voraus. Verstehen bedeutet in diesem Kontext die Bewertung des Einflusses der Ereignisse auf die geschäftlichen Abläufe und strategischen Ziele des Unternehmens. Durch die unmittelbare Relevanz der Fragen für die operativen Prozesse ist es essenziell, die Antworten in Echtzeit zu erhalten, um zeitnah reagieren zu können. Konsequenzen für die Unternehmensanwendungen Konventionellen IT-Anwendungsarchitekturen liegt eine eher ablauforientierte Sicht auf die Unternehmensanwendungen zugrunde. Diese Systeme sind in der Regel zu starr und unflexibel, um das Verständnis von Geschäftsereignissen und die zeitnahe Ableitung von fachlichen Reaktionen zu leisten. Gesucht ist eine neue Art von Anwendungsarchitektur, die es ermöglicht, die Auswirkungen von Ereignissen auf die Unternehmensziele, -richtlinien und Geschäftsprozesse abzubilden. Da heutige Unternehmensarchitekturen in der Regel nicht explizit auf Ereignisse im Unternehmenskontext eingehen, besteht häufig eine Diskrepanz zwischen den realen Geschäftsprozessen und deren informationstechnischer Unterstützung. Roy Schulte formuliert dies wie folgt: “The real world is mostly event driven, and event-driven situations are best addressed by event-driven business applications (to eliminate the impedance mismatch).“ (Quelle: R. Schulte, Gartner Inc., Vortrag “Event Processing in Business Applications“, 15. März 2006)

1.3 Historischer Kontext

9

Um diesen Herausforderungen gerecht werden zu können, ist für Unternehmen das Erkennen, Analysieren und Reagieren von bzw. auf Ereignisse mindestens genauso wichtig wie das Ausführen von vordefinierten Prozessen. Mit Event-Driven Architecture als Architekturstil und Complex Event Processing als leistungsfähiger Technologie zur Ereignisverarbeitung stehen zwei ausdrucksstarke Ansätze zur Entwicklung ereignisgesteuerter Geschäftsanwendungen zur Verfügung. Mit EDA und CEP lassen sich Geschäftsprozesse wirklichkeitsnah und problemadäquat abbilden und somit die Geschäftsziele und IT-Systeme in Einklang bringen. Unternehmen, die den ereignisorientierten Architekturstil in ihre Unternehmensanwendungen integrieren, können schneller und flexibler auf sich verändernde Geschäftsbedingungen reagieren und erreichen insgesamt eine höhere Agilität und Effizienz ihrer Prozessabläufe. Wohingegen konventionelle Softwarearchitekturen für die Verarbeitung von Ereignissen oft komplexes und kostspieliges Software Engineering erfordern.

1.3 Historischer Kontext Event-Driven Architecture und Complex Event Processing haben sich in den letzten Jahren als eigenständiges Fachgebiet der Ereignisverarbeitung (event processing) etabliert. In der Informatik wird jedoch die Verarbeitung von Ereignissen bereits seit vielen Jahren untersucht. Ereignisbasierte Konzepte wurden unabhängig voneinander in unterschiedlichen Bereichen entwickelt. Eine ausführlichere Diskussion der Entwicklung der Ereignisverarbeitung findet sich in [66] und [67]. • Die diskrete Ereignissimulation (discrete event simulation) verfolgt das Ziel, das natürliche Verhalten von Systemen rechnergestützt zu simulieren. Ausgehend von Eingabedaten erzeugt die Simulation Ereignisse, die die Interaktion zwischen Teilkomponenten des Systems nachbilden. Die sich während der Simulation ergebende Folge von Ereignissen repräsentiert somit das Verhalten des Modells. Die Analyse der Ereignisfolge berücksichtigt kausale Abhängigkeiten zwischen Ereignissen und leitet Systemkenngrößen aus den simulierten Ereignissen bzw. deren Beziehungsmustern ab [66]. • In Computer-Netzwerken stellt das Senden oder Empfangen von Datenpaketen jeweils ein signifikantes Ereignis dar. Zur Strukturierung der Kommunikationsaufgaben werden in Netzwerken die Kommunikationsereignisse in aufeinander aufbauende Schichten (layer) gegliedert, beispielsweise im ISO/OSIReferenzmodell oder im TCP/IP-Referenzmodell. Diese Modelle basieren auf der Abstraktion von Ereignissen – ausgehend von einfachen Netzwerkdetails (unterste Ebene) bis zu aussagekräftigen Anwendungsereignissen (höchste Ebene) nimmt der Abstraktionsgrad von Schicht zu Schicht zu [66]. Die in diesem Kontext entstandenen Netzwerkmanagement-Werkzeuge ermöglichen das Verfolgen und die Kontrolle von Ereignissen im Netzwerk. Diese Werk-

10


zeuge können als frühe Vorgänger des Business Activity Monitoring (BAM) angesehen werden und enthalten bereits wesentliche grundlegende Konzepte von Echtzeitkontrollsystemen. • Aktive Datenbanken (active databases) [85] erweitern traditionelle Datenbankmodelle um Techniken zur unmittelbaren Reaktion auf Datenänderungen, und zwar mit dem Ziel einer Echtzeitverarbeitung. Mit Hilfe sogenannter ECARegeln (event-condition-action rules) können einzelne Ereignisse sowie einfache Muster von Ereignissen definiert werden, deren Auftreten im operativen Betrieb dann Aktionen auslösen kann, wie z.B. den Aufruf einer Anwendungsfunktion. Spezifische Sprachen zur Formulierung von ECA-Regeln beinhalten Konzepte wie zusammengesetzte Ereignisse (composite events) und temporale Constraints [66]. • In der Softwarearchitektur hat sich der Austausch von Ereignissen in Form von Nachrichten als Kommunikationsstil zwischen verteilten Systemkomponenten etabliert. Insbesondere im Bereich der Anwendungsintegration (Enterprise Application Integration, EAI) kommt dieser Kommunikationsstil zum Einsatz. Ereignisse sind Bestandteil von Unternehmensarchitekturen (enterprise architecture) [40, 51] und Entwurfsmustern (design pattern) wie beispielsweise dem Observer-Pattern [43]. Die Kommunikationsinfrastruktur basiert auf ereignisgesteuerter Kommunikation auf einer niedrigen, technischen Ebene und unterstützt eine ereignisgesteuerte Anwendungsarchitektur, also eine Event-Driven Architecture, auf der Ebene der Unternehmensanwendungen [66]. Weitere, wichtige Konzepte mit starkem Einfluss auf EDA und CEP stammen aus dem Gebiet der Künstlichen Intelligenz (artificial intelligence). Hier sind insbesondere die Arbeiten zur Repräsentation und zum Schließen über zeitabhängige Informationen (temporales Schließen, temporal reasoning) [4] sowie die Konzepte zu regelbasierten Systemen (production systems) [78] und wissensbasierten Systemen (knowledge-based systems) zu nennen. Im Jahr 2002 veröffentlichte David Luckham sein grundlegendes Buch “The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems“ [63], in dem er die diversen Vorarbeiten im Kontext der Verarbeitung von Ereignissen zum Konzept des Complex Event Processing (CEP) zusammenführte. Das Buch stellt einen wesentlichen Meilenstein für die Etablierung der Ereignisorientierung als Fachdisziplin dar. Inzwischen haben etliche Softwarehersteller den Markt für Ereignisverarbeitung erkannt und bieten diverse professionelle Softwareplattformen für Complex Event Processing bzw. Event Stream Processing an. Neben kommerziellen Werkzeugen von Herstellern, u.a. Progress, Aleri, IBM, Oracle, Tibco, Coral8, StreamBase Systems, sind auch leistungsfähige Open-Source-Produkte, u.a. Esper [34] oder Drools [54], verfügbar.

1.3 Historischer Kontext

11

Mit der Event Processing Technical Society (EPTS)2 wurde im Jahr 2008 erstmalig eine internationale Fachorganisation gegründet, die explizit auf das Fachgebiet der Ereignisverarbeitung fokussiert ist. Die EPTS verfolgt die Ziele, das Verständnis und die Entwicklung von Prinzipien und Technologien zur Ereignisverarbeitung zu fördern, die Entwicklung von Standards zu unterstützen und ein kooperatives Umfeld für Kommunikation und Lernen in diesem Fachgebiet zu bieten.

2

Weitere Informationen zur Event Processing Technical Society (EPTS) finden sich unter der URL http://www.ep-ts.com.

Kapitel 2

Ereignisse in Unternehmensanwendungen

Zusammenfassung Geschäftsereignissen kommt eine große Bedeutung für Unternehmen zu. Diese fachliche Bedeutung für die Geschäftsprozesse eines Unternehmens ist Gegenstand dieses Kapitels. Die Einflussfaktoren für den auch zukünftig anhaltenden Bedeutungszuwachs und die sich hieraus ergebenden fachlichen Anforderungen werden herausgearbeitet. Konventionelle Softwarearchitekturen können diesen Anforderungen nur zum Teil gerecht werden, ihre Grenzen werden aufgezeigt. Ereignisorientierung als Architekturstil behebt einige dieser Defizite, dies wird im Vergleich mit den konventionellen Ansätzen betrachtet. Da Serviceorientierte Architekturen (SOA) in den letzten Jahren eine sehr große Resonanz erfahren haben, wird auf das Verhältnis von EDA und SOA explizit eingegangen. Den Abschluss bildet die Identifikation von potenziellen Anwendungsgebieten, die für EDA besonders aussichtsreich erscheinen, sowie den hierfür ausschlaggebenden Kriterien.

2.1 Bedeutung von Ereignissen Kunden stornieren Aufträge, Paketsendungen gehen verloren oder zugelieferte Fertigungsteile sind verspätet. Unternehmen sind seit jeher ereignisgesteuert, da sie permanent auf erwartete und unvorhergesehene Ereignisse von Kunden, Lieferanten, Wettbewerben oder aus dem eigenen Unternehmen reagieren müssen. Selbst in sorgfältig entworfenen und durchgeführten Geschäftsprozessen ist es unmöglich, alle potenziellen Ereignisse zu berücksichtigen, die den Prozess tangieren und stören könnten. Ereignisse beeinflussen somit wesentlich alle Abläufe und Entscheidungen in einem Unternehmen. Jeder Vorgang, jede Aktivität und jede Entscheidung in der realen Welt oder in einem Softwaresystem, der bzw. die direkte Auswirkungen auf die betrieblichen Prozesse in einem Unternehmen nach sich ziehen kann, stellt ein Ereignis bzw. Geschäftsereignis dar.

R. Bruns, J. Dunkel, Event-Driven Architecture, Xpert.press, DOI 10.1007/978-3-642-02439-9_2, © Springer-Verlag Berlin Heidelberg 2010

13

14

2 Ereignisse in Unternehmensanwendungen

Beispiele für Ereignisse sind: eine Finanztransaktion, ein Defekt an einer Fertigungsmaschine, die Auslieferung einer Ware aus einem Warenlager, das Löschen eines Artikels aus dem Warenkorb in einem Online-Shop, der Start eines Flugzeugs, ein Sensor meldet eine erhöhte Temperatur einer Maschine, ein gemessener CO2 Wert an einer Messstelle oder ein Fahrzeug überquert eine in einer Straße eingelassene Induktionsschleife.

2.1.1 Ereignisgesteuerte Geschäftsprozesse Ereignisse sind allgegenwärtig in Unternehmen und spielen eine entscheidende Rolle in der Steuerung der Geschäftsprozesse. Ein Geschäftsprozess (business process) ist eine Folge von Schritten zur Erreichung eines angestrebten Arbeitsergebnisses und dient der Leistungserbringung in einem Unternehmen. Ein Geschäftsprozess lässt sich als ereignisgesteuert bezeichnen, wenn eine spezifische Verarbeitungsfolge durch den Auftritt eines Ereignisses ausgelöst oder substanziell beeinflusst wird. Es existiert eine Fülle von Beispielen für ereignisgesteuerte Geschäftsprozesse: • Im Wertpapierhandel orientieren sich die Kauf- bzw. Verkaufsentscheidungen an der Entwicklung unterschiedlicher Kennzahlen wie Devisenkursen, Edelmetallpreisen oder Aktienindizes. Jede Kursänderung stellt ein relevantes Ereignis dar und beeinflusst ggf. die Entscheidungsfindung. • Viele Fertigungsprozesse sind durch den Auftritt von Ereignissen geprägt. Beispielsweise muss auf die Bereitstellung eines Werkstücks, das Beenden eines Fertigungsschritts oder das Auftreten einer Fehlfunktion unmittelbar reagiert werden. • In logistischen Prozessen kommt der Identifikation und Lokalisierung von Waren und Gegenständen eine besondere Bedeutung zu. Aus diesem Grund werden die nachzuverfolgenden Gegenstände z.B. mit RFID-Technologie (Radio Frequency Identification) ausgestattet. Jedes von einem RFID-Lesegerät empfangene Signal eines Transponders stellt ein Ereignis dar, dessen Relevanz für den logistischen Prozess analysiert werden muss. • Im Business Activity Monitoring (BAM) werden die für ein Unternehmen relevanten Geschäftsereignisse in Echtzeit gesammelt und zu Daten verdichtet, die für die Bestimmung des gegenwärtigen Zustands der wichtigen Geschäftsprozesse aussagekräftig sind. Basierend auf ausgewählten Unternehmensindikatoren lassen sich so Entscheidungen qualifizierter treffen und die Geschäftsprozesse dynamisch entsprechend den Unternehmenszielen anpassen. Abhängig von der Größe, Branche und Art eines Unternehmens treten täglich hunderte bis zu millionen bemerkenswerter Ereignisse auf. Einige dieser Geschäftsereignisse können sich negativ, andere positiv auf die Geschäftstätigkeit auswirken. Einige stellen eine attraktive Chance dar, andere wiederum sind nicht weiter beachtenswert.

2.1 Bedeutung von Ereignissen

15

David Luckham bezeichnet die Gesamtheit aller Ereignisse, in der sich ein Unternehmen bewegen muss, als Ereigniswolke (global event cloud) [63]. Der Begriff Wolke symbolisiert eine nur teilweise geordnete Menge heterogener Ereignisse aus unterschiedlichen Quellen, bei denen wünschenswerte Eigenschaften wie Vollständigkeit oder Ordnung nicht gewährleistet sind. So können Ereignisse in veränderter Reihenfolge eintreffen, die nicht der Reihenfolge ihrer zeitlichen Erzeugung oder ihrer kausalen Reihenfolge entspricht. Manche Ereignisse können fehlen, andere dafür in mehrfacher Ausführung vorliegen.

2.1.2 Herausforderungen im Umgang mit Ereignissen Die Größe dieser Ereigniswolke – sowohl hinsichtlich der Anzahl der auftretenden Ereignisse an sich als auch der Anzahl von unterschiedlichen Arten von Ereignissen – steigt kontinuierlich immer weiter an. Folgende Faktoren tragen wesentlich dazu bei, dass Unternehmen mit einem stetig steigenden Strom von Ereignissen konfrontiert sind: 1. Fachliche Komplexität Geschäftsprozesse innerhalb eines Unternehmens vernetzen heutzutage unterschiedliche Abteilungen, Standorte und Fertigungsstätten im In- und Ausland miteinander. Die fortschreitende Arbeitsteilung zwischen Unternehmen führt zu einer engen, unternehmensübergreifenden Kopplung der Prozesse von Produzenten und Zulieferern entlang der Zulieferkette (supply chain), wie bereits in Abschnitt 1.2 am Beispiel der Unternehmensnetzwerke ausgeführt. Mit dieser Vernetzung einher geht die Notwendigkeit, die entsprechenden Informationssysteme zu integrieren und untereinander abgestimmte Datenflüsse auszutauschen. Dieser Datenaustausch beinhaltet eine Vielzahl von geschäftlich relevanten und irrelevanten Ereignissen, die identifiziert, analysiert und bewertet werden müssen. Die Komplexität der fachlichen Prozesse ist enorm gestiegen und wird auch in Zukunft weiter ansteigen. Dieser Komplexitätsanstieg geht wesentlich auf die fachliche Nutzung der fortschreitend zunehmenden Möglichkeiten der Informationstechnologie, insbesondere im Umfeld des Internets, zurück. 2. Technische Komplexität Nahezu jedes größere Unternehmen sieht sich mit einer komplexen, heterogenen IT-Infrastruktur konfrontiert, die über viele Jahre gewachsen ist. Sowohl hardware- als auch softwaretechnisch befinden sich diverse Systeme mit unterschiedlichen Hardwareplattformen, Betriebssystemen, Programmiersprachen, Datenformaten und inkompatiblen Kommunikationsprotokollen im Einsatz. Einige dieser Systeme sind bereits mehrere Jahre alt, andere noch relativ neu. Dazu erfolgt der Einsatz häufig in sehr großer Anzahl und verteilt über Abteilungs- und Unternehmensgrenzen. Diese Systeme interagieren ständig miteinander durch den Austausch technischer Daten auf Protokollebene. Das Verstehen und Kontrollieren des Systemverhaltens ist äußerst schwierig und setzt die Aggregation der technischen Protokolldaten zu aussagekräftigen inhaltlichen Ereignissen vor-

16


aus, die ein Systemadministrator interpretieren kann. Und auch die technische Komplexität wird weiter steigen, beispielsweise durch mobile Arbeitsplätze und höhere Sicherheitsanforderungen. 3. Kommunikation mit der physikalischen Umwelt Sensornetzwerke übermitteln Messdaten aus der physikalischen Welt und stellen hierdurch eine Verbindung zwischen den Unternehmensanwendungen und der Außenwelt her. Aufgrund der steigenden technischen Möglichkeiten der Sensoren bei gleichzeitig fallenden Kosten haben der Verbreitungsgrad und die Einsatzfelder von Sensornetzwerken rapide zugenommen. Einsatzgebiete sind z.B. die Lokalisierung und Identifikation von Containern mittels RFID, die Überwachung industrieller Anlagen oder die Messung von Meeresströmungen und -temperatur. In der Regel sind die von einem Sensor übermittelten Daten feingranulare Daten, z.B. (Sensor-ID, Zeitpunkt, Messwert), die in extrem großen Volumina auftreten. Ein Sensornetzwerk besteht häufig aus tausenden von Sensoren, die jeweils im Millisekundentakt Messwerte liefern. 4. Datenmenge Unternehmen sehen sich einem stetig wachsenden Fluss von Daten ausgesetzt: sowohl sehr feingranulare, eher technische Daten, z.B. ein Web-Server registriert den Eingang eines HTTP-Requests, als auch komplexere fachliche Daten, z.B. ein Kunde annuliert eine Bestellung. Das steigende Aufkommen an Geschäftstransaktionen sowie die zunehmende Geschwindigkeit, in der Daten produziert werden, führen zu einer kaum noch handhabbaren Menge von Daten. Ein typisches Unternehmen produziert Millionen von (Daten-)Ereignissen pro Tag. Durch diese stetige Zunahme von Ereignissen, deren Menge und Qualität bisher nicht bekannte Größenordnungen erreichen können, stehen die Unternehmen in Zugzwang. Sie müssen diese Ereignisse in einer systematischen Art und Weise identifizieren sowie sie am richtigen Ort, zur richtigen Zeit und im richtigen Abstraktiongsgrad bereitstellen. Die Herausforderung liegt darin, die immer stärker anwachsende Menge von Ereignisdaten in die laufenden operativen Geschäftsprozesse zu integrieren. Hieraus ergeben sich eine Reihe von fachlichen Anforderungen, denen Unternehmensanwendungen gerecht werden müssen, um ereignisgesteuerte Geschäftsprozesse angemessen zu unterstützen bzw. überhaupt erst zu ermöglichen. Die Abbildung 2.1 stellt die für die Zunahme der Ereignismenge verantwortlichen Faktoren den durch sie resultierenden Anforderungen gegenüber, die nachfolgend erläutert werden: • Kontrollierbarkeit Damit die menschlichen Benutzer die Kontrolle über die Geschäftsprozesse behalten können, müssen sie eine verständliche und personalisierte Sicht auf den Zustand der Prozesse und die Abläufe im System haben. Die Benutzer müssen den Status der Prozesse und den Zustand des Systems verstehen, um in Echtzeit operative Entscheidungen zu treffen. Die Auswertung von Log-Dateien, die viele Prozessautomatisierungswerkzeuge heutzutage anbieten, reicht hierzu bei weitem nicht aus.

2.1 Bedeutung von Ereignissen Fachliche Komplexität

Kontrollierbarkeit

17

Technische Komplexität

Kundenerwartungen

Transparenz

Kommunikation mit Umwelt

Agilität

Datenmenge

Ausnahmebehandlung

Abb. 2.1 Einflussfaktoren für Zunahme der Ereignismenge und resultierende Anforderungen für Geschäftsprozesse

• Kundenerwartungen Kunden erwarten heutzutage von Unternehmen immer schnellere Antworten auf Service-Anfragen und fordern häufig eine proaktive Kommunikation und Problemlösung.1 Unternehmen müssen schneller reagieren und antworten als je zuvor, wobei gleichzeitig die Anzahl der Kanäle für die Kundeninteraktion (multichanneling) zunimmt und somit annähernd eine Echtzeit-Koordination erfordern. Damit einher geht die Individualisierung der Informationssysteme, bei der jeder Kunde seinen persönlichen Zugang zum System erwartet. • Transparenz Gesetzliche, vertragliche und organisatorische Vorgaben und Regularien zwingen Unternehmen dazu, jederzeit Rechenschaft über den konkreten Zustand des Unternehmen ablegen zu können. In Berichten muss sich der gegenwärtige Zustand durch Kennzahlen ablesen lassen, und Prozessabläufe müssen sich lückenlos nachvollziehen lassen. Insbesondere die Anforderungen an ein effektives Risikomanagement sind durch gesetzliche Vorgaben enorm gestiegen. Die Auswertung von Daten aus der Vergangenheit ist hierfür nicht ausreichend, stattdessen stehen die Gegenwart und das Erkennen von zukünftigen Trends und sich anbahnenden Risiken im Fokus. • Agilität Geschäftsprozesse sind einer kontinuierlichen Evolution unterworfen. Das Marktumfeld eines Unternehmens ist von hoher Agilität und dynamischen Veränderungen auf technischer, wirtschaftlicher, gesetzlicher, politischer und gesellschaftlicher Ebene geprägt. Beim Entwurf eines Prozesses können nicht alle möglichen Situationen vorhergesehen werden, die jemals eintreten können. Deshalb müssen Unternehmen neben einer effizienten Implementierung der geplanten fachlichen 1

Proaktives Verhalten ist dadurch gekennzeichnet, dass das System bereits reagiert, bevor ein Sachverhalt aufgetreten ist. Wenn beispielsweise bei einer Flugreise ein Gepäckstück verloren gegangen ist, soll nicht erst dann reagiert werden, wenn der Reisende am Zielort vergeblich auf sein Gepäck wartet und den Verlust meldet. Stattdessen soll das System den Verlust des Gepäcks möglichst zum Zeitpunkt der Fehlleitung erkennen, um vorausschauend die Behebung des Problems einzuleiten.

18


Prozessabläufe bei Bedarf auch in der Lage sein, die in den IT-Systemen implementierten Prozesse ebenso effizient adaptieren zu können. Die Schnelligkeit und der Erfolg bei der Adaption der geschäftlichen Prozesse hängt entscheidend von der Anpassungsfähigkeit der tangierten Anwendungssysteme ab. Im Idealfall lassen sich die Prozesse ohne Unterbrechung des laufenden Betriebs anpassen (on-the-fly process modification). • Ausnahmebehandlung Ausnahmesituationen wie Störungen oder Fehler können unerwartet und zu jeder Zeit auftreten. Da diese Ausnahmen den Ablauf der Geschäftsprozesse empfindlich stören können, ist die systematische Behandlung von Ausnahmesituationen ebenso wichtig wie die Unterstützung des Normalverhaltens der Prozesse. Im besten Falle lassen sich Ausnahmesituationen durch die Analyse sich ankündigender Ereignisse bereits im Vorfeld erkennen und das Eintreten der Ausnahme durch Initiierung geeigneter Maßnahmen proaktiv verhindern. Natürlich lassen sich nicht sämtliche Ausnahmen im Voraus vermeiden. Um die negativen Auswirkungen einer Ausnahme zu minimieren, ist aber das Wissen hilfreich, welche Ereignisse zu dieser Ausnahme geführt haben. Also das Wissen um die kausalen Abhängigkeiten, aus denen die Ausnahme resultierte. Die effiziente Erfüllung dieser fachlichen Anforderungen setzt ein tiefgreifendes Verständnis des Verhaltens und des Zustands der Unternehmensanwendungen in Echtzeit voraus. Gegenwärtig fällt es sehr schwer, qualifiziert zu beurteilen, wie sich die enorme Menge von Ereignissen in den zugrunde liegenden Anwendungssystemen auf die operativen Geschäftsprozesse und damit auf das Erreichen der Geschäftsziele auswirkt. Gefordert ist aber die Fähigkeit vorherzusagen, wie spezifische Konstellationen von Ereignissen die Geschäftsziele, -richtlinien und -prozesse beeinflussen.

2.1.3 Ereignismuster und -abstraktion Die Unternehmen stehen vor der Herausforderung, den maximalen Informationswert aus dem immer weiter ansteigenden Datenfluss und der sich daraus ergebenden riesigen Ereignismenge herauszuholen. Um diesem Ziel gerecht zu werden, müssen die folgenden zentralen Problembereiche gelöst werden [63]: 1. 2. 3. 4.

Erkennen von komplexen Mustern zwischen Ereignissen Betrachtung von Ereignissen auf unterschiedlichen Abstraktionsebenen Nachverfolgen von kausalen Beziehungen zwischen Ereignissen in Echtzeit Initiieren von Aktionen, wenn Muster von Ereignissen erkannt werden

1. Ereignismuster Signifikante Informationen mit Einfluss auf die geschäftlichen Abläufe ergeben sich einerseits durch das Erkennen des Auftretens einzelner Ereignisse, anderseits aber


19

insbesondere durch das Erkennen von Zusammenhängen, Abhängigkeiten und Korrelationen zwischen mehreren Ereignissen. Häufig gewinnen Ereignisse erst an Bedeutung, wenn sie zu anderen Ereignissen in Beziehung gesetzt werden, die zeitlich und/oder örtlich getrennt aufgetreten sind. Die zwischen zusammenhängenden Ereignissen bestehenden Beziehungen bilden ein spezifisches Muster von Ereignissen (event pattern), das in der enormen Masse der Ereignisse erkannt werden muss. Ereignismuster können sich z.B. auf die Sequenz des Eintreffens (Ereignis X gefolgt von Y und danach Z), auf temporale Bedingungen (innerhalb eines Zeitintervalls von 10 Minuten) und/oder auf räumliche Bedingungen (innerhalb eines Umkreises von 10 Kilometern) beziehen. Ein Ereignismuster beschreibt eine spezifische Situation oder Konstellation in der Ereignismenge mit fachlichem Informationswert. Ein einfaches Beispiel für den Zusammenhang zwischen Ereignissen ist die Beziehung zwischen zwei E-Mail-Nachrichten, bei denen die zweite E-Mail-Nachricht als Antwort (reply) auf die erste Mail geschrieben wurde. Wenn die zweite E-Mail für sich alleine isoliert betrachtet wird, kann es sehr schwierig sein, deren Bedeutung richtig zu erfassen. Erst durch das Erkennen, dass diese E-Mail in AntwortBeziehung zu einer früheren E-Mail steht, lässt sie sich korrekt interpretieren. Abbildung 2.2 zeigt eine Menge von Ereignissen, in der an zwei Stellen ein signifikantes Muster von drei zu einander in Beziehung stehenden Ereignissen erkannt wurde. Um Muster in der Menge der Ereignisse zu erkennen und daraus entsprechende Schlussfolgerungen zu ziehen, muss der eingehende Fluss der eingetretenen Ereignisse über einen längeren Zeitraum analysiert werden. Ereignismuster

Fluss der Ereignisse

Ereignismuster

Abb. 2.2 Erkennen von komplexen Mustern zwischen Ereignissen

In einem System für den Handel mit Wertpapieren bilden die Daten über aktuelle und historische Kursänderungen sowie Kauf- und Verkaufsaufträge einen kontinuierlichen Fluss von Ereignissen – Millionen von Ereignissen pro Tag aus unterschiedlichen Quellen wie Banken, Analysten, Börsen etc. Aus der isolierten Interpretation eines singulären Ereignisses, wie beispielsweise das aktuelle Steigen eines Aktienkurses, lassen sich keine qualifizierten Entscheidungen ableiten. Stattdessen gilt es, aus der enormen Menge von Ereignissen signifikante Muster zu erkennen, aus denen sich fundierte Kauf- und Verkaufsentscheidungen ableiten lassen. Ein Beispiel für ein Muster in diesem Kontext ist, wenn die Aktienkurse von fünf Automobilherstellern innerhalb von 10 Minuten um mindestens 5% steigen.

20


2. Abstraktionsebenen Die Entscheidungsfindung in einem Unternehmen benötigt verdichtete Informationen auf einem problemadäquaten Abstraktionsniveau, das die für das Verständnis des Status der operativen Prozesse wesentlichen Informationen wiedergibt, dabei aber alle in diesem Kontext unwesentlichen Details ausblendet. In einem Unternehmen treten die Ereignisse, die für die benötigten Informationen verantwortlich sind, jedoch typischerweise auf ganz unterschiedlichen Abstraktionsebenen auf – von äußerst einfachen, häufig technischen Ereignissen (low level events) auf der Sensoren-, Netzwerk- und Middleware-Ebene bis zu höherwertigen, komplexen Geschäftsereignissen mit unmittelbarer fachlicher Bedeutung auf der Ebene der Geschäftsprozesse (high level events). Das Auftreten mehrerer einfacher Ereignisse kann hierbei ein Ereignis auf einer höheren Abstraktionsebene implizieren. Sobald ein entsprechendes Ereignismuster erkannt wird, lässt sich daraus ein neues, komplexeres Ereignis auf einer höheren Abstraktionsebene ableiten, dargestellt in Abbildung 2.3.

Abstraktionsgrad

komplexe Ereignisse höhere Abstraktionsebene

tiefere Abstraktionsebene

Abb. 2.3 Betrachtung von Ereignissen auf unterschiedlichen Abstraktionsebenen

Das komplexe Ereignis abstrahiert von den Informationen im Ereignismuster – wichtige Daten bleiben im neuen Ereignis erhalten, unwesentliche Informationen werden ausgelassen. Die Abstraktion von Ereignissen ist eine wirkungsvolle Methode, um abstraktere Sichten auf komplexe Muster von geschäftlichen Aktivitäten zu liefern. In der Regel ist es einfacher, die Bedeutung eines komplexen, höherwertigen Ereignisses zu verstehen (z.B. “innerhalb der letzten Stunde ist der Prozentsatz der Devisenverkäufe um 43% gestiegen“) und darauf zu reagieren, als direkt auf der Menge der einfachen Ereignisse zu arbeiten (bspw. die einzelnen Devisenverkaufstransaktionen durchzuarbeiten) [18]. Ein komplexes Ereignis realisiert somit eine vereinfachte Sicht auf eine komplexe fachliche Situation. Je nach fachlichem Anwendungskontext kann es mehrere Abstraktionsebenen geben, die eine Hierarchie bilden. Je höher die Abstraktionsebene, desto aussagekräftiger sind die Ereignisse auf dieser Ebene. Eine Hierarchie von Abstraktions-


21

ebenen ist auch ein probates Mittel zur Beherrschung der Komplexität, da die Anzahl der Ereignisse mit jeder höheren Ebene abnimmt. Die Abbildung 2.4 visualisiert exemplarisch ein Ereignismuster in einem vereinfachten Logistikprozess. Ein Auftrag für die Lieferung einer Ware geht ein. Daraufhin wird die Ware im Lager reserviert und eine Rechnung an der Kunden gesendet. Nur wenn die Ware reserviert wurde und die Zahlung durch den Kunden bereits erfolgt ist, wird die Ware ausgeliefert. Dann folgt der Transport und die Ablieferung beim Kunden.

komplexes Ereignis

Lieferauftrag komplett fertig

Abstraktionsgrad

höhere Abstraktionsebene

Lagerreservierung

Lagerausgang

Rechnungsausgang

Zahlungseingang

Auftragseingang

Transport

Ablieferung Kunde

Ereignismuster


Abb. 2.4 Abstraktionsebenen am Beispiel eines Logistikprozesses

Der Zusammenhang zwischen den Einzelereignissen in diesem Ereignismuster resultiert aus der Tatsache, dass diese Ereignisse alle zum selben Lieferauftrag gehören, beispielsweise repräsentiert durch die Lieferauftragsnummer in jedem Ereignis. Wenn alle diese Einzelereignisse mit den durch die Pfeile angegebenen zeitlichen Abhängigkeiten eingetreten sind, ist der Lieferauftrag vollständig bearbeitet. Die Einzelereignisse für einen Lieferauftrag werden also zueinander in Beziehung gesetzt und wenn das entsprechende Muster in der Menge der Ereignisse erkannt wird, erfolgt die Erzeugung eines komplexeren Ereignisses “Lieferauftrag komplett fertig“. 3. Kausale Beziehungen Wenn aufgrund eines erkannten Ereignismusters ein neues komplexes Ereignis erzeugt wird, dann besteht zwischen den einfachen Ereignissen im Ereignismuster und dem komplexen Ereignis ein ursächlicher bzw. kausaler Zusammenhang. Ohne das Auftreten der einfachen Ereignisse würde auch das komplexe Ereignis nicht existieren. Die Möglichkeit, die kausalen Abhängigkeiten zwischen Ereignissen nachvollziehen zu können, ist wichtig, um die Frage, warum etwas geschehen ist, zu

22


beantworten und eine Erklärung für das Entstehen eines Ereignisses zu erhalten. Abbildung 2.5 zeigt im linken Teil die Rückverfolgung der kausalen Beziehungen, ausgehend von einem komplexen Ereignis hin zu den einfacheren Ereignissen, die für die Entstehung des komplexen Ereignisses verantwortlich sind.

Nachverfolgung

komplexe Ereignisse

? höhere Abstraktionsebene nicht eingetretenes Ereignis

abstraktes Ereignis


?

Abb. 2.5 Nachverfolgen des Eintretens und des Nicht-Eintretens von komplexen Ereignissen anhand der kausalen Beziehungen

Wenn für das komplexe Ereignis “Lieferauftrag komplett fertig“ in Abbildung 2.4 eine Erklärung benötigt wird, warum der Lieferauftrag vollständig abgeschlossen ist, dann lassen sich aufgrund der kausalen Abhängigkeiten alle einfachen Ereignisse zurückverfolgen, deren Auftreten zum Abschluss des Lieferauftrags geführt haben. Das Nachvollziehen von kausalen Abhängigkeiten bietet sogar die Möglichkeit festzustellen, warum ein erwartetes Ereignis nicht eingetreten ist. Das Fehlen eines erwarteten komplexen Ereignisses ist in Abbildung 2.5 durch das “?“ auf der höheren Abstraktionsebene angedeutet. Eine Erklärung für das Nicht-Eintreten eines komplexen Ereignisses ist möglich, indem anhand eines Ereignismusters nachvollzogen wird, welche Ereignisse aus dem Muster nicht eingetreten sind, also fehlen, und somit die Ursache darstellen, dass die Erzeugung des komplexen Ereignisses nicht stattgefunden hat. Ist nun das komplexe Ereignis “Lieferauftrag komplett fertig“ in Abbildung 2.4 nicht eingetreten, so lässt sich anhand des Ereignismusters in Abbildung 2.4 herausfinden, welches einfache Ereignis aus dem Muster fehlt. Beispielweise der fehlende Zahlungseingang und die gescheiterte Reservierung im Lager. 4. Initiieren von Aktionen Wenn ein Muster im Ereignisfluss erkannt wird, dann soll in der Regel aus dieser Erkenntnis auch eine fachliche Konsequenz abgeleitet werden. Sei es, dass als Konsequenz ein neues Ereignis auf einer höheren Abstraktionsebene erzeugt wird. Sei es, dass aus dem Ereignismuster fachliche Aktionen resultieren sollen. Beispiels-

2.2 Grenzen von konventionellen Softwarearchitekturen

23

weise wird der menschliche Prozessverantwortliche durch Setzen einer Alarmstufe auf gelb gewarnt. Wenn ein weiteres Ereignis X innerhalb von 10 Sekunden auftritt, wird die Alarmstufe wieder auf grün zurückgesetzt, oder wenn X nicht auftritt, wird die Alarmstufe auf rot gesetzt und ein Alarm ausgelöst. Im Logistikprozess könnten beispielsweise bei dem Eingang der Meldung eines Verkehrsstaus mit mehr als 5 Kilometer Länge alle LKWs automatisch informiert werden, die sich zurzeit in einem Umkreis von 70 Kilometern zu dem gemeldeten Stau befinden. Konsequenz Das Erkennen von Ereignismustern, die Betrachtung von Ereignissen auf unterschiedlichen Abstraktionsebenen, das Nachvollziehen von kausalen Beziehungen sowie das Ableiten von fachlichen Aktionen sind essenzielle Problemstellungen, um aus der riesigen Ereignismenge die für das Systemverständnis wesentlichen Informationen zu extrahieren und auf deren Basis die richtigen operativen Entscheidungen zu fällen. Der Schlüssel zur Lösung der aufgezeigten Probleme liegt in der Berücksichtigung der Verarbeitung von Ereignissen als zentrales Konzept der Softwarearchitektur.

2.2 Grenzen von konventionellen Softwarearchitekturen Die automatische Verarbeitung von Ereignissen ist keine neue Idee, sondern findet in Softwaresystemen schon seit vielen Jahrzehnten statt, siehe hierzu die Beschreibung des historischen Kontextes in Abschnitt 1.3. Abgesehen von Ausnahmen dient jedoch die Ereignisorientierung nicht als zentrales Konzept, auf dem die Softwarearchitektur basiert. Insbesondere in der Systemsoftware ist die Ereignisverarbeitung ein etablierter Bestandteil, beispielsweise in Betriebssystemen sowie Netzwerk- und Systemmanagement-Werkzeugen. In betrieblichen Unternehmensanwendungen findet die explizite Verarbeitung von Ereignissen dagegen nur in sehr begrenztem Umfang statt. Selbst wenn Ereignisse in Unternehmensanwendungen verarbeitet werden, so handelt es sich in der Regel um sehr einfache Ereignisse in graphischen Benutzungsoberflächen, nachrichtengesteuerten Systemen oder in der Anwendungsintegration [98]. Abbildung 2.6 stellt die Situation dar, wie Ereignisse typischerweise in Unternehmensanwendungen verarbeitet werden, die auf konventionellen Softwarearchitekturen basieren.2 Dargestellt ist die Verarbeitung von Ereignissen aus der fachlichen (Geschäftssicht) sowie aus der technischen Perspektive (Technologiesicht).

2 Unter konventionellen Softwarearchitekturen verstehen wir alle Arten von Softwarearchitekturen, die nicht auf der Verarbeitung von Ereignissen als zentralem Strukturierungskonzept basieren.

24


Geschäftssicht

Vergangenheitsperspektive bei Analyse des Zustands des Unternehmens

Geschäftsprozesse ablauforientierte Prozesse Betrachtung singulärer Ereignisse

Anwendungssysteme

Technologiesicht

starke Kopplung synchrone Kommunikation

Ereignisverarbeitung implizit und verstreut

Ereignisströme

Abb. 2.6 Ereignisse in konventionellen Unternehmensanwendungen

2.2.1 Geschäftssicht in konventionellen Architekturen Geschäftsereignisse beeinflussen wesentlich die fachlichen Abläufe in einem Unternehmen, wie bereits ausführlich in Abschnitt 2.1 diskutiert. Aus fachlicher Sicht sind hierbei die nachfolgenden Aspekte und Einschränkungen bemerkenswert. Vergangenheitsperspektive Qualifizierte unternehmerische Entscheidungen setzen eine möglichst exakte Kenntnis des Zustands des Unternehmens voraus (und selbstverständlich auch eine realistische Einschätzung der zukünftigen Marktentwicklung und der Wettbewerber). In konventionellen Informationssystemen erfolgt die Analyse des Unternehmenszustands in der Regel retrospektiv, also aus einer Vergangenheitsperspektive heraus. Diese Systeme beruhen auf einem statischen Datenverarbeitungsmodell, bei dem Ereignisse gespeichert, indexiert und abgefragt werden, um herauszufinden, was geschehen ist. Typische Anfragen sind z.B. folgende: • “Wie hoch war der Umsatz im vergangenen Monat?“ • “Wie viele Benutzer haben die Firmen-Homepage gestern aufgerufen?“ • “Wie viel Prozent der Aufträge wurden im letzten Quartal mit Verspätung ausgeliefert?“


25

Diese Aufbereitung der Unternehmensdaten aus der Vergangenheit ist Aufgabe des Business Intelligence (BI). Business Intelligence erfüllt eine enorm wichtige Funktion im Unternehmen und wird auch in Zukunft bedeutsame Auswertungen und Analysen für die Unternehmensführung liefern. Grenzen: Eine Sicht auf den aktuellen Zustand des Unternehmens, d.h. was passiert jetzt, ist jedoch nicht möglich, da hierfür die aktuellen Ereignisse in die Betrachtung mit einbezogen werden müssten. Gerade Überwachungs- und Kontrollsysteme sind aber stets auf aktuelle Informationen angewiesen, z.B. bei der Steuerung von Energienetzen oder der Überwachung des Netzbetriebs in Rechenzentren. Ereignisorientierung ist in diesem Kontext als Ergänzung des Business Intelligence um Echtzeitaspekte zu sehen. Geschäftsprozesse Ereignisse können die operative Ausführung der fachlichen Geschäftsprozesse eines Unternehmens außerordentlich stark beeinflussen (siehe Abschnitt 2.1.1). Ablauforientierte Prozesse Konventionelle Architekturansätze sind gut geeignet, wenn die zu unterstützenden Geschäftsprozesse ablauforientiert sind, d.h. durch einzelne Arbeitsschritte, Bedingungen, Abfragen, Kontrollstrukturen usw. beschrieben werden können. Die meisten geschäftlichen Tätigkeiten laufen in der unternehmerischen Praxis nach bestimmten Regeln ab, die die auszuführenden Aktivitäten und deren Reihenfolge determinieren. Durch die explizite Modellierung und die direkte Abbildung in einem Informationssystem werden diese Abläufe festgeschrieben und dadurch vereinheitlicht und standardisiert. Diese standardisierten Abläufe können somit direkt durch ein betriebliches oder technisches Informationssystem unterstützt werden. Hierbei kommen entweder Standardsoftwareprodukte zum Einsatz oder es muss eine individuelle Softwarelösung entwickelt werden. Diese Vereinheitlichung bildet die Voraussetzung, um die geschäftlichen Abläufe zu analysieren, zu reorganisieren und zu optimieren. Grenzen: Eine ablauforientierte Sicht auf Geschäftsprozesse stößt in vielen Anwendungsbereichen an ihre Grenzen, da reale Prozesse häufig parallel und asynchron ablaufen und durch Eingriffe von außen spontan veränderbar sein müssen. Geschäftliche Abläufe sind immer nur bis zu einem bestimmten Grad planbar, da es nicht möglich ist, bereits bei dem Entwurf des Prozesses alle Eventualitäten (= Ereignisse) vorherzusehen, die jemals den Prozess beeinflussen könnten. Betrachtung singulärer Ereignisse Ereignisse werden meistens nur singulär betrachtet, wodurch sich nur ein beschränkter Erkenntnisgewinn realisieren lässt. Ein einzelnes Ereignis kann einen Geschäftsablauf auslösen, beispielsweise setzt der Eingang eines Kundenauftrags den Auftragsbearbeitungsprozess in Gang, oder eine Ausnahmesituation darstellen, auf die durch einen manuellen Eingriff reagiert werden muss, z.B. die manuelle Sperrung einer Kreditkarte aufgrund einer telefonischen Verlustmeldung. Grenzen: Zwischen Ereignissen existieren häufig sehr komplexe Wechselwirkungen, die bei einer singulären Betrachtung nicht erkannt werden können. Aus den

26


beiden Ereignissen (a) “Kunde A bezahlt in San Francisco mit Kreditkarte 4321“ und (b) “Kunde A hebt in Hannover mit Kreditkarte 4321 fünfhundert Euro ab“, die im Abstand von wenigen Minuten auftreten, lässt sich ein komplexes Ereignis “Verdacht auf Kreditkartenbetrug“ ableiten. Bei isolierter Betrachtung beider Ereignisse wäre der mögliche Kreditkartenbetrug nicht oder erst im Nachhinein erkannt worden. Oder wenn mit einer Kreditkarte innerhalb von 30 Sekunden fünf Zahlungsvorgänge (= fünf Ereignisse) bei fünf verschiedenen Unternehmen erfolgen, deutet wiederum einiges auf einen Kreditkartenmissbrauch hin, und die Karte sollte umgehend gesperrt werden, um weiteren Schaden proaktiv zu vermeiden. Auch die Abstraktion von Ereignissen in einer Hierarchie auf mehreren Ebenen ist nicht möglich.

2.2.2 Technologiesicht in konventionellen Architekturen Eine gute Softwarearchitektur zeichnet sich dadurch aus, dass sie die Komplexität des Softwaresystems reduziert, indem sie eine sinnvolle Zerlegung in Teilsysteme oder Softwarekomponenten vornimmt [29]. Jede Komponente ist für einen abgegrenzten fachlichen oder technischen Aufgabenbereich verantwortlich und stellt ihrer Außenwelt eine Menge von Diensten zur Verfügung, die über wohldefinierte Schnittstellen genutzt werden können. Die Komponenten interagieren miteinander, indem eine Komponente (= Client) einen Dienst einer anderen Komponente aufruft. Aus technischer Sicht ist die Verarbeitung von Ereignissen in konventionellen Softwarearchitekturen typischerweise durch die nachfolgenden Eigenschaften charakterisiert.3 Anwendungssysteme Auf der Ebene der Anwendungssysteme kommt der Kopplung zwischen Systemkomponenten und der Kommunikationsstruktur eine große Bedeutung für die Flexibilität der Unternehmensanwendungen zu. Starke bis lose Kopplung Damit ein Client einen Dienst aufrufen kann, muss er den Namen, die Signatur (Parameterstruktur) und die technische Realisierung (Nachrichtenformate, Transportprotokolle, Server und ggf. die Programmiersprache) des Dienstes kennen. Die Komponenten sind hierbei stark gekoppelt, weil für den Aufruf eines Dienstes detaillierte Kenntnisse über die anbietende Komponente notwendig sind. Darüber hinaus sind häufig in den Entwurf der Schnittstelle eines Dienstes auch Annahmen über die aufrufende Komponente mit eingeflossen, wodurch die Kopplung weiter verstärkt wird. Durch Konzepte wie Service-orientierte Architekturen (siehe Abschnitt 2.4) lässt sich eine losere Kopplung erreichen. 3 Selbstverständlich existieren viele operative Systeme, auf die die aufgelisteten Eigenschaften nicht oder nur teilweise zutreffen. Aber in der überwiegenden Mehrzahl der Unternehmensanwendungsarchitekturen lassen sich diese charakteristischen Eigenschaften wiederfinden.


27

Synchrone Kommunikation Die Kommunikation zwischen zwei Komponenten erfolgt typischerweise nach dem Request/Reply-Interaktionsmuster, wie in Abbildung 2.7 dargestellt. Bei dieser Form der Interaktion stellt eine sendende Komponente eine Anfrage an eine empfangende Komponente, die die Anfrage verarbeitet und eine Antwort an den Sender mit dem Ergebnis der Anfrage zurückschickt.

Anfrage Sendende Komponente

Empfangende Komponente Antwort

Abb. 2.7 Request/Reply-Interaktion zwischen zwei Komponenten

Request/Reply wird häufig innerhalb von Geschäftsprozessen für den Aufruf von Diensten genutzt und realisiert eine dedizierte 1:1-Beziehung zwischen sendender und empfangender Komponente. Die sendende Komponente bestimmt hierbei den Kontrollfluss und damit die Reihenfolge der Abarbeitung. Der Aufruf eines Dienstes erfolgt in der Regel synchron, d.h. die aufrufende Komponente wartet, bis die aufgerufene Komponente die Anfrage bearbeitet und ggf. einen Rückgabewert als Ergebnis liefert. Die Verwendung von asynchronen Aufrufen eines Dienstes führt dazu, dass der Client nicht durch einen Dienstaufruf blockiert wird. Ereignisverarbeitung Die Verarbeitung von Ereignissen erfolgt direkt an den Stellen im Source-Code, an denen das Ereignis benötigt wird. Folglich ist der Source-Code für die Ereignisverarbeitung über die betroffenen Komponenten und damit häufig über das gesamte System verstreut. Im Normalfall ist das Wissen über die Verarbeitung nicht explizit formuliert, sondern mittels einer imperativen oder objektorientierten Programmiersprache festverdrahtet bzw. hartcodiert im Anwendungscode enthalten, demnach handelt es sich um eine implizite Form der Ereignisverarbeitung. Grenzen konventioneller Technologien Jede Unternehmensanwendung unterliegt einer permanenten Weiterentwicklung aufgrund sich ändernder fachlicher und technischer Anforderungen. Qualitätsmerkmale einer Softwarearchitektur wie Erweiterbarkeit und Wartbarkeit beeinflussen wesentlich die Möglichkeiten eines Unternehmens, effizient und effektiv auf neue Marktbedingungen zu reagieren, um sich im Wettbewerb zu behaupten. Die Verteilung der Ereignisverarbeitung über viele Komponenten, eine starke Kopplung und eine synchrone Kommunikation verkomplizieren die Änderung und Weiterentwicklung der Unternehmensanwendungen und beschränken damit die Agilität des Unternehmens.

28


2.3 Ereignisorientierung als Architekturstil Ereignisgesteuerte Geschäftsprozesse besitzen besondere Eigenschaften, die sie von traditionellen, ablauforientierten Prozessen unterscheiden. Obwohl es sich bei ereignisgesteuerten Geschäftsprozessen in erster Linie um ein fachliches Phänomen handelt, ergeben sich direkte Auswirkungen auf die Unternehmensanwendungen und deren zugrunde liegende Softwarearchitektur. Viele Aspekte von ereignisgesteuerten Geschäftsprozessen können nur implementiert werden, wenn auch die darunter liegenden Anwendungssysteme ereignisgesteuert sind – ereignisgesteuerte Prozesse benötigen ereignisgesteuerte Anwendungsarchitekturen [98]. Event-Driven Architecture (EDA) führt Ereignisorientierung als Architekturstil für Unternehmensanwendungen ein, indem die Verarbeitung von Ereignissen als zentrales Konzept in den Fokus der Architektur rückt. Komponenten interagieren durch den Austausch von Ereignissen miteinander, Ereignisse werden identifiziert, transformiert, korreliert und bewertet, Ereignisströme aus unterschiedlichen Quellen werden analysiert und Muster in den Ereignisströmen erkannt. Ereignisgesteuerte Geschäftsprozesse und ereignisgesteuerte Unternehmensanwendungen helfen Unternehmen schnell und angemessen auf sich verändernde Marktbedingungen zu reagieren. Ereignisgesteuerte Prozesse beruhen auf dem Erkennen von Ereignissen und dem Auslösen einer angemessenen Reaktion. Konventionelle Anwendungsarchitekturen sind zu statisch, unflexibel und schwerfällig, um dies entsprechend zu implementieren. Der Schwerpunkt konventioneller Architekturen liegt auf dem Ausführen von vordefinierten, klar strukturierten Prozessen. Abbildung 2.8 visualisiert die Geschäfts- und Technologiesicht einer Anwendungsarchitektur, die auf der Verarbeitung von Ereignissen als zentralem Gestaltungsprinzip beruht. Im Vergleich zu Abbildung 2.6 in Abschnitt 2.2 ergeben sich signifikante Änderungen auf allen Ebenen der beiden Sichten.

2.3.1 Geschäftssicht in ereignisorientierten Architekturen Abschnitt 2.1 geht ausführlich auf die fachliche Bedeutung von Geschäftsereignissen für das Erreichen der Geschäftsziele eines Unternehmens ein. Die Ereignisorientierung als Stil der Softwarearchitektur soll es ermöglichen, das enorme fachliche Potenzial der Ereignisverarbeitung auszuschöpfen und die Kluft zwischen Fachlichkeit und IT-technischer Unterstützung zu überbrücken. Gegenwartsperspektive Fundierte unternehmerische Entscheidungen können nur getroffen werden, wenn die Entscheider ein realistisches Bild auf der Basis aktueller und konsistenter Kennzahlen vom gegenwärtigen Status der Geschäftsprozesse bzw. vom Zustand des Unternehmens haben. Die systematische Auswertung von historischen Daten liefert

2.3 Ereignisorientierung als Architekturstil

29

Geschäftssicht

Gegenwartsperspektive Dashboards

Meldungen

Leitstände

EchtzeitInformationskanäle

Geschäftsprozesse ereignisorientierte Prozesse Betrachtung von Ereignismustern

Anwendungssysteme

Technologiesicht

Entkopplung asynchrone Kommunikation

CEP

Complex Event Processing

Ereignisverarbeitung explizit und deklarativ

Ereignisströme

Abb. 2.8 Ereignisorientierte Unternehmensanwendungen

hierzu wertvolle Erkenntnisse, für viele Entscheidungen ist aber das Verständnis des Jetzt, also der Gegenwart, wesentlich. Event-Driven Architecture liegt ein dynamisches Datenverarbeitungsmodell zugrunde, bei dem die Daten zum Zeitpunkt ihres Auftretens erkannt und verarbeitet werden. Die persistente Speicherung der Ereignisdaten erfolgt erst im Anschluss an die Verarbeitung. Betriebliche Ereignisse werden so dynamisch überwacht, um sie in Echtzeit (real time) zu analysieren und in Echtzeit operative Entscheidungen zu treffen. Typische Fragestellungen sind z.B. folgende: • “Wie viele Kunden sind zurzeit online im System aktiv?“ • “Wo befindet sich der Container mit dem Kennzeichen DCBA in diesem Augenblick?“ • “Hält sich in diesem Moment ein nicht autorisierter Benutzer in meinem ITSystem auf?“ • “Welche Fahrzeuge sind von der gerade eingegangenen Verkehrsmeldung betroffen?“ Ereignisorientierung in Unternehmensanwendungen ermöglicht somit Informationskanäle in Echtzeit, die die relevanten Kennzahlen und Unternehmensindikatoren auf einem für den menschlichen Entscheider angemessenen Abstraktionsgrad aggregieren. Die Aktualität der Informationen ermöglicht bessere operative Entscheidungen und schnelle und nachvollziehbare Reaktionen auf bedeutsame Situationen.

30


Die resultierenden BAM-Anwendungen (Business Activity Monitoring) werden in Abschnitt 2.5 ausführlich diskutiert. Geschäftsprozesse Die Prozessebene ist die entscheidende Ebene für die Ereignisverarbeitung, da auf dieser Ebene die fachlichen Entscheidungen über operative Abläufe getroffen werden. Ereignisorientierte Prozesse Sämtliche fachlichen Abläufe in einem Unternehmen werden maßgeblich durch Ereignisse beeinflusst. Manche Ereignisse lassen sich bereits bei der Modellierung der Geschäftsprozesse vorhersehen und im Entwurf des Prozessablaufs berücksichtigen. Andere Ereignisse dagegen treten unerwartet auf und erfordern eine spontane Änderung des Prozessablaufs von außen. Das Erkennen und Reagieren auf Ereignisse spielt also eine wesentliche Rolle bei der Steuerung der Unternehmensprozesse. Die ereignisgesteuerte Implementierung von ereignisgesteuerten Geschäftsprozessen ergibt signifikante Vorteile, da sie die inhärent ereignisgesteuerte Natur vieler Aspekte der realen Welt besser abbildet. Betrachtung von Ereignismustern Wertvolle Informationen liegen nicht nur in den Ereignissen selbst verborgen, sondern, wie in Abschnitt 2.1.3 erläutert, vor allem in den Beziehungen und Zusammenhängen zwischen mehreren Ereignissen. Das Erkennen von Ereignismustern in dem Strom der eingehenden Ereignisse ist essenzieller Bestandteil der Ereignisorientierung. In eine Unternehmensanwendung können Ereignisströme aus diversen Quellen und in sehr, sehr großen Volumina einfließen, die nach dem Auftreten von Ereignismustern innerhalb und zwischen Strömen untersucht werden müssen. Durch die Korrelation von zusammenhängenden Ereignissen zu komplexen Ereignissen auf einer höheren Abstraktionsebene können Fehler, Ausnahmesituationen und sich anbahnende Probleme frühzeitig erkannt und entsprechende Maßnahmen oder Warnungen proaktiv in Echtzeit veranlasst werden (sense-and-respond behavior [99]). Ereignisse treten auf allen Ebenen einer Anwendungsarchitektur auf, und zwar in ganz unterschiedlichen Abstraktionsgraden, und müssen demnach auch auf allen Ebenen verarbeitet werden.

2.3.2 Technologiesicht in ereignisorientierten Architekturen Die Ereignisorientierung als Architekturstil benötigt in der Umsetzung eine leistungsfähige Technologie zur komplexen Ereignisverarbeitung. Complex Event Processing (CEP) ist solch eine Technologie zur dynamischen Verarbeitung von Ereignissen [63]. CEP analysiert die Ströme von Ereignissen aus unterschiedlichen Quellen nach temporalen oder kausalen Ereignismustern und kann beim Erkennen eines Musters entsprechende Aktionen, z.B. Generierung eines neuen Ereignisses, Warnungen, Meldungen, Aufruf eines Dienstes, initiieren.


31

Anwendungssysteme Auf der Anwendungssystemebene sollte, an den Stellen, wo dies sinnvoll erscheint, die Kommunikation zwischen Komponenten durch den Austausch von Ereignissen realisiert werden. Entkopplung Die Kommunikation zwischen zwei Komponenten erfolgt in einer ereignisgesteuerten Architektur durch den Austausch von Ereignissen bzw. Ereignisobjekten – in der Regel in Form von Nachrichten (messages). Die Komponente, die das Ereignis erzeugt (= Ereignisquelle), leitet dies als Nachricht an eine Middleware weiter, ohne zu wissen, wie und wo die Weiterverarbeitung erfolgt. Komponenten, die ein Ereignis eines bestimmten Typs verarbeiten wollen (= Ereignissenke), müssen sich bei der Middleware registrieren und bekommen dann alle Ereignisse dieses Typs zugestellt. Die kommunizierenden Ereignisquellen und -senken kennen sich nicht gegenseitig. Grundvoraussetzung ist natürlich eine vorhergehende Verständigung über die Semantik der ausgetauschten Nachrichten. Gemeinsam mit einem asynchronen Interaktionsmuster ergibt sich eine äußerst lose Kopplung bzw. Entkopplung der Komponenten. Asynchrone Kommunikation Die Kommunikation zwischen Ereignisquelle und -senke erfolgt asynchron nach dem Publish/Subscribe-Interaktionsmuster. Die Ereignisquelle setzt ihre Verarbeitung unmittelbar fort, sobald sie eine Nachricht gesendet hat. Asynchronität und Entkopplung bilden die Basis für die hohe Interoperabilität von EDA und damit für deren Einsatz als Integrationsinfrastruktur, siehe auch Abschnitt 2.5.4. Ereignisverarbeitung Die Verarbeitung der Ereignisse erfolgt zentral in einer CEP-Komponente, in der die eingehenden Ereignisströme analysiert werden. Die Ereignisse werden erkannt, transformiert, klassifiziert und aggregiert und somit den Unternehmensanwendungen fachlich aufbereitet zur Verfügung gestellt. In CEP wird das Wissen über die Ereignisverarbeitung deklarativ in Form von Regeln formuliert, mit denen komplexe Muster von Ereignissen überprüft werden können. Ein Regelinterpreter interpretiert die Regeln entsprechend einem definierten Verarbeitungsmodell und wendet sie so auf die Ereignisströme an. Aufgrund der expliziten und deklarativen Repräsentation des fachlichen Wissens über die Ereignisverarbeitung lassen sich die Geschäftsprozesse ohne Unterbrechung des laufenden Betriebs flexibel anpassen (on-the-fly modification).

2.3.3 Fachliche Gesamtsicht der Ereignisorientierung Die Idee von Event-Driven Architecture beruht auf der Ereignisorientierung als Architekturstil und besitzt ein weitreichendes fachliches Potenzial. Aus der Ereignis-

32


orientierung ergeben sich folgende Chancen bei der Realisierung betrieblicher Unternehmensanwendungen: • Echtzeitfähigkeit für Aktualität der operativen Entscheidungen, • Erkennen und Reagieren auf einfache und komplexe Ereignismuster für eine schnelle unternehmerische Reaktionsfähigkeit, • Betrachtung von Ereignissen auf unterschiedlichen Abstraktionsebenen für mehr Transparenz der unternehmerischen Entscheidungen, • Verarbeitung von kontinuierlich und in großen Mengen einströmenden Ereignissen für eine höhere Effizienz der Prozessabläufe, • wirklichkeitsnahe Modellierung fachlicher Prozesse, • Flexibilität und Agilität der Anwendungssysteme. Das Ausschöpfen des fachlichen Potenzials der durch Event-Driven Architecture in die Anwendungsarchitektur von Unternehmen eingeführten Ereignisorientierung bietet die Aussicht auf 1. Anwendungssysteme, die durch EDA effizienter und transparenter werden und damit zu einer Optimierung der unterstützten Geschäftsprozesse beitragen, und darüber hinaus auf 2. neue Anwendungssysteme, die ohne EDA bisher nicht realisierbar waren, beispielsweise für betriebliche Prozesse, die aufgrund der extrem großen Datenmenge oder der strikten Echtzeitanforderungen bisher nicht oder nur unzureichend unterstützt werden konnten. Die sinnvolle und effiziente Verarbeitung von Geschäftsereignissen erfordert einerseits eine leistungsfähige Technologie zur Ereignisverarbeitung, diese steht mit Complex Event Processing zur Verfügung (siehe Kapitel 4, 5 und 6), andererseits aber auch eine ausgeprägte fachliche Expertise. Fachexperten müssen die Ereignismodelle verstehen und entwerfen, die die Abhängigkeiten und Beziehungen zwischen Ereignisobjekten innerhalb eines Ereignisstroms bzw. zwischen Ereignisströmen sowie im Kontext mit historischen Daten modellieren und gemeinsam mit IT-Experten als deklarative Regeln implementieren [107]. Geschäftliche Ereignisse in den Fokus der Architektur zu stellen, erfordert das intensive Zusammenwirken von Fachlichkeit und Technik. Zusammenfassende Gegenüberstellung konventioneller und ereignisorientierter Ansätze Die Diskussion konventioneller und ereignisorientierter Architekturansätze hinsichtlich ihrer prägenden Eigenschaften im Hinblick auf die Verarbeitung von Geschäftsereignissen hat signifikante Unterschiede hervorgebracht, die in den beiden nachfolgenden Tabellen zusammenfassend gegenübergestellt sind. Die Tabelle 2.1 führt die wesentlichen Aspekte konventioneller und ereignisorientierter Softwarearchitekturen aus Geschäftssicht auf.


33

Tabelle 2.1 Gegenüberstellung konventioneller und ereignisorientierter Architekturen aus Geschäftssicht Eigenschaft

Konventionelle Architekturen

Perspektive auf Un- Vergangenheitsperspektive ternehmenszustand

Ereignisorientierte Architekturen Gegenwarts- und Vergangenheitsperspektive; Echtzeitfähigkeit

Prozesssicht

ablauforientierte zesse

Geschäftspro- ereignisgesteuerte Geschäftsprozesse

Ereignisverarbeitung

singuläre Betrachtung einzelner einfache und komplexe EreignisEreignisse muster über mehrere Ereignisse

Abstraktionsgrad

eine Abstraktionsebene

Abstraktion von einfachen zu fachlich höherwertigen Ereignissen; Hierarchie von Abstraktionsebenen

Mengengerüst

wenige Ereignisse

Verarbeitung von Massenereignisdaten aus multiplen Ereignisströmen

In Tabelle 2.2 sind die wesentlichen Aspekte von konventionellen und ereignisorientierten Architekturansätzen aus Technologiesicht gegenübergestellt. Tabelle 2.2 Gegenüberstellung konventioneller und ereignisorientierter Architekturen aus Technologiesicht Eigenschaft

Konventionelle Architekturen

Ereignisorientierte Architekturen

Grad der Kopplung

starke bis lose Kopplung von äußerst lose Kopplung oder EntKomponenten kopplung von Komponenten; Ereignisquelle kennt Ereignissenke nicht; Verwendung von Ereignissen als Kommunikationsmechanismus zwischen Komponenten

Interaktionsmuster

synchrone oder asynchrone Kom- asynchrone Kommunikation munikation

Kontrollfluss

Client bestimmt Kontrollfluss Ereignissenke/-empfänger bedurch Service-Aufruf (request- stimmt den Kontrollfluss aufgrund driven) des empfangenen Ereignisses (event-driven)


implizit (nicht explizit formuliert) explizit in CEP-Komponente; Wisund über System verstreut sen über Ereignisverarbeitung deklarativ in Form von Regeln formuliert

34


2.4 EDA und SOA Der Ansatz der Service-orientierten Architektur (SOA) stellt ebenso wie EventDriven Architecture (EDA) einen Architekturstil zur Strukturierung von Unternehmensarchitekturen dar. Sowohl aufgrund der Relevanz von SOA für den Entwurf von Softwarearchitekturen in der Praxis als auch durch einige Unklarheiten in der Abgrenzung zwischen SOA und EDA wird in diesem Abschnitt eigens die Beziehung der beiden Ansätze betrachtet. EDA und SOA stellen komplementäre Konzepte dar, die sowohl eigenständig als auch in Kombination eingesetzt werden können. Eine EDA kann problemlos ohne SOA-Konzepte und -Technologien realisiert werden, und eine SOA kommt ebenso ohne explizite Ereignisverarbeitung aus. Die gewichtige Relevanz von SOA in der Praxis wird auch in Zukunft bestehen bleiben, und SOA wird auch weiterhin für viele Anwendungsgebiete die erste Wahl sein. Nach einer kurzen Vorstellung der grundsätzlichen Idee von SOA werden in diesem Abschnitt die beiden Architekturstile vergleichend gegenübergestellt sowie das Potenzial aufgezeigt, das aus einer fruchtbaren Kombination der beiden Ansätze entstehen kann.

2.4.1 Grundidee von SOA Das Ziel einer Service-orientierten Architektur liegt in der besseren Unterstützung der fachlichen Geschäftsprozesse eines Unternehmens durch die Flexibilisierung der IT-Infrastruktur – Unternehmensstrategie und Informationstechnologie sollen näher zusammengeführt werden. Die SOA-Vision einer auf die Geschäftsprozesse und strategischen Ziele ausgerichteten IT-Landschaft ist in Abbildung 2.9 dargestellt.

Geschäftssicht

Strategie

Prozesse

Technologiesicht

Domänen

Applikationen

Technologien

Abb. 2.9 Geschäftsdomänen als zentrales Element einer SOA

Zentrales Element einer SOA sind die Geschäftsdomänen, die die Geschäftsprozesse mit den im Unternehmen vorhandenen Unternehmensanwendungen verbinden [32]. Die Geschäftsprozesse verwenden nicht unmittelbar die verschiedenen Anwendungssysteme, sondern nutzen die in den Domänen bereitgestellten Services

2.4 EDA und SOA

35

(Dienste). Die Domänen stellen unternehmensweit ein technologieunabhängiges Service-Portfolio zur Verfügung, das die Geschäftsprozesse von den konkreten Anwendungen – und damit auch von den in ihnen genutzten Technologien – entkoppelt. Jeder Service kapselt somit Geschäftsfunktionalität, die in einer einzelnen Komponente mittels einer spezifischen Technologie realisiert ist. Eine fachliche Abfolge von Aktivitäten in einem Geschäftsprozess wiederum kann durch die Orchestrierung von anwendungsunabhängigen Services realisiert werden, d.h. es wird ein linearer Ablauf in einer Programmier- oder Prozessbeschreibungssprache, wie z.B. BPEL (Business Process Execution Language [79]), festgelegt. In BPEL lassen sich Prozesse durch einzelne Arbeitsschritte, Abfragen, Schleifen usw. adäquat beschreiben, wie dies bei ablauforientierten Geschäftsprozessen der Fall ist (siehe Abschnitt 2.2). Aus Geschäftssicht stellt sich die ITInfrastruktur eines Unternehmens somit nicht mehr als Menge von Applikationen dar, sondern als unternehmensweites Service-Portfolio, das im Sinne einer optimalen Unterstützung der Geschäftsziele kontinuierlich weiterentwickelt wird. SOA basiert auf wohlverstandenen Prinzipien der Kapselung wiederverwendbarer Funktionalität sowie der losen Kopplung von Komponenten und überträgt diese auf die Ebene der unternehmensweiten Anwendungsarchitektur. Die Services sind in verschiedenen Softwarekomponenten (service provider) realisiert und bilden so die Bausteine, aus denen sich sämtliche unternehmenseigenen Geschäftsprozesse flexibel zusammensetzen lassen. Die Logik der Geschäftsprozesse ist nicht auf einzelne Anwendungen verteilt, sondern in einer dedizierten Prozessschicht definiert und implementiert. Die Abbildung 2.10 veranschaulicht das Zusammensetzen von Geschäftsprozessen aus Services und den ablauforientierten Charakter der Prozesse. Aus den von den Komponenten bereitgestellten Services wird in der Prozessschicht ein fachlicher Ablauf zusammengesetzt. Geschäftsprozessschicht

A

B

C

Komponente 1

Softwarekomponente

D

E

Komponente 2

Service

Y

...

Z

Komponente n

Serviceaufruf

Abb. 2.10 Service-Orientierung mit Geschäftsprozessschicht (nach [28])

Der Aufruf und die Ausführung von Services sollte möglichst technologieunabhängig durch eine entsprechende Middleware bewerkstelligt werden. Dies geschieht durch einen Enterprise Service Bus (ESB), der den technologieneutralen Aufruf

36


von in unterschiedlichsten Implementierungsparadigmen realisierten Services ermöglicht. Ein ESB führt somit zu einer Homogenisierung der eingesetzten Technologien und definiert einen unternehmensweiten Standard für die Kommunikation zwischen Softwarekomponenten. Alternativ können auch Web Services als offene, auf XML-basierende Middleware-Standards zum Einsatz kommen [5]. Die Kommunikation zwischen einem Client (service requester) und dem Anbieter eines Service erfolgt in der Regel nach dem Request/Reply-Interaktionsmuster. Die Service-Aufrufe können sowohl synchron als auch asynchron erfolgen. Die Beschreibung der Schnittstelle (interface description) eines Service beinhaltet alle Informationen, die ein Client benötigt, um den Service aufzurufen. Das sind Name, Parameterstruktur, Format- und Protokollangaben und Serveradresse des Service. Bei Web Services kommen SOAP als standardisiertes Nachrichtenformat und die Sprache WSDL (Web Services Description Language) zur Schnittstellenbeschreibung zum Einsatz [5]. SOA geht deutlich über bisherige EAI-Ansätze (Enterprise Application Integration) hinaus, die vornehmlich technologiegetrieben waren und die technische Integration von Anwendungen zum Ziel hatten. SOA bietet vielmehr eine Vision, wie Geschäftsprozesse und Anwendungslandschaften zusammenwachsen können und wie die Unternehmensanwendungen an den geschäftlichen Erfordernissen ausgerichtet werden können. Der entscheidende Mehrwert einer SOA liegt in der fachlich motivierten Ausrichtung der IT-Systeme auf die Unternehmensziele [32]. Die Einführung einer SOA ist deshalb in erster Linie keine softwarearchitekturelle Entscheidung, sondern primär eine organisatorische. Wesentlich ist deshalb die Etablierung einer entsprechenden SOA-Governance, die ein organisatorisches und technisches Rahmenwerk für die Umsetzung einer SOA definiert [92].

2.4.2 Gegenüberstellung von SOA und EDA Ähnlich wie SOA beschäftigt sich auch EDA primär mit fachlichen Fragestellungen, da die Ereignisse, die betrachtet werden, fachlichen und somit unmittelbar geschäftsrelevanten Charakter haben. Service-Orientierung eignet sich hervorragend, wenn es darum geht, ablauf- bzw. prozessorientierte Geschäftsprozesse zu realisieren. Insbesondere bei synchronen Aufrufen oder Transaktionen hat dieser Architekturansatz seine Stärken. Klassische Geschäftsprozesse sind in der Regel service-orientiert implementiert [28]. Der SOA-Ansatz beinhaltet jedoch nicht die Konzepte, die notwendig sind, um Echtzeit-Unternehmensanwendungen zu ermöglichen und die Dynamik ereignisgesteuerter Geschäftsprozesse zu unterstützen [107]. Ohne Ereignisverarbeitung ist es nicht möglich, den aktuellen Status geschäftlicher Aktivitäten zu erkennen, hierzu müssen in Echtzeit temporale und kausale Beziehungen zwischen betrieblichen Geschäftsereignissen erkannt und ausgewertet werden. In Tabelle 2.3 sind die wesent-

2.4 EDA und SOA

37

lichen charakteristischen Eigenschaften von SOA und EDA einander vergleichend gegenübergestellt.4 Tabelle 2.3 Charakteristische Eigenschaften der Architekturstile SOA und EDA (nach [76]) Eigenschaft

SOA

EDA

Entwurfsfokus

Service und Service-Schnittstelle Ereignis und Ereignisnachricht (interface) (messages)

Verarbeitungsmodell

Ein Client ruft die Funktionalität eines Service auf und erwartet i.d.R. eine Antwort. Der Service führt Anfragen des Client aus, und zwar als Teil der LUW des Client.

Modularität

modular durch Services und Cli- modular durch konzeptionelle ents Trennung von Ereignissenken und -quellen

Verteilbarkeit

Technologie-inhärent

Ereignisquelle sendet eine Nachricht mit den Daten über das Auftreten eines Ereignisses an eine Middleware. Ein registrierter Empfänger (Ereignissenke) bemerkt die Ankunft einer Ereignisnachricht und verarbeitet sie unmittelbar. Das Ereignis selbst enthält keine Informationen über seine weitere Verarbeitung.


Typisches Kommuni- Request/Reply, sowohl synchron Publish/Subscribe mit Pushkationsmuster als auch asynchron Modus, asynchron, mehrere Ereignissenken Transaktionsbereich (LUW)

Client und Service bilden eine Ereignisquelle und -senke bilden LUW zwei unabhängige LUW

Transaktionskontrolle (LUW)

Client behält Kontrolle

Beziehung zwischen Client kennt Aufgabe, Name und Komponenten Adresse eines Service; Service muss bei Aufruf verfügbar sein. Nur der Service selbst kennt seine Implementierung.

Ereignisquelle und -senke kontrollieren unabhängig jeweils ihre LUWs Ereignisquellen und -senken kennen sich nicht. Ereignisquelle hat kein Wissen über Senke, nicht mal darüber, ob diese verfügbar ist oder überhaupt existiert.

Abhängigkeit zwi- Schnittstellendefinition und Versi- Schema der Ereignisnachricht und schen Komponenten on, SLAs Version Grad der Kopplung

lose Kopplung

äußerst lose Kopplung oder Entkopplung von Komponenten

LUW = logical unit of work

4 Die Gegenüberstellung in der Tabelle greift einige Eigenschaften von EDA vorweg, die erst in Kapitel 3 eingeführt werden. Für eine ausführliche Erläuterung der Haupteigenschaften einer EDA sei auf Abschnitt 3.1 verwiesen.

38


2.4.3 SOA + EDA = Event-Driven SOA Die beiden Architekturstile SOA und EDA ergänzen sich geradezu ideal, da beide Ansätze stark fachlich motiviert sind und das Ziel einer agileren IT-Infrastruktur verfolgen. Eine SOA kann dadurch von Ereignissen profitieren, dass ein betriebliches Ereignis die Ausführung eines separaten Service oder einer Reihe von Services auslösen kann, um ein Geschäftsproblem zu behandeln. Das Ergebnis eines Service oder einer Orchestrierung von Services ist oft ein weiteres Geschäftsereignis. Durch die Modellierung der Ereignisverarbeitung als Service lassen sich beispielsweise äußerst elegant Legacy-Systeme in eine SOA integrieren (siehe z.B. Event Web Service in [106], Seite 113). Der Datenstrom der Legacy-Systeme wird hierbei durch die Ereignisverarbeitung aufbereitet und damit für eine SOA verfügbar. In einer ähnlichen Weise ermöglicht eine um Ereignisse angereicherte SOA agile, adaptive Geschäftsprozesse, die flexibel und zeitnah auf sich verändernde Chancen und Bedrohungen reagieren können. Eine EDA kann grundsätzlich von den Geschäftszielen und der organisatorischen Verankerung einer SOA profitieren, da es sich bei SOA ebenfalls um ein fachliches Konzept handelt. Aufgrund der flexiblen Komponentenarchitektur einer SOA können Services in einer EDA auf praktisch jeder funktionalen Ebene in der Architektur integriert werden. Aus Integrationssicht kommunizieren fachlich stark zusammenhängende Komponenten mittels Service-Aufrufen miteinander. Im Gegensatz dazu sollte sowohl die Kommunikation zwischen lose gekoppelten Komponenten als auch die Kommunikation über Unternehmensgrenzen hinweg durch den Austausch von Ereignissen erfolgen. Die Konzepte EDA und SOA sind also nicht als substituierend, sondern in erster Linie als komplementär zu betrachten. Statt Services mittels einer Prozessbeschreibungssprache zu neuen Geschäftsprozessen zu orchestrieren, werden Muster in Ereignisströmen gesucht, die entsprechende Services anstoßen. Durch EDA kann eine SOA intelligenter, reaktionsschneller und echtzeitfähig werden. Die Firma TIBCO bezeichnet die Erweiterung einer SOA um Ereignisverarbeitung als “Event-Driven SOA“ [107] bzw. ereignisgesteuerte SOA, die Firma Gartner prägte der Begriff “advanced SOA“ [76]. Eine ereignisgesteuerte SOA stellt den nächsten konsequenten Schritt in der Weiterentwicklung einer Service-orientierten Architektur dar.

2.5 Anwendungsgebiete für EDA

39

2.5 Anwendungsgebiete für EDA Betriebliche Ereignisse spielen in vielen Unternehmensbereichen und -prozessen eine signifikante geschäftliche Rolle (siehe die Diskussion in Abschnitt 2.1). Nur wenige Geschäftsprobleme erfordern jedoch eine exklusive EDA-Lösung. Vielmehr bietet sich für die meisten Unternehmensanwendungen eine Kombination von konventionellen und ereignisgesteuerten Softwarearchitekturen an, in der beide Ansätze ihre Vorteile an den richtigen Problemstellen einbringen können. Stark strukturierte Geschäftsprozesse mit seltenen Ausnahmen und ohne Echtzeitanforderungen lassen sich durch konventionelle Architekturen gut unterstützen. In diesem Abschnitt werden einige Anwendungsbereiche identifiziert, die für ereignisorientierte Softwarearchitekturen prädestiniert erscheinen und sich mit konventionellen Ansätzen nur schwer oder unzureichend lösen lassen. Geschäftsprobleme, die eine oder mehrere der folgenden funktionalen und nichtfunktionalen Anforderungen aufweisen, kommen als aussichtsreiche Anwendungsbereiche für einen ereignisgesteuerten Ansatz in Frage (u.a. nach [20]): 1. Komplexe Fachlogik Unterstützung komplexer Verarbeitungsprozesse (wie z.B. komplexe Aggregationen über homogene oder heterogene Daten, Korrelationen von aktuellen und historischen Daten, Erkennen von Ereignismustern (pattern matching), Daten auf verschiedenen Abstraktionsebenen, Aktionen aufgrund der Abwesenheit von Ereignissen) 2. Große Datenvolumina Abarbeitung einer extrem hohen Anzahl von Daten bzw. Nachrichten, die kontinuierlich in hoher Eingangsrate eintreffen (im Bereich von tausend bis zu hunderttausend Daten pro Sekunde und darüber hinaus) 3. Geringe Latenzzeit Reaktion in Echtzeit (real-time) auf eingetretene Ereignisse bzw. Systemzustände (im Bereich von Millisekunden bis Sekunden) 4. Skalierbarkeit Skalierbarkeit aufgrund steigenden Daten- oder Transaktionsaufkommes 5. Agilität Einfache Änder- und Wartbarkeit der Unternehmensanwendung aufgrund einer hohen fachlichen Agilität der Anwendungsdomäne Anwendungsgebiete in den Bereichen Kontroll- und Überwachungssysteme (Abschnitt 2.5.1), Sensornetzwerke (Abschnitt 2.5.2), Analytik (Abschnitt 2.5.3) und Enterprise Application Integration (Abschnitt 2.5.4) sind geprägt durch obige Anforderungen. Der Einsatz von EDA besitzt in diesen Anwendungsbereichen ein besonders hohes fachliches Potenzial.

40


2.5.1 Monitoring Das Ziel von Monitoring-Anwendungen ist die Kontrolle und Überwachung des Verhaltens von technischen oder betrieblichen Systemen. Die Basis hierfür ist eine exakte Kenntnis des jetzigen Status der internen Prozesse bzw. des Zustands des Gesamtsystems. Auch der externe Kontext eines Systems oder Unternehmens kann eine wichtige Rolle spielen, z.B. das Verhalten von Wettbewerbern oder Partnerunternehmen. Monitoring-Anwendungen sind charakterisiert durch die Auswertung einer Vielzahl von Ereignissen in Echtzeit. Singuläre Ereignisse sind in der Regel in diesem Kontext wenig aussagekräftig, aber die Korrelation, Zusammenfassung und Aggregation von Ereignissen aus unterschiedlichen Quellen zu Indikatoren und Prozesskennzahlen auf einer höheren Abstraktionsebene liefert den notwendigen Informationsgehalt, und zwar zeitnah. Business Activity Monitoring Business Activity Monitoring (BAM) unterstützt das Fällen von operativen Geschäftsentscheidungen sowie das Erkennen von Problemsituationen bzw. von sich anbahnenden Problemen durch die Bereitstellung der geschäftsrelevanten Informationen in Echtzeit [71]. Aussagekräftige Informationen über den gegenwärtigen Status und die Resultate von Geschäftsabläufen, Prozessen und Transaktionen werden analysiert, gebündelt und aufbereitet, so dass Prozessverantwortliche bei Bedarf zeitnah, umfassend und übersichtlich auf alle relevanten Informationen zugreifen können. Basierend auf ausgewählten Unternehmensindikatoren (key performance indicator, KPI) lassen sich so Entscheidungen qualifizierter treffen und die Geschäftsprozesse dynamisch entsprechend den Unternehmenszielen beschleunigen und anpassen. Da sich die Informationen an Fachexperten richten, ist es besonders wichtig, die Informationen in dem für den jeweiligen Benutzerkreis angemessenen Abstraktionsgrad bereitzustellen. Hierbei kommt der übersichtlichen Präsentation und Visualisierung der Prozesskennzahlen eine besondere Bedeutung zu. Die Kennzahlen sind quantitative Daten, die zahlenmäßig erfassbare betriebswirtschaftliche Sachverhalte verdichtet darstellen. Ähnlich einem Tachometer signalisieren in sogenannten Dashboards z.B. grüne und rote Bereiche, welche Kennzahlen normale oder kritische Werte aufweisen oder einen Schwellenwert überschreiten. Aufgrund der besonderen Relevanz der Visualisierung für BAM greift Abschnitt 6.4 explizit dieses Thema bei der Behandlung von Ereignissen auf. Detailinformationen über eine spezifische Prozesskennzahl können über eine Drill-down-Funktionalität abgefragt werden. Abbildung 2.5 zeigt eine solche Drilldown-Funktionalität anhand der Nachverfolgung der kausalen Beziehungen zwischen Ereignissen. Die Einflussfaktoren (= Ereignisse), die für das Zustandekommen der Kennzahl verantwortlich sind, lassen sich so identifizieren und es können entsprechende Gegenmaßnahmen eingeleitet werden.


41

Im Einzelnen soll Business Activity Monitoring unter anderem folgende Anforderungen erfüllen: • BAM soll zu Erkenntnissen führen, in welcher Weise bestimmte interne und externe Sachverhalte (= Ereignisse) die Geschäftsprozesse beeinflussen. • BAM betrachtet Informationen auf verschiedenen Abstraktionsebenen; die entsprechenden Daten können sowohl technischer als auch fachlicher Natur sein, beispielsweise Netzwerkfehler, Serverauslastung, Auftragseingänge oder Fehlbuchungen. • BAM unterstützt die Entscheidungsfindung in Echtzeit. • BAM zeigt Verletzungen von Geschäftsregeln (business policies) automatisch und unmittelbar an. • BAM bietet aussagekräftige Statistiken für die relevanten Geschäftskennzahlen. Das traditionelle Business Intelligence zielt auf die Informationsanforderungen von Geschäftsanalysten oder Führungskräften ab, und zwar mit dem Fokus auf strategische unternehmerische Entscheidungen. Im Gegensatz dazu adressiert BAM die Informationsanforderungen für die operativen Entscheidungen in der Steuerung der laufenden Geschäftsprozesse, bei denen Prozessverantwortliche innerhalb kurzer Zeit taktische Entscheidungen mit unmittelbaren Auswirkungen auf den weiteren Prozessverlauf treffen müssen [18]. Aufgrund der besonderen Eignung von EDA für BAM-Anwendungen existieren bereits einige ereignisgesteuerte Ansätze für BAM, u.a. im Bankenumfeld [45] oder bei der Überwachung von Sprachapplikationen in Sprachportalen [74]. Sonstige Monitoring-Anwendungen Weitere Kontroll- und Überwachungsanwendungen, die als geeignete Anwendungsbereiche für EDA identifiziert wurden, sind z.B. die Überwachung der Einhaltung von Service Level Agreements (SLAs) [30], die Überwachung von Rechnernetzen [63, 75], die Kontrolle des Luftverkehrs (air traffic management) [106] sowie die Überwachung und Steuerung von Energienetzen.

2.5.2 Sensornetzwerke Sensoren bzw. Netzwerke von Sensoren erfassen Messdaten (= Ereignisse) aus der physikalischen Welt und stellen diese Daten Unternehmensanwendungen zur Auswertung zur Verfügung. Beispiele für Sensoren sind RFID-Technologie, BarcodeLeser, GPS-Geräte, Temperatur- oder Feuchtigkeitsmessgeräte, Bewegungsmelder oder biometrische Sensoren. Sensoren dienen als technisches Bindeglied, um die Informationsverarbeitung mit der physikalischen Welt zu verbinden. Die Bezeichnung “Netz der Dinge“ (net of things) drückt aus, dass in Zukunft nicht nur Rechner, sondern auch simple Dinge aus der realen Welt, wie beispielsweise Waren oder Fahrzeuge, technisch vernetzt werden können.

42


Fallende Kosten und die wachsenden technischen Fähigkeiten der Sensoren eröffnen immer neue Einsatzgebiete, so dass die Verbreitung von Sensornetzwerken stetig zunimmt. Sensoren kommen inzwischen in vielfältigen Anwendungsbereichen zum Einsatz, z.B. bei der Verwaltung von Waren in Kauf- oder Lagerhäusern, bei der Überwachung von Umweltbedingungen wie Temperaturtrends, Gletscherentwicklungen, Meeresströmungen oder Schadstoffemissionen, bei der Lokalisierung von Fertigungsteilen in einer Zulieferkette (supply chain), bei der Patientenüberwachung in der Medizin oder in Systemen zur Gebäudeüberwachung [37]. Moderne Automobile sind heutzutage mit einer Vielzahl von ganz unterschiedlichen Sensoren ausgestattet. Die Kontrolle von Verkehrsströmen mittels Sensortechnik dient als Fallstudie in den nachfolgenden Kapiteln dieses Buches und wird in Abschnitt 3.4 ausführlich vorgestellt. Eine charakteristische Eigenschaft von Sensornetzwerken ist die Erzeugung riesiger Datenmengen, die in kurzen Taktzyklen durch die Sensoren kontinuierlich generiert werden. Die Daten sind normalerweise sehr feingranular, enthalten nur wenige Informationen (z.B. Sensor-ID, Zeitpunkt, Messwert) und stehen demnach lediglich auf einer sehr niedrigen Abstraktionsebene zur Verfügung. Typische Anwendungen beruhen auf einer großen Anzahl von Sensoren, die teilweise im Millisekundentakt Daten liefern, um den Überwachungsbereich abzudecken. Jeder Sensor überwacht hierbei seine lokale Umgebung in einem relativ kleinen Bereich. Andere Charakteristiken von Sensornetzwerken differieren sehr stark entsprechend dem jeweiligen Anwendungsbereich, insbesondere die Netzwerktopologie (statisch oder dynamisch) und -infrastruktur. Unternehmensanwendungen stehen nun vor der Herausforderung, in dem kontinuierlichen Strom von feingranularen Daten (= Ereignisstrom) Beziehungen und Muster zwischen den Daten zu erkennen, hieraus höherwertige bzw. betrieblich aussagekräftige Ereignisse zu generieren und bei Bedarf geeignete Aktionen einzuleiten. Die Ereignisverarbeitung agiert in diesem Kontext als eine Art “Middleware“ zwischen der physikalischen Welt und der IT-Infrastruktur, wie in Abbildung 2.11 dargestellt. Muster über Ereignisströme Sensor 1 Complex Event Processing Sensor 2

ITInfrastruktur

Umwelt EDA Sensor 3

Abb. 2.11 Korrelation und Aufbereitung von Daten in Sensornetzen


43

RFID-Anwendungen Einen besonders großen Verbreitungsgrad haben Sensornetzwerke auf Basis von RFID-Technologie (Radio Frequency Identification) erlangt. Die RFID-Technologie kommt in vielen Anwendungsgebieten als berührungslose Technologie zur Identifikation von Objekten zum Einsatz. Um ein Objekt zu identifizieren, wird ein RFIDTag bzw. -Transponder an dem Objekt angebracht. Sobald sich das Objekt in der Reichweite eines RFID-Lesegeräts befindet, wird das Tag und damit das Objekt erfasst und identifiziert. Jedes von einem Lesegerät empfangene Signal stellt hierbei ein Ereignis dar, dessen Relevanz für den betroffenen Geschäftsprozess analysiert werden muss. Einfache RFID-Infrastrukturen zur Nachverfolgung von Gegenständen erzeugen Ereignisse, durch die es möglich wird, beispielsweise den Schwund durch Diebstahl zu reduzieren, falsch weitergeleitete Gepäckstücke zu lokalisieren oder Waren in Warenhäusern zu finden. Weiteres Nutzenpotenzial ergibt sich dadurch, dass die einfachen RFID-Ereignisse und höherwertige Geschäftsereignisse in Beziehung gesetzt werden. Beispielsweise kann in der Lagerhaltung ein WareneinlagerungsEreignis zu den beim Einlagerungsvorgang ausgelösten RFID-Ereignissen in Beziehung gesetzt werden, um die Einlagerung zu verifizieren, den Lagerort abzuleiten und den Status der Ware auf “eingelagert“ zu setzen. RFID für Laborlogistik Ein relativ neues Anwendungsszenario für RFID-Technologie ist z.B. die Ortung von Laborproben mit RFID [25]. In größeren Unternehmen werden Laborproben in mehrere Teilproben aufgeteilt und in verschiedenen Abteilungen untersucht. Im Rahmen der Analytik müssen verschiedene Labormitarbeiter immer wieder auf einzelne Proben Zugriff haben, wobei sie jedoch, trotz guter arbeitsorganisatorischer Ansätze, häufig viel Zeit mit dem Auffinden der gesuchten Probe verbringen. Neben der Lokalisierung ist auch die verwechselungsfreie Zuordnung einer Probe zu ihren Daten entscheidend, damit die Untersuchungsergebnisse auch den richtigen Probendaten im Labormanagementsystem zugeordnet werden. Zur Lösung dieser Probleme lässt sich die RFID-Technik einsetzen. Dafür werden alle Probenbehälter und/oder Transportkisten mit RFID-Transpondern versehen. An bestimmten Orten wie Türen oder bestimmten Arbeits- bzw. Untersuchungsbereichen werden die Sende- und Empfangsgeräte aufgestellt, um die Aufenthaltsorte und Identitäten der Proben festzustellen, graphisch zu visualisieren und die Daten aufbereitet einem Labormanagementsystem zur Verfügung zu stellen. Abbildung 2.12 zeigt beispielhaft die Position von Lesegeräten in den Untersuchungsräumen in einem Labor. Sonstige RFID-Anwendungen Weitere typische Anwendungsbereiche für RFID-Technologie sind die Identifikation und Lokalisierung von Containern in der Logistik, von Fertigungsteilen entlang

44


Raum 7 2. Obergeschoss

L7 Raum 5

L8

L5 L4 Raum 6

L6 RFID-Lesegerät

Abb. 2.12 Raumplan mit RFID-Lesegeräten an Türen und Arbeitsbereichen

der Zulieferkette oder von Waren in der Lagerverwaltung sowie die Bestandsverwaltung, Abrechnung und Diebstahlsicherung von Waren in Kaufhäusern. Diese Einsatzgebiete werden als “Track-and-Trace“-Anwendungen bezeichnet und sind aufgrund ihrer Eigenschaften prädestiniert für den Einsatz von EDA [18]. Der Abschnitt 6.4 greift Tracking-and-Tracing-Anwendungen beispielhaft bei der Behandlung von Ereignissen auf.

2.5.3 Analytik Auftragseingänge, Aktienpreise, Kundendaten, Prüfungsergebnisse, Stornierungen und vieles mehr: Jede Organisation sieht sich einer stetig anwachsenden Menge von (Ereignis-)Daten ausgesetzt, die die Geschäftstätigkeit und -prozesse beeinflussen (siehe auch ereignisorientierte Prozesse in Abschnitt 2.1). In [21] wird dieser Datenfluss als “Live“-Daten bezeichnet. Diese Daten können als Einzelereignisse angesehen werden, die zeitnah und kontinuierlich auf das Vorhandensein von signifikanten Mustern von Beziehungen und Zusammenhängen hin analysiert werden müssen, um rechtzeitig Entwicklungen zu erkennen und, wenn notwendig, darauf zeitnah reagieren zu können.


45

Wertpapierhandel Als klassisches Beispiel für analytische Anwendungen auf Basis von EDA gilt der Wertpapierhandel (algorithmic/financial trading) [31, 63, 69]. Die Kauf- oder Verkaufsentscheidungen für ein bestimmtes Wertpapier hängen von diversen Faktoren ab, u.a. von der Entwicklung der Kurse am Aktien-, Devisenmarkt und weiteren Märkten. Jede einzelne Kursänderung kann als Ereignis angesehen werden. Aus der isolierten Analyse eines einzelnen Ereignisses, wie z.B. dem Steigen oder Fallen einer bestimmten Aktie, lassen sich keine aussagekräftigen Erkenntnisse gewinnen. Erst das Erkennen des Auftretens von signifikanten Mustern im kontinuierlichen Strom der Ereignisse, d.h. die Analyse von Abhängigkeiten und Beziehungen zwischen Ereignissen, führt zu einer gewissen Transparenz und zu einem Verständnis der Marktsituation und -entwicklung und ermöglicht das Ableiten von Kauf- bzw. Verkaufsentscheidungen. Sonstige Analytik-Anwendungen Weitere aussichtsreiche Anwendungsgebiete für eine ereignisorientierte Analytik sind z.B. Analyse des Kundenverhaltens im Internet (click stream analysis) oder im Telekommunikationsbereich [21], Intrusion Detection [63], Betrugserkennung (fraud detection, anti-money laundering [69, 106]), automatische Behandlung von Ausnahmefällen [38] oder weitere Handelssysteme wie beispielsweise für den Handel an Energiemärkten.

2.5.4 Enterprise Application Integration Die Abläufe in Geschäftsprozessen sind typischerweise abteilungs-, standort- und häufig auch unternehmensübergreifend. Folglich lassen sich diese Prozesse nicht in einem einzelnen Anwendungssystem realisieren, sondern erfordern das Zusammenspiel von mehreren, häufig heterogenen Systemen entlang der Prozesskette. Enterprise Application Integration (EAI) stellt einen Ansatz zur technischen Integration von heterogenen Anwendungssystemen dar, seien es individuell entwickelte Informationssysteme, Standard-ERP-Systeme oder Legacy-Systeme [19]. Mit EAI lassen sich verteilte Daten gemeinsam benutzen bzw. austauschen und Geschäftsprozesse ganzheitlich unterstützen. EAI bietet eine technische Infrastruktur für die strukturierte Integration von Anwendungssystemen und führt zu einer Vereinfachung und Komplexitätsreduzierung der Anwendungsintegration (siehe Abbildung 2.13). Da die zu integrierenden Anwendungssysteme in der Regel unabhängig entwickelt, administriert und weiterentwickelt werden, muss die Integrationsarchitektur eine maximale Entkopplung anstreben, um Flexibilität und Skalierbarkeit zu gewährleisten [51]. Physische Kopplung existierender Anwendungssysteme über etablierte Schnittstellentechnologie und asynchroner Austausch von Nachrichten über

46

2 Ereignisse in Unternehmensanwendungen Historisch gewachsene Anwendungsintegration

Anwendungsintegration mit Enterprise Application Integration

Abb. 2.13 Integration von Unternehmensanwendungen ohne und mit EAI

eine nachrichtenorientierte Middleware bilden die Grundlage der meisten EAIAnsätze. Ereignisorientierung als Architekturstil adressiert direkt die EAI-Ziele und bietet sich folglich als Integrationsinfrastruktur an [75], die den Austausch von Ereignissen als grundlegenden Integrationsmechanismus in den Fokus rückt. Um Ereignisse zwischen heterogenen Umgebungen austauschen zu können und damit die Interoperabilität der Anwendungen zu gewährleisten, müssen die ausgetauschten Ereignisse häufig für die Integration von einer Anwendung mit einer anderen zunächst transformiert, inhaltlich angereichert und/oder kombiniert werden [30]. Die Überführung eines Ereignisses in ein anderes Format (event translation), die Anreicherung des Ereignisinhalts durch externe Kontextinformationen (content enrichment) und das Aggregieren von mehreren Ereignissen zu einem komplexeren Ereignis (event composition) erfordern eine komplexe Verarbeitung der Ereignisse, wie sie beispielsweise durch Complex Event Processing bereitgestellt wird.

Kapitel 3

Event-Driven Architecture und Complex Event Processing im Überblick

Zusammenfassung Dieses Kapitel stellt die Grundidee und Kernkonzepte von Event-Driven Architecture und Complex Event Processing vor. Zunächst steht EDA als Architekturstil im Fokus. Die Schlüsselbegriffe, Entwurfsprinzipien und charakteristischen Eigenschaften einer ereignisgesteuerten Architektur werden eingeführt, die herausgehobene Bedeutung von CEP für EDA beleuchtet und die Architektur und die Architekturschichten einer EDA erklärt. Der zweite Abschnitt geht auf Complex Event Processing als die zentrale Softwaretechnologie für die Umsetzung einer EDA ein und stellt die wesentlichen Konzepte und Elemente von CEP überblicksartig vor. Anschließend erfolgt eine Bewertung von EDA als innovativem Stil für dynamische und reaktionsfähige Unternehmensarchitekturen. Zum Schluss erfolgt die Vorstellung einer Fallstudie, anhand derer in den nachfolgenden Kapiteln die Konzepte praktisch veranschaulicht werden. Als Anwendungsdomäne für die Fallstudie dient der Bereich der Verkehrskontrolle und -steuerung.

3.1 EDA – Grundkonzepte Event-Driven Architecture (EDA) ist ein innovativer Architekturstil für die Gestaltung von verteilten Unternehmensarchitekturen (enterprise architectures) mit dem Ziel, den Anwendungssystemen in Unternehmen zu mehr Agilität und Effizienz zu verhelfen. Dieser Abschnitt führt die Grundidee, die Fachterminologie, die wesentlichen Konzepte sowie die charakteristischen Eigenschaften von ereignisgesteuerten Softwarearchitekturen ein (Abschnitt 3.1.1), beschreibt die besondere Bedeutung von Complex Event Processing für eine EDA (Abschnitt 3.1.2) und stellt die Architektur und die Architekturelemente einer EDA vor (Abschnitt 3.1.3).


47

48

3 Event-Driven Architecture und Complex Event Processing im Überblick

3.1.1 Ereignisse – Ereignisgesteuert – EDA Eine Event-Driven Architecture rückt Ereignisse in den Fokus der Softwarearchitektur. Fachliche Geschäftsereignisse bilden das zentrale Architekturkonzept in allen Schritten der Entwicklung eines ereignisgesteuerten Softwaresystems.1 Grundidee und -begriffe Ereignis (event) Ein Ereignis kann alles sein (eine Aktivität, ein Vorgang, eine Entscheidung etc.), was passiert oder von dem erwartet wird, dass es passiert [68]. Im Allgemeinen bezieht sich ein Ereignis auf die Veränderung eines Zustands, also typischerweise auf die Änderung des Wertes einer Eigenschaft eines realen oder virtuellen Objekts. Ereignisse können Vorkommnisse auf unterschiedlichen Abstraktionsebenen repräsentieren:2 • Technische Ereignisse mit einem niedrigen Abstraktionsgrad, wie z.B. die Veränderung der gemessenen Temperatur an einem Sensor einer Fertigungsmaschine oder der festgestellte CO2 -Gehalt der Luft an einer Straßenkreuzung zu einem definierten Messzeitpunkt. • Systemereignisse aus der IT-Infrastruktur mit einem ebenfalls niedrigen Abstraktionsgrad, wie beispielsweise der Eingang eines HTTP-Requests an einem WebServer, die Änderung des Zustands eines endlichen Automaten oder die Benachrichtigung über die Änderung einer Konfigurationseinstellung einer Systemsoftware. • Geschäftsereignisse, die einen fachlichen Sachverhalt widerspiegeln und einen unmittelbaren Einfluss auf die geschäftlichen Abläufe erwarten lassen, wie z.B. die Kündigung eines Liefervertrags durch einen Kunden, das Entladen eines Containers nach seiner Verschiffung im Zielhafen, ein Verkehrsstau im Straßenverkehr oder die Unterschreitung eines vorgegebenen Schwellenwerts für den Lagerbestand einer Ware. Wichtig ist die Erkenntnis, dass abhängig vom jeweiligen fachlichen Kontext so gut wie jedes Vorkommnis ein Ereignis darstellen oder auslösen kann [106]. Da Ereignisse aufgrund ihrer fachlichen Relevanz für eine Anwendungsdomäne betrachtet werden, ist es essenziell, die Ereignisse in der Terminologie der Fachdomäne zu beschreiben und keine informationstechnische Terminologie zu verwenden.

1

Die Event Processing Technical Society (http://www.ep-ts.com) hat ein “Event Processing Glossary“ [68] erstellt, um eine gemeinsame Fachterminologie im Bereich der Ereignisverarbeitung zu etablieren. Wo immer passend, lehnen sich die in diesem Buch vorgenommenen deutschen Begriffsbeschreibungen an das englische Glossar an. 2 Siehe auch Abschnitt 2.1.3.

3.1 EDA – Grundkonzepte

49

Analog zu der Abfolge der Aktivitäten in einem Geschäftsprozess in der fachlichen Realität sollen auch die zentralen Abläufe in der Anwendungsarchitektur durch den Fluss der Ereignisse (bzw. Ereignisobjekte3) gesteuert werden. Ereignisgesteuert (event-driven) Als ereignisgesteuert wird das Verhalten eines Systems, Geräts, Softwaremoduls oder anderer Entitäten bezeichnet, dessen Verarbeitungsprozess durch das Eintreffen eines Ereignisses von einer internen oder externen Quelle ausgelöst wird [68]. Beispiele für ereignisgesteuerte Systeme finden sich zuhauf in unserer natürlichen, betrieblichen und technischen Umwelt, u.a. Mobiltelefone, Kundenservice in einem Call-Center, eine durch ein Ereignis ausgelöste Regel in einem regelbasierten System, Trigger in Datenbankmanagementsystemen, ein Betriebssystem. Aber auch das automatische Einschalten eines Scheibenwischers in einem Auto, wenn der Regensensor auf der Windschutzscheibe durch Wassertropfen ausgelöst wird, ist ein ereignisgesteuertes Verhalten [106]. Demnach besteht eine zentrale Charakteristik von ereignisgesteuerten Systemen aus der Komposition von drei Grundschritten: (1) Erkennen, (2) Verarbeiten und (3) Reagieren von bzw. auf Ereignisse (sense & respond behaviour) [16, 17, 99]. In Abbildung 3.1 ist der sich ergebende charakteristische Zyklus ereignisgesteuerter Systeme dargestellt.

Reaktion auf erkannte Muster; Aufruf von verteilten Services in Echtzeit

Reagieren

Erkennen EDA

Entdecken von Ereignissen in Umgebungen in Echtzeit

Verarbeiten Aggregieren von Ereignissen über unterschiedliche Quellen; Suchen nach Ereignismustern

Abb. 3.1 Grundzyklus ereignisgesteuerter Systeme

1. Erkennen (sense) Ausgangspunkt ist das Erkennen von relevanten Informationen oder Sachverhalten aus dem Unternehmen selbst oder von außerhalb des Unternehmens, z.B. 3

Aus Gründen der Vereinfachung differenzieren wir in diesem Kapitel nicht explizit zwischen Ereignissen und Ereignisobjekten, sondern sprechen allgemein von Ereignissen. Für die ausführliche Beschreibung und Differenzierung der Begriffe sei auf Kapitel 4 verwiesen.

50


durch Sensoren oder aber auch durch ganz anders geartete Quellen. Diese Informationen werden als Ereignisse interpretiert und spiegeln einen relevanten Ausschnitt des Zustands der Geschäftstätigkeit bzw. der “Realität“ wider. Für erkannte Ereignisse wird ein entsprechendes Ereignisobjekt im System generiert. Entscheidend für ereignisgesteuerte Systeme ist, dass die Ereignisse unmittelbar zum Zeitpunkt ihres Auftretens erkannt werden und nicht zeitverzögert. 2. Verarbeiten (process bzw. analyze) Im Verarbeitungsschritt erfolgt die Analyse der erkannten Ereignisse, die aus unterschiedlichen Quellen stammen können. Bei der Analyse werden Ereignisse aggregiert, korreliert, abstrahiert, klassifiziert oder aber auch verworfen. Gesucht werden Muster in und zwischen den Ereignisströmen, die bestimmte Beziehungen und Abhängigkeiten zwischen den Ereignissen ausdrücken. 3. Reagieren (respond) Aufgrund von analysierten Mustern, die im Fluss der eingetretenen Ereignisse erkannt wurden, können vielfältige Arten von Reaktionen zeitnah veranlasst werden. Typische Reaktionen sind beispielsweise das Schicken von Warnmeldungen, der Aufruf von fachlichen Anwendungsfunktionen in Form von verteilten Services, das Auslösen eines Geschäftsprozesses oder die Initiierung von Aktionen durch menschliche Benutzer. Aber auch die Generierung neuer Ereignisse ist eine mögliche Reaktion, z.B. von komplexen Ereignissen auf einer höheren Abstraktionsebene. Die Umsetzung der Ereignissteuerung in Unternehmensanwendungen muss bereits in den Prinzipien und Strukturen der zugrunde liegenden Softwarearchitektur verankert sein. Ein ereignisgesteuertes System kommt ohne zentrale Steuerung aus, stattdessen ist die Architektur so entworfen, dass das System bzw. die Systemkomponenten auf eintretende Ereignisse reagieren. Die Architektur von Software ist die grundlegende Organisation eines Systems, bestehend aus ihren Komponenten und Teilsystemen, deren Beziehungen und Interaktionen untereinander und zu ihrer Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems leiten ([91] entsprechend dem IEEE-Standard 1471-2000). Event-Driven Architecture (EDA) Event-Driven Architecture ist ein Architekturstil, in dem einige Komponenten ereignisgesteuert sind und die Interaktion durch den Austausch von Ereignissen erfolgt [68]. Die Verarbeitung von Ereignissen bildet das zentrale Konzept bei der Modellierung, dem Entwurf und der Interaktion einer Unternehmensarchitektur. Natürlich wäre es möglich, nur Systeme als EDA zu bezeichnen, bei denen sämtliche Komponenten ereignisgesteuert sind und die Kommunikation ausschließlich über den Austausch von Ereignissen erfolgt. Die Diskussionen in den Abschnitten 2.4 und 2.5 zeigen aber, dass EDA und konventionelle oder Service-orientierte Architekturen nicht substituierend, sondern komplementär zu betrachten sind. Deswegen erscheint in der betrieblichen Praxis eine ausschließlich ereignisgesteuerte


51

Architektur wenig sinnvoll, höchstens in abgegrenzten Spezialeinsatzgebieten kann ein rein ereignisgesteuertes System die beste Wahl sein. Eigenschaften einer EDA Nicht jedes Softwaresystem, das Ereignisse behandelt, erfüllt automatisch die Kriterien für eine Event-Driven Architecture. Ereignisse können in starr vorgegebenen Abläufen vorkommen oder als Antwort auf einen Service-Aufruf zurückgegeben werden. Weiterhin können Ereignisse in Repositories für eine retrospektive Auswertung gespeichert werden oder in (entfernten) Methodenaufrufen (remote procedure calls, RPC) verpackt sein. Diese Art des Umgangs mit Ereignissen ist nicht ereignisgesteuert. Ereignisgesteuerte Softwarearchitekturen, und damit insbesondere EDA, besitzen Schlüsseleigenschaften, die aus dem 1. Verarbeitungsmodell und 2. Kommunikationsmuster einer EDA resultieren (subsumiert u.a. aus [17, 99, 106]). 1. Verarbeitungsmodell von EDA Ereignisgesteuerten Systemen liegt ein spezielles Verarbeitungsmodell zugrunde, und zwar mit den folgenden Elementen und Eigenschaften: • Ereignisquelle (event source) Die Komponente, die relevante Informationen erkennt und entsprechende Ereignisse (bzw. Ereignisobjekte) erzeugt, wird als Ereignisquelle (oder Produzent) bezeichnet. Eine Ereignisquelle sendet eine Nachricht (message) mit den Daten über das Auftreten eines Ereignisses an einen Mediator. Die Ereignisquelle leitet hierbei das Ereignis als Nachricht an den Mediator weiter, ohne zu wissen, wo und wie das Ereignis weiterverarbeitet wird. Allein der Mediator ist verantwortlich für die richtige Verteilung der Nachrichten und verfügt über das entsprechende Wissen. Auch die Verfügbarkeit oder überhaupt die Existenz einer weiterverarbeitenden Komponente ist der Quelle nicht bekannt. Die Ereignisquelle bestimmt den Zeitpunkt des Sendens. Durch das aktive Senden eines Ereignisses unmittelbar zu dem Zeitpunkt, an dem es erkannt wird, reduziert sich die Zeit, um auf ein Ereignis zu reagieren.4 Als Konsequenz besitzen EDAs eine äußerst hohe Aktualität. • Ereignissenke (event sink) Die Softwarekomponente, die ein Ereignis empfängt, wird als Ereignissenke (oder Konsument) bezeichnet. Eine Ereignissenke (event sink, event consumer) ist eine beliebige Entität, die Ereignisse empfangen kann [68]. Eine Ereignissenke reagiert, sobald sie ein Ereignis empfangen hat. Ein gestufter Geschäftspro4

Im Gegensatz zur zeitgesteuerten Nachfrage (polling) einer an einem Ereignis interessierten Komponente, ob ein Ereignis eingetreten ist.

52


zess über verteilte Anwendungskomponenten lässt sich so in kurzer Zeit abarbeiten, indem die relevanten Ereignisse unmittelbar von Stufe zu Stufe weitergeleitet werden und dort jeweils sofort mit dem Eintreffen einen Verarbeitungsvorgang auslösen. • Ereignisobjekt (event object) Ein Ereignis bzw. Ereignisobjekt enthält keinerlei Wissen oder Annahmen über die Operationen oder Verarbeitungsschritte, die ein Konsument ausführen wird, sobald er das Ereignis empfängt. Die Ereignisquelle sendet lediglich eine Nachricht, dass ein Ereignis eingetreten ist.

Senke & Quelle Ereignissenke

Mediator

Ereignisquelle

Mediator

Die Fachlogik zu entscheiden, wie aufgrund des Ereignisses zu reagieren ist, kennt ausschließlich der Konsument (bzw. die Konsumenten). Hierdurch reduziert sich die Abhängigkeit zwischen Quelle und Senke auf ein Mindestmaß, nämlich auf die Abstimmung der syntaktischen Struktur und der Semantik der ausgetauschten Ereignisnachrichten.

Ereignissenke

Abb. 3.2 Gestuftes Verarbeitungsmodell mit Ereignisquellen, -senken und Mediatoren

Abbildung 3.2 veranschaulicht das einer EDA zugrunde liegende Verarbeitungsmodell. Die konsequente Verwendung von Ereignissen als Mittel der Interaktion und das hiermit einhergehende Verarbeitungsmodell von EDA führen zu einer extrem losen Kopplung bzw. zu einer Entkopplung der miteinander interagierenden Komponenten. Der Begriff Kopplung bezeichnet das Maß der Abhängigkeit zwischen zwei kommunizierenden Teilsystemen. Je mehr Annahmen die Teilsysteme übereinander benötigen, umso enger sind sie gekoppelt. Lose gekoppelte Teilsysteme sind von Änderungen in anderen Systemteilen nur in geringem Maße betroffen und somit robust. Deshalb sollte die Abhängigkeit zwischen Teilsystemen möglichst minimal sein [29].5 Durch den geringen Grad der Kopplung in einer EDA ist es möglich, Ereigniskonsumenten zu ändern oder weitere Konsumenten hinzuzufügen, ohne dass die Ereignisquellen hiervon tangiert werden. Die sich hieraus ergebende einfache Einbindung neuer Anwendungskomponenten (in [17] als plug-ability bezeichnet) ist ein wesentlicher Vorteil gegenüber herkömmlichen Systemen.

5

Für eine weiterführende Betrachtung der Kopplung von Komponenten sei auf die ausführliche Diskussion dieses Themas in [32] verwiesen.


53

2. Kommunikationsmuster von EDA Der Kommunikation von Systemkomponenten durch den Austausch von Ereignissen in einem ereignisgesteuerten System liegt ein spezielles Kommunikationsmuster zugrunde, und zwar mit den drei Eigenschaften: (a) Asynchronität, (b) Publish/Subscribe-Interaktion und (c) Push-Modus: • Asynchronität Zwei unterschiedliche Arten existieren für die Interaktion zwischen Komponenten in einem verteilten System: synchron und asynchron. 1. Synchrone Interaktion Synchrone Interaktion verhält sich ähnlich wie ein Prozeduraufruf (procedure call). Die aufrufende Komponente initiiert den Kommunikationsvorgang mit einer anderen Komponente, beispielsweise durch den Aufruf einer Methode oder durch das Senden einer Nachricht, und wartet auf einen Rückgabewert, bevor sie mit der Ausführung an der Stelle fortfährt, an der sie unterbrochen wurde. Um den Kommunikationsvorgang abzuschließen, muss die aufgerufene Komponente verfügbar sein und jegliche weitere Verarbeitung muss warten, bis der Transfer der Antwortdaten abgeschlossen ist. Die aufrufende Komponente ist somit bis zum Erhalt der Antwort blockiert. Request/Reply-Interaktionen, wie die in Abbildung 2.7 dargestellte Anfrage/AntwortInteraktion, sind typisch für eine synchrone Interaktion. 2. Asynchrone Interaktion Im Gegensatz zur synchronen Interaktion wartet bei einer asynchronen Interaktion die aufrufende Komponente nicht auf die Antwort, sondern fährt unvermittelt mit den weiteren Verarbeitungsschritten fort. Bei dieser Art der Kommunikation ist es auch nicht notwendig, dass die aufgerufene Komponente zum Zeitpunkt des Kommunikationsvorgangs verfügbar ist. Bei einer asynchronen Kommunikation werden die Nachrichten an einen Mediator gesendet, der die Nachrichten speichert, bis diese an den Empfänger zugestellt werden können. Beispiele sind die E-Mail-Kommunikation oder das Hinterlassen einer Nachricht auf einer Mailbox beim Telefonieren. Publish/Subscribe-Interaktionen (siehe Abbildung 3.3) sind typisch für eine asynchrone Interaktion. Ereignisgesteuerten Systemen liegt eine asynchrone Art der Kommunikation zugrunde [106]. Der Austausch von Ereignisobjekten zwischen Ereignisquellen und -senken erfolgt mittels asynchroner Nachrichten (asynchronous messages), und die Ereignisquelle wartet nicht auf die Bearbeitung des Ereignisses durch den oder die Empfänger. • Publish/Subscribe-Interaktion Der Austausch von Nachrichten in einem ereignisgesteuerten System wird typischerweise im Publish/Subscribe-Modus realisiert, dargestellt in Abbildung 3.3. Ein Sender (= publisher, Produzent) schickt seine Daten in Form von Nachrichten an eine Middleware, um diese interessierten Parteien zur Verfügung zu stellen

54


bzw. zu publizieren. Die publizierten Nachrichten sind Instanzen eines spezifischen Nachrichtentyps (bzw. einer Nachrichtenklasse).

Sendende Komponente

Senden

Middleware

Empfangende Komponente A

Abonnieren

Empfangende Komponente B

Empfangende Komponente C

Benachrichtigen

Abb. 3.3 Publish/Subscribe-Interaktion

Ein oder mehrere Empfänger (= subscriber, Konsumenten) artikulieren ihr Interesse an einem oder mehreren Nachrichtentypen, indem sie sich bei der Middleware für diesen Typ bzw. diese Typen registrieren – sie abonnieren (subscribe) sozusagen die Zustellung aller Nachrichten der registrierten Typen. Beim Abonnieren ist es natürlich möglich, dass mehrere Empfänger an demselben Nachrichtentyp interessiert sind, so dass sich sowohl eine 1:1- als auch eine 1:nKommunikation realisieren lässt. Beim Eintreffen einer neuen Nachricht benachrichtigt die Middleware alle an dem Typ der Nachricht interessierten Parteien über deren Eintreffen. Jeder Empfänger kann die neue Nachricht, und damit das Ereignis, zu einem von ihm bestimmten Zeitpunkt abholen. Das Publish/Subscribe-Kommunikationsmuster führt zu einem nebenläufigen Verarbeitungsmodell. Aus der nebenläufigen Verarbeitung folgt aber gleichzeitig der Verlust einer deterministischen Reihenfolge der Verarbeitungsschritte. • Push-Modus In einem ereignisgesteuerten System geht die Initiative zum Nachrichtenaustausch immer von der Ereignisquelle aus [17]. Die Quelle bestimmt den Zeitpunkt der Interaktion. Diese Form der Kommunikation wird auch als PushModus6 bezeichnet [118]. Die Kommunikation auf der Basis des Publish/Subscribe-Modells im PushModus unterstützt die Entkopplung der beteiligten Komponenten. Asynchronität und Entkopplung sind die konzeptionellen Grundlagen für die Interoperabilität und Skalierbarkeit von EDA und damit für den Einsatz von EDA als Integrationsinfrastruktur (siehe Abschnitt 2.5.4).

6 Im Gegensatz dazu die Pull-Variante, bei der die Ereignissenke, also der Konsument, aktiv die Nachrichten von der Ereignisquelle einfordert [118].


55

Kommunikationsstruktur und Kerneigenschaften Das Zusammenspiel von Verarbeitungsmodell und Kommunikationsmuster ereignisgesteuerter Systeme visualisiert die Abbildung 3.4 exemplarisch. Komponente k1 erkennt Ereignisse vom Typ TA und sendet (“push“) diese ohne Zeitverzug in Form einer Nachricht an einen Mediator, der die Nachrichten verwaltet, z.B. in einer Warteschlange (queue), und zur Abholung bereitstellt. Nachdem die Komponente k1 eine Ereignisnachricht gesendet hat, fährt sie ohne zu warten, also asynchron, mit den weiteren Verarbeitungsschritten fort. Der Mediator benachrichtigt jede Komponente, die sich für Ereignisse dieses speziellen Typs registriert hat, über den Eingang eines neuen Ereignisses dieses Typs. Die betreffende Komponente kann sich dann zu einem von ihr bestimmten Zeitpunkt das Ereignis zur weiteren Verarbeitung abholen. Im Beispiel hat sich die Komponente k2 für Ereignisse des Typs TA registriert und holt sich das entsprechende Ereignis aus dem Mediator ab.

Mediator Typ TA

Komponente k1

Typ TB

Komponente k2

Softwarekomponente

Komponente kn

Warteschlange

Ereignistyp TA Senden

...

Ereignistyp TB Abholen

Benachrichtigen/ Registrieren

Abb. 3.4 Kommunikationsstruktur ereignisgesteuerter Systeme (nach [28])

Das Konzept des Austausches von Ereignissen über Nachrichten ist bereits im Bereich der Integration von Unternehmensanwendungen (Enterprise Application Integration, EAI [19, 40]) etabliert. Es bietet sich an, auch eine EDA durch eine nachrichtenorientierte Middleware (Message-oriented Middleware, MOM) zu implementieren. Jedoch ist nicht automatisch jeder Einsatz eines MOM-Produktes gleichbedeutend mit der Realisierung einer EDA. Das Konzept der Ereignisorientierung muss bereits Teil der Modellierung und des Entwurfs der Softwarelösung sein, um als EDA zu gelten – einfaches Nutzen von Nachrichten über Warteschlangen erfüllt nicht zwangsläufig die Kriterien der Ereignissteuerung. Gleichermaßen impliziert die Nutzung einer Publish/Subscribe-Interaktion nicht zwangsläufig eine EDA, obwohl viele EDA-Anwendungen dieses Kommunikationsmuster verwenden [76].

56


Die Tabelle 3.1 stellt die aus dem speziellen Verarbeitungsmodell und dem Kommunikationsmuster resultierenden Kerneigenschaften einer Event-Driven Architecture zusammenfassend dar. Tabelle 3.1 Charakteristische Eigenschaften von EDA (analog zu Tabelle 2.3) Eigenschaft

EDA

Entwurfsfokus

Ereignis und Ereignisnachricht (message)

Verarbeitungsmodell

Ereignisquelle sendet eine Nachricht mit den Daten über das Auftreten eines Ereignisses an eine Middleware. Ein registrierter Empfänger (Ereignissenke) bemerkt die Ankunft einer Ereignisnachricht und verarbeitet diese unmittelbar. Das Ereignis selbst enthält keine Informationen über seine weitere Verarbeitung.

Modularität

modular durch konzeptionelle Trennung von Ereignissenken und -quellen

Verteilbarkeit


Typisches Kommunikationsmuster

Publish/Subscribe mit Push-Modus, asynchron, mehrere Ereignissenken

Transaktionsbereich (LUW)

Ereignisquelle und -senke bilden zwei unabhängige LUW

Transaktionskontrolle (LUW)

Ereignisquelle und -senke kontrollieren unabhängig jeweils ihre LUWs

Beziehung zwischen Komponenten

Ereignisquellen und -senken kennen sich nicht. Ereignisquelle hat kein Wissen über Senke, nicht mal darüber, ob diese verfügbar ist oder überhaupt existiert.

Abhängigkeit zwischen Komponenten

Schema der Ereignisnachricht und Version

Grad der Kopplung

äußerst lose Kopplung oder Entkopplung von Komponenten

LUW = logical unit of work

3.1.2 EDA mit CEP Es existieren verschiedene Ausprägungen von Systemen, die die in Tabelle 3.1 zusammengefassten Eigenschaften erfüllen und somit als EDA bezeichnet werden könnten. Die Ausführungen im vorhergehenden Abschnitt 3.1.1 basieren auf der Betrachtung des Austausches einzelner Ereignisse zwischen Systemkomponenten, bei dem die Ereignisse im Wesentlichen unabhängig voneinander betrachtet werden. In [99] wird diese Form einer EDA als “one-event-at-a-time EDA“ bezeichnet. Der Verarbeiten-Schritt im Grundzyklus in Abbildung 3.1 umfasste in den bisheri-


57

gen Ausführungen lediglich Operationen auf der Basis von Einzelereignissen, wie beispielsweise deren Interpretation oder Transformation. Wie in Kapitel 2 ausführlich diskutiert, reicht jedoch die voneinander unabhängige Betrachtung einzelner Ereignisse für viele Anwendungsdomänen nicht aus. Das volle Potenzial der Ereignisverarbeitung erschließt sich erst, wenn mehrere Ereignisse mit ihren Beziehungen, Abhängigkeiten und Korrelationen über einen längeren Zeitraum betrachtet werden, um daraus Schlussfolgerungen für schnellere und bessere operative Geschäftsentscheidungen abzuleiten. Mit Complex Event Processing steht eine Technologie zur Verfügung, die die Verarbeitung komplexer Ereignisse in das Zentrum der Softwareentwicklung stellt – entwickelt von David Luckham [63]. Complex Event Processing (CEP) Complex Event Processing ist eine Softwaretechnologie für die dynamische Verarbeitung von mehreren Ereignissen zur gleichen Zeit. Mit CEP ist es möglich, kausale, temporale, räumliche und andere Beziehungen zwischen Ereignissen auszudrücken. Diese Beziehungen spezifizieren Muster, nach denen die Ereignismenge in Echtzeit durchsucht wird (event pattern matching) [63]. CEP ermöglicht es, sehr große Mengen von Ereignissen dynamisch zu verarbeiten, den fachlichen Informationswert aus diesen Ereignissen zu extrahieren und für die Steuerung des Kontrollflusses von Anwendungen zu nutzen. Eng mit CEP verwandt ist die Technologie des Event Stream Processing. Event Stream Processing (ESP) Event Stream Processing bezeichnet eine Technologie zur Verarbeitung von kontinuierlichen Ereignisströmen als Eingabe [68], die als Sequenzen von geordneten Ereignisobjekten in das System einfließen. Betrachtet wird jeweils ein Ausschnitt aus dem Fluss der Ereignisse (häufig als Fenster (window) bezeichnet), der nach dem Vorhandensein von Ereignismustern analysiert wird. Ein Beispiel für kontinuierlich einfließende Ereignisse sind Aktienmarktticker, in denen fortlaufend aktuelle Meldungen über Börsendaten, Märkte, Kurse, Transaktionen, Finanztitel, Branchen usw. aus dem Bereich des Wertpapierhandels bereitgestellt werden. Diese Meldungen stellen eine riesige Menge von Ereignissen dar, die in der Reihenfolge des Eintreffens analysiert werden, um z.B. durchschnittliche Preise ausgewählter Aktien zu berechnen oder Abweichungen von Durchschnittswerten zu erkennen. Die Begriffe CEP und ESP sind konzeptionelle Klassifikationen: CEP fokussiert stärker auf komplexe Operationen über mehreren Ereignissen, während bei ESP die kontinuierlichen Ereignisströme im Vordergrund stehen. Eine konzeptionell eindeutige Abgrenzung der beiden Begriffe existiert jedoch nicht. Bei der Implementierung von Softwareprodukten für die Verarbeitung von sehr großen Mengen von Er-

58


eignisdaten, den sogenannten Event Processing Engines, finden sich in der Regel Konzepte aus beiden Kategorien. Aus diesem Grund wird im Folgenden nicht weiter zwischen CEP und ESP differenziert, sondern unter dem Begriff CEP auch die Verarbeitung von Ereignisströmen subsumiert. Typischen Datenbank-Applikationen liegt eine statische Sicht der Datenverarbeitung zugrunde, in der die Daten persistent gespeichert und indexiert werden. Eine transiente Anfrage (query) wird gegen diese statische Datenmenge geschickt. CEP und ESP drehen dieses traditionelle Verarbeitungsmodell um. Die Daten treffen kontinuierlich und dynamisch ein, aber die Anfrage gegen die Daten, bestehend aus deklarativen Regeln, ist persistent. Ereignisdaten

Ereignisanfragen

Abb. 3.5 In-Memory-Ansatz mit Anfragen im dynamischen Strom der Datenereignisse

Mit sogenannten In-Memory-Techniken werden Anfragen in den Strom der Ereignisse gesetzt und somit die eintreffenden Datenereignisse gegen die Anfrage geschickt [18] (siehe Abbildung 3.5). Bei einem In-Memory-Ansatz befinden sich die Ereignisdaten bzw. ein aktueller Ausschnitt davon im Arbeitsspeicher und werden dort äußerst effizient analysiert. Aus den Betrachtungen folgt, dass EDA ein generelleres Konzept als CEP darstellt und CEP auch als Teil einer EDA angesehen werden kann. Die Analysten der Gartner Group bezeichnen CEP als “sophisticated form of EDA“ [99], also als eine besonders ausgereifte Form von EDA. Diese Interpretation entspricht auch der Sichtweise in diesem Buch. EDA mit CEP Complex Event Processing ist ein integraler Bestandteil und somit Kernelement einer technisch ausgereiften Event-Driven Architecture. Wenn in diesem Buch der Begriff EDA verwendet wird, ist damit implizit stets eine EDA mit CEP gemeint. Eigenschaften einer EDA mit CEP Erst durch Complex Event Processing wird eine EDA “richtig“ ereignisgesteuert und kann die vielfältigen Möglichkeiten der Ereignisverarbeitung voll entfalten. Komplexe Ereignisverarbeitung ergänzt die in Tabelle 3.1 identifizierten Eigenschaften einer EDA durch die nachfolgenden Fähigkeiten (nach [65]): 1. Echtzeitfähigkeit Ein CEP-System muss die in den Ereignissen enthaltenen Daten in (annähernd) Echtzeit (real-time) verarbeiten. Typische Operationen sind beispielsweise das


59

Identifizieren von Ereignissen mit auffälligen bzw. abweichenden Daten, das Erkennen von Ereignissen, bei denen die Daten in einer spezifizierten Beziehung zueinander stehen, oder statistische Auswertungen von Daten einer großen Menge von Ereignissen. 2. Erkennung von Ereignismustern (event pattern matching) Um Zusammenhänge zwischen Ereignissen in einer großen Ereignismenge zu erkennen, muss die Ereignismenge auf das Auftreten von spezifischen Ereignismustern hin untersucht werden. Die Suche nach Mustern betrachtet eine Ereignismenge über einen längeren Zeitraum. Je nach Mächtigkeit der Operatoren lassen sich unterschiedliche Arten der Mustererkennung differenzieren. • Erkennen einfacher Ereignismuster Die einfache Mustererkennung identifiziert Einzelereignisse oder boolesche Kombinationen von Ereignissen in einer Ereignismenge, beispielsweise Ereignisse bzw. Ereigniskombinationen, die auf eine problematische Situation hindeuten. Zum Beispiel beschreibt das einfache Muster (A and B and not(C)) das Auftreten von zwei Ereignissen A und B, jedoch bei Abwesenheit von Ereignis C. • Erkennen komplexer Ereignismuster In vielen Anwendungsdomänen reichen jedoch einfache Muster nicht aus, um die Fachlichkeit adäquat abzubilden. In solchen Fällen sind weitere Operatoren für die Spezifikation von komplexeren Mustern erforderlich. Ein komplexes Muster beinhaltet eine Vielzahl von Ereignissen und kann sich entweder – ausschließlich auf Ereignisse desselben Typs oder – auf Ereignisse heterogener Typen beziehen [18]. Einbezogen werden Zusammenhänge wie Entstehungszeit (ein Ereignis trat vor einem anderen auf), Kausalität (ein Ereignis löst ein anderes aus) und Unabhängigkeit von Ereignissen (ein Ereignis ist nicht kausal abhängig von einem anderen). Die Ereignisse können aus unterschiedlichen Quellen, aus unterschiedlichen geographischen Lokationen oder aus verschiedenen Zeitzonen entstammen. Häufig ist eine Anreicherung der Ereignisdaten mit Kontextwissen (content enrichment) erforderlich. Zum Beispiel mit topologischen Informationen (die Herkunftsorte der Ereignisse A und B sind benachbart oder die Herkunftsorte der Ereignisse A und B liegen in unterschiedlichen Zeitzonen mit einer Zeitdifferenz von +2 Stunden). Ein weiteres Beispiel ist die Einbeziehung von Kundendaten. Im Fall der Meldung eines Garantiefalls über ein WebFormular durch einen Kunden sollte das Garantiefall-Ereignis um zusätzliche Daten zu diesem Kunden aus einem CRM-System (Customer Relationship Management) angereichert werden. • Abstraktion von Ereignismustern In Abschnitt 2.1.3 wird ausgeführt, dass das Auftreten eines Beziehungsmusters, bestehend aus mehreren einfachen Ereignissen, ein komplexes Ereignis auf einer höheren Abstraktionsebene implizieren kann. Diese Abstraktion von Ereignismustern ist eine sehr wirkungsvolle Methode, um verständliche

60


Sichten auf komplexe Situationen geschäftlicher Aktivitäten zu liefern und die Anzahl der Ereignisse zu reduzieren. Typische Operationen zur Abstraktion von Ereignismustern sind zum Beispiel das Bilden von Summen oder Durchschnittswerten. Gegeben sei beispielsweise ein Ereignismuster mit mehreren RFID-Ereignissen, die die gleiche Transponder_ID = 123 besitzen, aber durch unterschiedliche RFID-Lesegeräte gelesen wurden und Zeitstempel innerhalb eines Zeitraums von 60 Sekunden aufweisen. Dieses Muster impliziert das abstrakte Ereignis “Gegenstand mit Transponder_ID = 123 bewegt sich bzw. wird bewegt“. 3. Verarbeitung von Ereignisströmen CEP-Systeme können ein extrem großes Volumen an Ereignissen verarbeiten, bis zu mehreren hunderttausend Ereignissen pro Sekunde. Die Ereignisse fließen kontinuierlich in Form von einem oder mehreren Datenströmen als Eingabe in das System. 4. Explizite Wissensrepräsentation durch Regeln In CEP ist das Wissen über die Ereignisverarbeitung explizit und deklarativ in Form von WENN-DANN-Regeln (when-then rules) repräsentiert. Eine Regel besteht aus zwei Teilen: a. einem Bedingungsteil (W ENN-Teil) und b. einem Aktionsteil (DANN-Teil). Der Bedingungsteil beschreibt eine Situation, bei deren Auftreten der Aktionsteil ausgeführt werden soll. Im Falle von CEP spezifiziert der Bedingungsteil ein Ereignismuster. Wenn im Ereignisstrom das Muster vorkommt, dann ist der Bedingungsteil erfüllt, d.h. die Regel matched, und der Aktionsteil der Regel wird ausgeführt, d.h. die Regel feuert. Eine Regel sieht demnach wie folgt aus: Ereignisregel:

W ENN ereignismuster DANN aktion

Da menschliche Fachexperten ihr Wissen oft in Form von Regeln formulieren, bilden Regeln eine adäquate Form der Repräsentation von Fachwissen. Die Verarbeitung der Regeln erfolgt zentral in der CEP-Komponente. Tabelle 3.2 stellt zusammenfassend die zusätzlichen Eigenschaften von EDA dar, die durch die komplexe Verarbeitung von Ereignissen mit Complex Event Processing hinzukommen. Die beiden Tabellen 3.1 und 3.2 beschreiben somit umfassend die Eigenschaften einer EDA, die notwendig sind, um das volle Potenzial der Ereignisverarbeitung auszuschöpfen.


61

Tabelle 3.2 Weitergehende Eigenschaften einer EDA mit CEP (analog zu Tabellen 2.1 und 2.2) Eigenschaft

EDA mit CEP

Perspektive

Echtzeitfähigkeit


einfache und komplexe Ereignismuster (event pattern matching), unter Einbeziehung von Kontextinformationen (content enrichment)

Abstraktionsgrad

Abstraktion von einfachen zu fachlich höherwertigen Ereignissen ergibt Abstraktionshierarchie

Mengengerüst

Verarbeitung von Massenereignisdaten aus mehreren Ereignisströmen

Wissensrepräsentation

explizit in CEP-Komponente; Wissen über Ereignisverarbeitung deklarativ in Form von Regeln formuliert

3.1.3 EDA-Architektur und -schichten Aus Sicht der Softwarearchitektur lassen sich bei einer Event-Driven Architecture drei logische Strukturierungsschichten unterscheiden, die in Abbildung 3.6 dargestellt sind: 1. Schicht: Ereignisquellen 2. Schicht: Ereignisverarbeitung 3. Schicht: Ereignisbehandlung Die Gliederung einer EDA in die logischen Schichten bildet die drei Kernschritte im Grundzyklus ereignisgesteuerter Systeme aus Abbildung 3.1 in der Softwarearchitektur ab: (a) Erkennen, (b) Verarbeiten, (c) Reagieren. Der Ereignisverarbeitungsschicht fällt selbstverständlich im Rahmen einer EDA eine besondere Bedeutung zu, deshalb erfolgt die ausführliche Beschreibung dieser Schicht im nachfolgenden Abschnitt 3.2. 1. EDA-Schicht: Ereignisquellen Jedes Ereignis muss einen Ursprung, eine Quelle, besitzen, aus dem bzw. der es entstammt. Ereignisquelle Eine Ereignisquelle (event source, event emitter, event producer) ist eine beliebige Entität, die Ereignisse erkennt (bzw. Daten als Ereignisse interpretiert), entsprechende Ereignisobjekte generiert und bekannt gibt [68]. Aufgrund der Generalität des Ereignisbegriffs kommen als Ereignisquellen sehr unterschiedliche Entitäten in Betracht. Beispiele für Quellen von Ereignissen sind

62


Ereignisquellen


Ereignisbehandlung


RFID/ Sensoren

Anwendungen/ Services Geschäftsprozesse

Nachrichtenticker CEP

CEP

Monitoring/ Dashboard

Handelsdaten

Nachrichtenkanal

...

Data Warehouse CEP

Netzwerkdaten

Datenbank

In-Adapter

Out-Adapter

Rückfluss

Abb. 3.6 Logische Schichten einer EDA: Ereignisquellen – Ereignisverarbeitung – Ereignisbehandlung

Sensoren, RFID-Lesegeräte, Datenticker bzw. -Feeds, Managementwerkzeuge für Rechnernetze, Softwaremodule, Web Services, ERP-Applikationen, Benutzerinteraktionen, Kollaborationswerkzeuge wie E-Mail und Instant Messaging, interne Uhren und viele mehr. Auch ereignisverarbeitende Komponenten (sogenannte CEPKomponenten, siehe unten) können selbst wiederum Ereignisse generieren und somit als Quelle fungieren. In welcher Weise die Ereignisse an die weiterverarbeitende Schicht gelangen, hängt von den eingesetzten Technologien und den Möglichkeiten der Ereignisquellen ab. 2. EDA-Schicht: Ereignisverarbeitung Als Eingabe dienen der Ereignisverarbeitung (event processing) die Ströme von Ereignisdaten aus mehreren Ereignisquellen. Ereignisstrom Ein Ereignisstrom (event stream) ist eine linear geordnete Sequenz von kontinuierlich eintreffenden Ereignisobjekten [68]. In der Regel ist ein Ereignisstrom nach temporalen Aspekten geordnet, beispielsweise nach dem Auftrittszeitpunkt der Ereignisentstehung oder nach dem Zeitpunkt des Eintreffens der Ereignisse im System. Ein Strom kann unbegrenzt oder begrenzt sein, z.B. durch ein Zeitintervall oder andere Kriterien wie Inhalt, geographische


63

Gegebenheiten oder Quelle. Ein Strom kann heterogene Ereignisse unterschiedlicher Ereignistypen enthalten. Die eigentliche Analyse und Verarbeitung des Stroms der eintreffenden Ereignisse erfolgt durch Techniken des Complex Event Processing. Die fachliche Logik zur Analyse der Ereignisse ist in Form von deklarativen Ereignisregeln modelliert. Anhand der Regeln werden Ereignismuster im Ereignisstrom erkannt und, wenn vorhanden, Aktionen als Reaktion eingeleitet. Es existieren verschiedene Arten, wie auf das Vorhandensein eines Ereignismusters reagiert werden kann: • Kaskadieren von Ereignissen Generierung komplexer Ereignisse (bzw. Ereignisobjekte) als Abstraktion von erkannten Ereignismustern, die wiederum als Eingabe der Ereignisverarbeitung weiterarbeitet werden können. • Weitergabe an Behandlungsschicht Einleiten von Abläufen in den operativen Unternehmensanwendungen, zum Beispiel durch Aufruf einer Funktion einer Anwendung, Initiieren eines Geschäftsprozesses, Bekanntmachung eines Ereignisses durch Veröffentlichen (publish) über eine Middleware oder Benachrichtigen (notify) von Personen. Aufgrund eines Ereignismusters können auch mehrere unterschiedliche Reaktionen ausgelöst werden, z.B. der Aufruf des Bestell-Service bei einem Lieferanten und das Veröffentlichen in einem Nachrichtenkanal, auf den dann eine BAMAnwendung zugreift. Adapter Aufgrund der Vielfalt der möglichen Quellen für Ereignisse liegen auch die Ereignisrepräsentationen in einer großen Anzahl von heterogenen Datenformaten vor. Vor der eigentlichen Verarbeitung müssen die Ereignisse deshalb in ein einheitliches internes Format transformiert werden. Zur Kapselung des internen Formats bildet je eine Ebene von Adaptern die Schnittstelle zu den Ereignisquellen und zur Ereignisbehandlung (= Ereignissenken). Die In-Adapter transformieren die Ereignisse der eingehenden Datenströme in das interne Format. Die Out-Adapter transformieren das interne Ereignisformat in das gewünschte externe Format und stellen das Ereignis extern zur Verfügung, z.B. durch das Senden einer Nachricht mit den Ereignisdaten. Diese Form der Interaktion entspricht dem in Abschnitt 3.1.1 erläuterten Push-Modus. 3. EDA-Schicht: Ereignisbehandlung Die eigentliche Ereignisbehandlung (event handling) als Reaktion auf Ereignismuster erfolgt in den produktiven Unternehmensanwendungssystemen, den nachgelagerten Backend-Systemen. Die Unternehmensanwendungen realisieren die Geschäftsprozesse oder verteilten Services, die von den Ereignissen angestoßen werden. Typische Reaktionen zur Ereignisbehandlung sind beispielsweise [18]: • Aufruf von Diensten und Auslösen von Prozessen Aufruf eines Dienstes eines Web Service oder einer anderen API, um eine fach-

64

•

•

• •


liche Anwendungsfunktion auszuführen oder einen Geschäftsprozess zu initiieren. Aktualisierung einer BAM-Anwendung Direkte Benachrichtigung von Benutzern durch Aktualisierung von Kennzahlen, Visualisierung in einer graphischen Benutzungsoberfläche oder in einem BAMDashboard oder auch durch explizites Erzeugen von Warnmeldungen. Publizieren einer (Ereignis-)Nachricht Einstellen eines Ereignisobjekts in Form einer Nachricht in eine Nachrichtenwarteschlange. Interessierte Ereignissenken werden durch die Middleware über die neue Nachricht informiert und können diese zur weiteren Verarbeitung abrufen. Aktualisierung von Datenbanken Persistente Speicherung der Daten eines Ereignisses in einer Datenbank bzw. in einem Data Warehouse. Auslösen einer menschlichen Prozessbehandlung In Notfallsituationen bzw. zur Verhinderung von sich anbahnenden Notfallsituationen ist es wichtig, die beteiligten Personen entlang einer vordefinierten Eskalationshierarchie frühzeitig zu informieren, z.B. durch das Versenden von Warnmeldungen, damit das Notfallteam die Situation erkennt und vorbereitete Notfallpläne einleiten kann.

Eine Softwarekomponente aus der Ereignisbehandlungsschicht kann natürlich selbst wiederum Ereignisse generieren und damit als Quelle fungieren. Diese Ereignisse fließen erneut in die Verarbeitungsschicht zur weitergehenden Analyse ein. Dieser Rückfluss von Ereignissen ist in Abbildung 3.6 durch den untersten Pfeil dargestellt. Eine ausführliche Diskussion der Ereignisbehandlung erfolgt in Kapitel 6. Fluss der Ereignisse durch die Schichten Die Mächtigkeit einer EDA resultiert aus der inhärenten Flexibilität jeder logischen Schicht: Welche Ereignisse werden generiert, wie werden diese verarbeitet, wer abonniert (subscribe) die Ereignisse und welche Aktionen werden initiiert [73]. Eine mehrstufige EDA-Anwendung kann aus vielen Komponenten bestehen, die jeweils Ereignisse konsumieren, aber auch generieren können. Die von einer Komponente generierten Ereignisse können wiederum von anderen Komponenten konsumiert werden. Der grundlegende Kontrollfluss der Verarbeitung in einer EDA resultiert aus dem flexiblen Fluss der Ereignisse durch die Schichten, der am Beispiel eines Systems zum Wertpapierhandel aufgezeigt werden soll. Bei dem Handel mit Wertpapieren hängen die Kauf- und Verkaufsentscheidungen von diversen Faktoren ab, die im Zusammenhang und ihrer Entwicklung analysiert werden müssen (siehe auch die Ausführungen zu analytischen Anwendungen in Abschnitt 2.5.3). Unterschiedliche Arten von Wirtschaftsdaten aus verschiedenen Quellen bilden die Informationsgrundlage und damit die Eingabe für das System. Als Ereignisquellen dienen u.a. Börsensysteme, Analystendaten, Aktienmarktticker und Bankeninformationen. So kann beispielsweise jede einzelne Kauf- oder Verkaufstransaktion für Aktien als Ereignis aufgefasst werden. Die Quelle, beispiels-

3.2 CEP – Grundkonzepte

65

weise eine Handelsplattform einer Aktienbörse, generiert als Folge ein entsprechendes Ereignisobjekt und leitet es an die Verarbeitungsschicht unseres Wertpapierhandelssystems weiter. In der Verarbeitungsschicht sind Regeln mit Ereignismustern definiert, die bestimmte Kurssituationen beschreiben, die ein Kauf- oder Verkaufssignal darstellen. Muster sind z.B. folgende Kurssituationen: • Das Volumen der Verkäufe von Unternehmensaktien aus der Energiebranche ist im Zeitraum von drei Stunden um 7% gestiegen. • Die Anzahl der Verkaufstransaktionen von Aktien der Firma ABC mit einem Wert größer 100 TEuro innerhalb der letzten 15 Minuten hat einen vorgegebenen Schwellenwert überschritten. Die eingehenden Ereignisströme werden hinsichtlich der spezifizierten Muster analysiert und beim Erkennen einer bestimmten Kurssituation wird eine dafür vordefinierte Reaktion ausgeführt. Die Reaktion entstammt typischerweise aus den operativen Anwendungssystemen in der Schicht der Ereignisbehandlung. In unserem Beispiel ruft die Ereignisverarbeitung in einem Backend-System einen Dienst in Form eines Web Service zur Kauf- bzw. Verkaufsabwicklung einer Unternehmensaktie aus der Energiebranche auf oder sendet eine Warnmeldung in Form einer EMail an einen menschlichen Wertpapierhändler.

3.2 CEP – Grundkonzepte Die zentrale Architekturebene einer EDA ist die Ereignisverarbeitungsschicht in Abbildung 3.6. In dieser Schicht werden die einfließenden Ereignisströme anhand von Regeln auf das Vorhandensein von komplexen Ereignismustern hin analysiert und ggf. Aktionen eingeleitet. Die komplexe Analyse der Ereignisse erfolgt mit Techniken des Complex Event Processing (CEP). CEP erfordert den Einsatz von fortgeschrittenen Ereignisregelinterpretern sowie Sprachen und Techniken zur Definition und Erkennung (matching) von Ereignismustern und -korrelationen. Dieser Abschnitt stellt die wichtigsten Konzepte und Elemente von CEP überblicksartig vor. Eine ausführliche Einführung in CEP anhand einer Fallstudie erfolgt in Teil II dieses Buches, und zwar für Ereignismodelle in Kapitel 4 und für Ereignismuster und -regeln in Kapitel 5.

66


3.2.1 Ereignismodelle, -muster und -regeln Die Kernkomponente für die Ereignisverarbeitung in einer Event-Driven Architecture ist eine CEP-Komponente (event processing component). Luckham bezeichnet eine CEP-Komponente auch als “Event Processing Agent“ [63].7 Event Processing Agent (EPA) bzw. CEP-Komponente Ein Event Processing Agent bzw. eine CEP-Komponente ist ein Softwaremodul, das komplexe Ereignisse verarbeiten und Ereignismuster in einem Strom von Ereignissen erkennen kann [68]. Die Abbildung 3.7 zeigt einen Event Processing Agent mit seinen grundlegenden Elementen: den Metadaten (a) Ereignismodell und (b) Ereignisregeln sowie einer (c) Event Processing Engine. Eine qualitativ hochwertige CEP-Anwendung zeichnet sich durch wohlspezifizierte Metadaten aus, da die Metadaten das Fach- und Problemlösungswissen für eine betrachtete Anwendungsdomäne repräsentieren.

Eingangsstrom

Event Processing Agent

Event Processing Engine

Ereignismodell

Ereignisregeln

Ausgangsstrom

Applikation/ Datenbank

Abb. 3.7 Elemente eines Event Processing Agent

(a) Ereignismodell Die Grundlage von EDA und CEP ist eine exakte Spezifikation der zu verarbeitenden Ereignisse. Nur auf Basis eines formal definierten Ereignisformats ist der Austausch von Ereignissen zwischen Systemkomponenten und die Verarbeitung von Ereignisströmen möglich. Ein Ereignismodell (event model) beschreibt die möglichen Typen von Ereignissen, d.h. die unterschiedlichen Arten von relevanten Ereignissen 7

Abhängig vom Kontext verwenden wir die Bezeichnung CEP-Komponente allgemein für eine ereignisverarbeitende Komponente, sei es ein einzelner EPA oder aber auch ein Netzwerk von EPAs.


67

in der betrachteten Anwendungsdomäne, mit ihren Eigenschaften sowie die Beziehungen und Abhängigkeiten zwischen den Typen. Die Ereignistypen können auf unterschiedlichen Abstraktionsebenen vorliegen. Um die Entkopplung von Ereignisquellen und -senken zu gewährleisten, muss ein Ereignis die vollständigen Informationen mit sich führen, die für die weitere Verarbeitung bedeutsam sein können. Zum einen enthält jedes Ereignis domänenunabhängige Daten, die Auskunft über das Auftreten des Ereignisses geben. Dies sind mindestens eine Ereignis-ID, der Ereignistyp, ein Zeitstempel (timestamp) sowie die Angabe der Quelle, aus der das Ereignis entstammt. Neben diesen allgemeinen Informationen muss ein Ereignis zum anderen natürlich auch noch beschreiben, was denn eigentlich passiert ist, also die eigentlichen Nutzdaten (payload) mit sich führen. Zum Beispiel beschreiben die Nutzdaten bei einer Finanztransaktion, um welchen Transaktionsvorgang es sich handelt (bspw. Einzahlung oder Auszahlung), das betroffene Konto, den Geldbetrag, die Währung, die Kundennummer sowie die Identifikation des für diese Transaktion verantwortlichen Bankangestellten. (b) Ereignisregeln Auf der Basis der Spezifikation des Ereignismodells werden Ereignisregeln (event processing rules) zur Verarbeitung der Ereignisse definiert. Die Regelmenge repräsentiert die fachliche Logik der Anwendungsdomäne. Die Regeln können beispielsweise ein Ereignisformat in ein anderes Format transformieren, Ereignisse ausfiltern, die bei der weiteren Verarbeitung nicht mehr benötigt werden, mehrere einfache Ereignisse zu einem komplexeren Ereignis aggregieren und ein neues abgeleitetes Ereignisobjekt generieren. Eine Regel besteht aus einem Bedingungsteil, der als Bedingung ein Muster (pattern) von zusammenhängenden Ereignissen enthält, und einem Aktionsteil, der eine oder mehrere auszuführende Aktionen beschreibt. Wesentliches Konzept ist die Mustererkennung (pattern matching), d.h. der Abgleich des Ereignisstroms mit den Mustern in den Bedingungsteilen der Regelmenge. Erfüllen die Ereignisse im Ereignisstrom die in einem Muster definierten Bedingungen, so ist der Bedingungsteil der entsprechenden Regel erfüllt und der Aktionsteil der Regel wird ausgeführt. Für die Beschreibung der Ereignismuster und -regeln stehen spezielle Sprachen zur Verfügung, sogenannte EPLs (event pattern languages [63] bzw. event processing languages [68]) oder CQLs (continuous query languages [7]). Ein Beispiel für eine EPL ist die Sprache RAPIDE-EPL von Luckham [63]. In RAPIDE-EPL können Ereignismuster unter anderem durch die Operatoren and, or und → wie folgt definiert werden: • when (A and B and C) then action_X Die Regel feuert, wenn die Ereignisse A, B und C im Ereignisstrom aufgetreten sind. • when (A → (B or C)) then action_Y Die Regel feuert, wenn zuerst das Ereignis A und danach das Ereignis B oder das Ereignis C aufgetreten sind.

68


Derzeit existiert jedoch noch kein etablierter Standard zur formalen Beschreibung von Ereignissen und den darauf aufbauenden Mustern und Regeln. Weite Verbreitung hat die CQL der Open-Source-Engine Esper [34] erlangt, die in den Fallbeispielen in Teil II dieses Buches vorgestellt wird. Reichen die Daten in den Ereignissen für die Verarbeitung nicht aus, so müssen diese durch Kontextwissen angereichert werden. Dieses Kontextwissen muss für die CEP-Komponente durch den Zugriff auf Applikationslogik oder durch die direkte Abfrage von Datenbanken verfügbar sein. Diese Erweiterung eines EPA durch den Zugriff auf externes Wissen ist in Abbildung 3.7 angedeutet. (c) Event Processing Engine Den Mittelpunkt eines Event Processing Agent bildet eine Event Processing Engine, in die die operativen Ereignisdaten kontinuierlich einfließen. Eine Event Processing Engine ist eine spezielle Art von Regelinterpreter, der auf die kontinuierliche Verarbeitung von großen Massen von Ereignisdaten im Arbeitsspeicher hin optimiert ist. Die Event Processing Engine gleicht den Strom der Ereignisse mit den Mustern in den Bedingungsteilen der Regelmenge ab und sobald ein Muster in der Ereignismenge auftritt, führt der Interpreter die entsprechende Ereignisregel aus. Da für die Mustererkennung (pattern matching) auch in der Vergangenheit aufgetretene Ereignisse relevant sein können, müssen die Ereignisdaten permanent im Arbeitsspeicher vorgehalten werden. Typischerweise ist die Ereignismenge jedoch viel zu groß, um vollständig gespeichert zu werden. Betrachtet werden deshalb Ereignisse in einem gewissen Intervall (Zeit- oder Längenfenster). Neue Ereignisse kommen beim Eintreffen zu dem Intervall hinzu, alte Ereignisse fallen als Folge aus dem Intervall heraus. Das Angebot an Event Processing Engines hat in den letzten Jahren stark zugenommen, neben kommerziellen Werkzeugen sind auch leistungsfähige OpenSource-Produkte verfügbar. Der Abschnitt 5.7 geht genauer auf die verfügbaren CEP-Produkte ein.

3.2.2 Netzwerk von CEP-Komponenten Als logische Konsequenz aus der Komplexität von Problemstellungen in anspruchsvollen Anwendungsdomänen ist auch die Ereignisverarbeitung in diesen Anwendungsdomänen eine äußerst komplexe Herausforderung und sollte, wenn möglich, in Teilschritten erfolgen. Häufig ist es effizienter, komplexe Verarbeitungsvorgänge in kleinen Schritten mit jeweils einfachen Ereignismustern und wenigen Regeln pro Schritt durchzuführen, als die komplette Verarbeitung in einem einzigen, großen Schritt mit komplexen Ereignismustern und vielen Regeln abzuarbeiten. Um die schrittweise Verarbeitung zu realisieren, muss jeder Schritt durch eine einzelne CEP-Komponente realisiert werden. Durch die Verknüpfung mehre-


69

rer CEP-Komponenten ergibt sich ein Netzwerk, in dem die Ausgabe einer CEPKomponente als Eingabe einer anderen dient. Event Processing Network (EPN) Ein Event Processing Network (bzw. CEP-Netzwerk) ist eine Menge von Event Processing Agents, die durch sogenannte Ereigniskanäle miteinander verbunden sind [68], über die sie während der Verarbeitung Ereignisse austauschen. Die Struktur eines Event Processing Network kann entweder statisch oder dynamisch sein. Bei einem dynamischen Netzwerk ist es möglich, bisherige CEPKomponenten zu entfernen oder neue hinzuzufügen. Auch die Kanäle können dynamisch änderbar sein. Das Verhalten in einem dynamischen Netzwerk wird durch die Muster der Ereignisregeln in dem Netzwerk kontrolliert. Bei einem statischen Netzwerk sind die Knoten und Kanten des Netzwerks fest vorgegeben und lassen sich zur Laufzeit nicht ändern. Eine einzelne CEP-Komponente übernimmt hierbei nur einen oder wenige abgegrenzte Schritte im Prozess der Ereignisverarbeitung, z.B. das Herausfiltern von doppelten Ereignissen oder das Aggregieren von zusammenhängenden Ereignissen zu einem komplexen Ereignis. Aufgrund der eingeschränkten Regelmenge kann eine solche Komponente auch als leichtgewichtig bezeichnet werden. CEP-Anwendung Eine CEP-Anwendung besteht demnach aus einem Netzwerk von interagierenden, leichtgewichtigen Event Processing Agents bzw. CEP-Komponenten.

Typische Netzstruktur Eine typische Struktur eines Event Processing Network zeigt die Abbildung 3.8. Graphisch veranschaulicht bilden die Event Processing Agents die Knoten und die Ereigniskanäle die Kanten des Netzwerks. Die durch die Pfeile dargestellten gerichteten Verbindungen zwischen den Knoten repräsentieren den Fluss der Ereignisse im Netzwerk. Unterschiedliche Quellen stellen Ereignisdaten in der Regel in unterschiedlichen Formaten bereit. In der In-Adapterebene werden diese heterogenen Formate in ein internes Ereignisformat transformiert, so dass im Netzwerk die Annahme gilt, dass alle Ereignisse in dem gleichen, kompatiblen Format vorliegen. Typischerweise ist nicht jedes Ereignis für ein Anwendungsproblem von Interesse. Wenn zum Beispiel dasselbe RFID-Lesegerät denselben RFID-Transponder innerhalb von wenigen Sekunden mehrmals liest, befindet sich der Transponder immer noch im Empfangsbereich des Lesegeräts und die Mehrfachlesungen können ignoriert werden. Damit alle nichtrelevanten Ereignisse möglichst frühzeitig eliminiert werden, übergeben die In-Adapter die Ereignisse direkt an Filter-EPAs. Die Filter-EPAs sind normalerweise eher einfach und enthalten keine rechenintensiven

70

3 Event-Driven Architecture und Complex Event Processing im Überblick Aggregierte Ereignisse

Aggregation

Aggregationsebene

Aggregation

Gefilterte Ereignisse

Filter

Filterebene

Filter

Ereignisobjekte

InAdapter

InAdapter

OutAdapter

Adapterebene

Geschäftsereignisse

Abb. 3.8 Typische Struktur eines Event Processing Network (nach [63], S. 208)

Regeln. Sie filtern die im Kontext der Anwendung unbedeutsamen Ereignisse heraus und leiten lediglich die relevanten Ereignisse an die Aggregations-EPAs der nächsten Ebene weiter. Die Aggregationsknoten brauchen dann nur noch die stark reduzierte Ereignismenge auszuwerten. Zum Beispiel werden mehrere RFID-Ereignisse desselben RFID-Transponders, d.h. mit derselben Transponder-ID, zu einem Bewegungsereignis aggregiert, das aussagt, dass sich die Position des RFID-Transponders verändert haben muss. Das aggregierte Ereignis kann nun für weitere Systemkomponenten bereitgestellt werden. Hierzu wird es über einen Out-Adapter publiziert. Leichtgewichtige versus schwergewichtige Event Processing Agents Event Processing Networks strukturieren die komplexe Verarbeitung von Ereignisströmen in eine Folge von abgegrenzten Schritten. Jeder Event Processing Agent übernimmt eine klar definierte Teilaufgabe in der Ereignisverarbeitung und besteht hierzu aus einer Event Processing Engine mit entsprechend wenigen, fachlich direkt zusammenhängenden Ereignisregeln. Als Konsequenz stellt sich die Ereignisverarbeitung als Netzwerk von leichtgwichtigen Event Processing Agents dar. Die Verarbeitung der Ereignisse in kleineren Schritten dient der Reduzierung der Komplexität der Problemlösungsaufgabe und macht die Ereignisverarbeitung tranparenter und damit besser wart- und erweiterbar. Das Vorfiltern der Ereignismenge durch Filter-EPAs und die daraus resultierende Reduzierung der Anzahl der Er-


71

eignisse führt zu einer signifikanten Erhöhung der Performance. Durch geschickte Strukturierung lässt sich die Ereignismenge von Schritt zu Schritt im Event Processing Network reduzieren, so dass auch sehr große Ereignisvolumina in Echtzeit verarbeitet werden können. Ein Event Processing Network ist inhärent verteilt und kann deshalb auch physikalisch verteilt auf unterschiedlichen Rechnern eingesetzt werden. Dies führt zu einer sehr guten Skalierbarkeit. Die Strukturierung eines Event Processing Network ist in erster Linie eine fachliche Fragestellung und ist entscheidend für die Wartbarkeit und Effizienz des CEP-Systems. Durch das Konzept eines Netzwerks von CEP-Komponenten lassen sich zwei etablierte Qualitätskriterien aus dem Software Engineering auf die Entwicklung von CEP-Systemen übertragen: 1. starke Kohäsion und 2. lose Kopplung. Da eine leichtgewichtige CEP-Komponente eine klar umrissene Verantwortung für eine fachliche Aufgabe besitzt, hat die Komponente eine hohe Kohäsion. Eine hohe Kohäsion ist die Voraussetzung für die Minimierung der Abhängigkeiten zwischen Komponenten und unterstützt eine lose Kopplung. Im Gegensatz dazu ist eine zentrale, monolithische CEP-Komponente, bestehend aus einer Event Processing Engine mit einer großen Menge von komplexen Regeln, normalerweise sehr schwer zu verstehen, nachzuvollziehen und damit auch schwierig zu warten. Abbildung 3.9 visualisiert die beiden unterschiedlichen Varianten für die Realisierung einer CEP-Anwendung.


Zentraler Event Processing Agent Regeln

Ereignismodell

schwergewichtig leichtgewichtig Engine

Modell

Engine

Regeln

Modell

Regeln



Engine

Modell

Regeln


Abb. 3.9 Schwergewichtige versus leichtgewichtige CEP-Komponenten

72


Wenn statt verteilt über mehrere Knoten in einem Netzwerk die komplette Verarbeitung vollständig in einer einzigen Event Processing Engine abgebildet wird, so kann diese als schwergewichtige CEP-Komponente aufgefasst werden. Die Mustererkennung auf einer großen Regelmenge ist bei einer einzelnen Event Processing Engine durch fortgeschrittene Matching-Algorithmen in der Regel hoch optimiert, dafür sind Transparenz des Kontrollflusses, Wartbarkeit und Skalierbarkeit schwierig. Jede dieser beiden Varianten besitzt ihre Vorteile gegenüber der anderen, je nachdem welches Anwendungsproblem betrachtet wird. Wobei die Vorteile des Netzwerkansatzes eindeutig überwiegen. Ein Netzwerk von CEP-Komponenten zeigt eine Strategie auf, um den Einsatz von Ereignisregeln zu optimieren und die Problemlösungsaufgabe in einfache und handhabbare Schritte zu zerlegen. Ein Netzwerk von leichtgewichtigen CEP-Komponenten setzt allerdings voraus, dass sich auch das betrachtete fachliche Anwendungsproblem entsprechend in fachlich abgegrenzte Teilschritte strukturieren lässt. Ist dies fachlich nicht möglich, so bleibt nur die schwergewichtige Variante als Lösungsalternative.

3.3 EDA – Bewertung Eine Event-Driven Architecture stellt Ereignisse als zentrales Konzept in den Mittelpunkt der Softwareentwicklung. Das fachliche Potenzial, das Ereignisorientierung als Architekturstil entfaltet, ist ausführlich in Kapitel 2 beschrieben. Dieser Abschnitt behandelt die Eigenschaften einer EDA aus Sicht der Softwarequalität. Ausschlaggebend für die Qualitätsmerkmale von EDA sind deren Haupteigenschaften: Kommunikation durch den Austausch von Ereignissen als Interaktionsmechanismus, Publish/Subscribe-Interaktion im Push-Modus, Asynchronität, komplexe Ereignisverarbeitung mittels eines Netzwerks von leichtgewichtigen CEPKomponenten sowie Fachlogik repräsentiert durch deklarative Ereignismuster und -regeln. Insgesamt betrachtet bildet eine ereignisgesteuerte Softwarearchitektur die Grundlage für eine offene und dynamische Struktur von Unternehmensanwendungen, die es ermöglicht, sich ändernde und zukünftige Anforderungen zu berücksichtigen und umzusetzen. EDA erlaubt die Entwicklung hochgradig kombinierbarer Anwendungssysteme, die ein realitätsnahes Abbild der operativen Unternehmensprozesse liefern. Qualitätsmerkmale einer EDA Die Abbildung 3.10 greift den Grundzyklus ereignisgesteuerter Systeme aus Abbildung 3.1 auf und ergänzt ihn um die Qualitätsmerkmale, die aus einem ereignisgesteuerten Architekturansatz resultieren: Aktualität, Agilität, Effizienz, Robustheit, Wartbarkeit und Skalierbarkeit.

3.3 EDA – Bewertung

73

Ag

itä al

ilit

ät

tu Ak t Reagieren

Erkennen

Skalierbarkeit

Effizienz

EDA

Verarbeiten

ob th us ei t

a W

R

it

ke

ar

rtb

Abb. 3.10 Qualitätsmerkmale einer EDA

• Aktualität Aufgrund der Erkennung und Analyse sowohl von Einzelereignissen als auch von Beziehungsmustern zwischen zusammenhängenden Ereignissen zum Zeitpunkt ihres Auftretens liefert EDA ein aktuelles Bild des derzeitigen Status der Unternehmensprozesse. Betriebliche Geschäftsereignisse werden in Echtzeit überwacht und bewertet, um hieraus zeitnah operative Entscheidungen abzuleiten. • Agilität EDA ermöglicht eine hohe fachliche und technische Agilität durch eine wirklichkeitsnahe Modellierung, die flexibel an sich ändernde Geschäftsanforderungen angepasst werden kann. Zum einen lassen sich neue Ereignistypen, Ereignisquellen und Systembestandteile durch die extrem lose Kopplung bzw. Entkopplung einfach in das System integrieren. Zum anderen können sich ändernde Abläufe durch die Adaption der deklarativen Ereignisregeln ohne Unterbrechung des laufenden Betriebs leicht abgebildet werden. Da auch die Struktur des Event Processing Network dynamisch durch Entfernen oder Hinzufügen von EPA-Knoten und Kanten änderbar ist, resultiert eine hohe Flexibilität und Anpassungsfähigkeit der technischen Infrastruktur. Generell lassen sich Geschäftsprozesse, die auf Basis von EDA entworfen sind, einfach modifizieren und damit den realen Anfordernissen anpassen. • Effizienz CEP ist ausgelegt auf die Verarbeitung extrem großer Mengen von Ereignisdaten. Diese Fähigkeit zur effizienten Massendatenverarbeitung beruht einerseits auf einem guten Entwurf eines effizienten Event Processing Network sowie anderseits auf der Leistungsfähigkeit der verfügbaren Event Processing Engines, die

74


mehrere hunderttausend Ereignisse pro Sekunden verarbeiten können. Operative Geschäftsentscheidungen können somit auf Grundlage der Auswertung einer breiten Informationsbasis unter Einbeziehung mehrerer Ereignisquellen gefällt werden. • Robustheit Der geringe Grad der Kopplung und die Push-Interaktion führen zu einer geringen Abhängigkeit zwischen den Systemkomponenten, so dass bestehende Komponenten geändert oder neue hinzugefügt werden können, ohne dass die Ereignisquellen als Ausgangspunkt der Kommunikation hiervon tangiert werden. Änderungen wirken sich somit nur an wenigen, klar abgegrenzten Stellen aus. • Wartbarkeit Kohärente CEP-Komponenten, deklarative Wissenrepräsentation durch Ereignisregeln sowie Entkopplung von Systemteilen verbessern die Wartbarkeit in einer EDA. • Skalierbarkeit Asynchronität und Publish/Subscribe-Kommunikation mit Push-Interaktion einer EDA entkoppeln Systemkomponenten logisch und bilden somit auch die Grundlage für eine physikalische Verteilung. Weiterhin erfolgt auch die Ereignisverarbeitung über die Knoten eines Event Processing Network verteilt und kann deshalb ebenfalls physikalisch verteilt auf unterschiedlichen Rechnern eingesetzt werden. Insgesamt erfüllt eine EDA damit die Voraussetzungen für eine gute Skalierbarkeit. Potenzielle Defizite eines ereignisgesteuerten Ansatzes Wie die obige Betrachtung zeigt, bietet eine EDA eine ganze Reihe von wünschenswerten Qualitätsmerkmalen. Jedoch resultieren aus den Eigenschaften einer EDA nicht nur die obigen positiven Merkmale, sondern auch einige Nachteile, wie die folgenden: • Redundanz Als Konsequenz aus der Ereignisorientierung resultiert häufig, dass Daten und Funktionalität redundant in mehreren Systemen vorgehalten werden. Dies ist eine logische Folge der extrem losen Kopplung, denn eine Minderung der Redundanz verstärkt automatisch die Kopplung, weil Komponenten voneinander abhängig werden (siehe [28], Kapitel 6.1.1). Generell erschwert Redundanz die Wartbarkeit von Systemen, da Modifikationen an redundanten Daten oder Funktionen an mehreren Stellen nachgezogen werden müssen, was leicht zu Inkonsistenzen führen kann. • Schwierige Fehlersuche Lose gekoppelte verteilte Systemarchitekturen erschweren die Lokalisierung und Behebung von Fehlern im System [49]. Gewisse Fehlerarten sind zur Kompilierungszeit nicht mehr zu entdecken. Ein Beispiel für einen nur schwer herauszufindenden Fehler ist der Fall, dass bei einem vermeintlichen Ereignisempfänger überhaupt keine Ereignisse ankommen. Das Problem lässt sich erst zur Laufzeit feststellen, und die Ursachensuche kann sich als schwierig erweisen. Sendet

3.3 EDA – Bewertung

75

die Quelle vielleicht gar keine Ereignisse oder die falschen, ist die Middleware falsch konfiguriert oder gar fehlerhaft, wartet der Empfänger auf das falsche Ereignis oder hat der Empfänger versehentlich einen falschen Ereignistyp in der nachrichtenorientierten Middleware abonniert? Neben der Fehlersuche ist auch das strukturierte Testen von EDA-Anwendungen sehr schwierig, in der Praxis bewährte Testmethoden und -erfahrungen fehlen für EDA noch. • Agilität Agilität ist bereits als positives Merkmal von EDA aufgeführt. Jedoch geht mit einer leichten Änderbarkeit auch immer ein gewisses Maß an Unsicherheit einher. Häufige Änderungen an Systemkomponenten erschweren das Verständnis des Gesamtsystems und die Bestimmung seines tatsächlichen Zustands. Das Nachverfolgen des Flusses der Ereignisse durch ein dynamisches Netzwerk mit diversen Pfaden kann sich als äußerst schwierig erweisen [73]. Werkzeugunterstützung ist notwendig, um die Systemänderungen zu verwalten und nachvollziehen zu können [49]. • Undurchsichtiger Kontrollfluss Einer der Hauptnachteile eines regelbasierten Ansatzes, wie ihn CEP verfolgt, ist der schwer verständliche Kontrollfluss. Insbesondere bei großen Regelmengen geht die Übersichtlichkeit leicht verloren und damit das Verständnis und die Kontrolle des Systemverhaltens. Solche Regelmengen werden auch als “Regelspaghetti“ bezeichnet [90]. Die Strukturierung der Regelmenge, wie beispielsweise in einem Event Processing Network, trägt sehr zur Verständlichkeit des Kontrollflusses bei. Die schwierige Fehlersuche und die möglichen Probleme bei zu hoher Agilität sind generelle Nachteile bei lose gekoppelten, hochgradig verteilten Systemarchitekturen. Solche Systeme können das “architect‘s dream, developer‘s nightmare“-Symptom aufweisen [50, 51]. Gesucht ist eine ausgeglichene Balance zwischen wünschenswerten Architekturkonzepten und einer effektiven Softwareentwicklung. Gesamtbewertung EDA ist ein Architekturprinzip zur Gestaltung von Unternehmensanwendungen mit vielversprechenden Qualitätsmerkmalen. Der Abschnitt 2.3.3 betrachtet die Ereignisorientierung aus der fachlichen Perspektive, während dieser Abschnitt die fachlichen und technischen Merkmale diskutiert, die aus den spezifischen Eigenschaften von EDA resultieren. Abbildung 3.11 führt die positiven Qualitätseigenschaften von EDA zusammenfassend auf, differenziert nach dem Nutzen für die Geschäftstätigkeit als auch für die IT-Infrastruktur eines Unternehmens. Es wird nur selten Anwendungsprobleme geben, bei denen ein ausschließlich ereignisorientierter Architekturansatz zur Anwendung kommt. Aufgrund der Vielfalt der unterschiedlichen Anforderungen von Anwendungsproblemen und ihren diversen Wechselwirkungen innerhalb eines Unternehmens muss sich diese Vielfalt auch in der Softwarearchitektur widerspiegeln. Deshalb setzt sich die Architektur von Unternehmensanwendungen typischerweise aus einer Kombination von unterschiedlichen Architekturstilen zusammen-

76

3 Event-Driven Architecture und Complex Event Processing im Überblick Nutzen einer Event-Driven Architecture

Geschäftsnutzen

Nutzen für IT-Infrastruktur

Aktualität/ Echtzeitfähigkeit

Technische Agilität/ Anpassungsfähigkeit

Fachliche Agilität

Robustheit

Schnelle Reaktionsfähigkeit

Wartbarkeit

Effizienz fachlicher Prozesse

Skalierbarkeit

Transparenz fachlicher Entscheidungen

Abb. 3.11 Nutzenpotenzial einer EDA

setzen. Service-orientierte Architektur, Event-Driven Architecture, prozessbasierte Architektur mit expliziter Prozesssteuerung durch Business Process Management (BPM), Enterprise Application Integration sowie andere Architekturansätze behalten jeweils ihre Berechtigung und bilden im Zusammenwirken die Grundlage für eine zukunfts- und leistungsfähige Softwarearchitektur von Unternehmensanwendungen [73]. Der besondere Beitrag von Event-Driven Architecture in diesem Architekturmix liegt insbesondere darin, dass Unternehmensarchitekturen agiler, reaktionsschneller und echtzeitfähig werden.

3.4 Fallstudie: Verkehrskontrolle und -steuerung Die nachfolgenden Buchkapitel veranschaulichen die grundlegenden Konzepte von Event-Driven Architecture und Complex Event Processing anhand einer durchgehenden Fallstudie. Als Anwendungsbereich für diese Fallstudie dient das Gebiet der Verkehrskontrolle und -steuerung (traffic management). Verkehrssteuerungssysteme sind in der Regel sensorbasiert und weisen somit wesentliche Kriterien auf, die in Kapitel 2.5 als prädestiniert für einen ereignisgesteuerten Lösungsansatz identifiziert werden.

3.4 Fallstudie: Verkehrskontrolle und -steuerung

77

Ziele der Verkehrssteuerung Das stetig wachsende Verkehrsaufkommen und die damit einhergehenden ökonomischen und ökologischen Folgewirkungen führen zu der Notwendigkeit einer intelligenten Steuerung der Verkehrsflüsse. Ein intelligentes Steuerungssystem zur Koordination des Verkehrs soll die folgenden Ziele realisieren: • Erhöhung der Effizienz der bestehenden Verkehrsinfrastruktur durch bessere Ausnutzung der vorhandenen Kapazität der Verkehrswege • Vermeidung von Verkehrsbehinderungen, insbesondere von Verkehrsstaus • Verbesserung der Sicherheit der Verkehrsteilnehmer • Senkung der verkehrsbedingten Umweltbelastungen, die durch die Lärm- und Schadstoffemissionen (bspw. CO2 , Feinstaub) der Verkehrsmittel entstehen Diese Fallstudie beschränkt sich aus Gründen der Übersichtlichkeit auf den Verkehrsweg Straße. Die Betrachtungen gelten aber analog für die Verkehrswege Schienen-, See- und Luftverkehr sowie deren Kombination zu einem multimodalen Verkehrssystem. Die Grundlage für Informationssysteme zur Verkehrssteuerung bilden zeitaktuelle Informationen über die Verkehrswege (z.B. Straßensperrungen, Baustellen), Verkehrsdaten (z.B. Verkehrsdichte, Durchschnittsgeschwindigkeit) sowie Umfelddaten (z.B. Witterungsdaten über Temperatur, Niederschlag, Nebel). Die Herausforderung liegt nun darin, diese diversen Daten im notwendigen Umfang zu erheben, sie in der erforderlichen Qualität bereitzustellen und die richtigen Handlungsanweisungen unmittelbar aus ihnen abzuleiten. Analyse der Verkehrssituation Eine zeitaktuelle Analyse der bestehenden Verkehrssituation sowie eine Prognose deren voraussichtlicher Entwicklung sind Voraussetzung für eine aktive Verkehrssteuerung. Charakteristische Kennzahlen, um die Verkehrssituation beurteilen und Prognosen über deren Entwicklung im weiteren Verlauf der Verkehrswege aufstellen zu können, sind: • Verkehrsstärke Die Verkehrsstärke innerhalb eines Streckenabschnitts bezeichnet die Anzahl Fahrzeuge pro Stunde, bezogen auf beide Fahrtrichtungen. • Verkehrsdichte Die Verkehrsdichte bezeichnet die Anzahl Fahrzeuge pro Streckenkilometer. Aufgrund der Verkehrsdichte findet eine Klassifizierung der Auslastung eines Streckenabschnitts statt: in der Regel von gering, über hoch bis zu Überlast. • Durchschnittsgeschwindigkeit Die Durchschnittsgeschwindigkeit bezeichnet die mittlere Geschwindigkeit aller Fahrzeuge in einem Streckenabschnitt innerhalb eines festgelegten Zeitraums. Aufgrund der erhobenen Kennzahlen müssen qualitative Schlüsse gezogen werden, um die Verkehrsflüsse aktiv zu leiten und die Verkehrsteilnehmer rechtzeitig

78


und aktuell zu informieren, was sie auf der Wegstrecke erwartet und wie problematische Streckenabschnitte umfahren werden können. Das Leiten der Verkehrsflüsse kann beispielsweise durch automatische Verkehrsanzeigen oder verkehrsabhängig geschaltete Lichtsignalanlagen erfolgen. Typische diagnostizierte Situationen und mögliche Steuerungsentscheidungen sind beispielhaft in Tabelle 3.3 aufgeführt. Tabelle 3.3 Beispielhafte Verkehrsdiagnosen und mögliche Aktionen Diagnostizierte Situation

Steuerungsaktion

Verkehrsunfall

Warnung vor unfallgefährdender Situation

Verkehrsunfall

Umleitungsempfehlung auf eine nicht blockierte Strecke

Verkehrsstau

Warnhinweise durch automatische Verkehrskontrolle

Verkehrsstau

Umleitungsempfehlung auf alternative Strecken

Hohes Verkehrsaufkommen

Geschwindigkeitsbeschränkung zur Verhinderung von Unfällen

Hohes Verkehrsaufkommen

Umleitungsempfehlung auf weniger ausgelastete Strecken

Geringes Verkehrsaufkommen

Aufheben bzw. Anheben einer bestehenden Geschwindigkeitsbeschränkung

Schlechte Witterung

Geschwindigkeitsbeschränkung zur Verhinderung von Unfällen

Schlechte Witterung

Warnhinweis an Verkehrsteilnehmer

In der Regel stellen Verkehrsprobleme außergewöhnliche Situationen dar, die sich aus ungewöhnlichem Verhalten der Straßenverkehrs ergeben. Folglich kann Verkehrsdiagnose als die Identifikation von Abweichungen des normalen Verkehrsverhaltens aufgefasst werden. Solche Abweichungen können sowohl in zeitlicher als auch in räumlicher Dimension entstehen, wie in Abbildung 3.12 illustriert. Im Zuge der aktiven Verkehrssteuerung müssen somit die Verkehrsinformationen zeitlich und räumlich in Beziehung gesetzt werden. Schwellenwertverletzungen Ein Verkehrsproblem lässt sich dadurch identifizieren, das eine ermittelte Verkehrskennzahl einen vorgegebenen Schwellenwert verletzt, z.B. wenn die durchschnittliche Geschwindigkeit in einem betrachteten Streckenabschnitt unter einen definierten Wert sinkt (dargestellt in der ersten Zeile in Abbildung 3.12). In der Regel muss der Schwellenwert für die Dauer eines vorgegebenen Zeitraums unterschritten sein, damit von einem existenten Verkehrsproblem gesprochen wird. Sprunghafte Veränderungen Unvermittelte Veränderungen oder signifikante Unterschiede zu aufeinander folgenden Zeitpunkten oder in benachbarten Streckenabschnitten deuten auf Verkehrsprobleme hin, beispielsweise ein plötzlicher Abfall der Durchschnittsgeschwindigkeit. Häufig bilden ernsthafte Probleme, wie z.B. Unfäl-

3.4 Fallstudie: Verkehrskontrolle und -steuerung Ebenen der Problemerkennung

79

Dimensionen der Problemerkennung zeitlich räumlich

Geschwindigkeit

Schwellenwertverletzung

Schwellenwert kritischer Bereich Zeit

Geschwindigkeit pro Abschnitt

Geschwindigkeit

Sprunghafte Veränderung

abrupte Änderung 18 40

abrupte Änderung

42

Geschwindigkeit

Zeit

Entwicklungstrend

40 39

Geschwindigkeit pro Abschnitt

kontinuierl. Trend

22 42

34

26

29

40

25

Zeit

kontinuierl. Trend

Abb. 3.12 Kategorien und Dimensionen der Problemdiagnose

le, die Ursache für solche sprunghaften Veränderungen (illustriert in Zeile zwei in Abbildung 3.12). Entwicklungstrends Andere Verkehrsprobleme entwickeln sich nicht sprunghaft, sondern eher langsam und graduell. Um diese Art von Problemen zu erkennen, ist eine Form der Trendvorhersage erforderlich. Wenn beispielsweise die beobachtete Durchschnittsgeschwindigkeit in einem Zeitraum oder im Vergleich von benachbarten Streckenabschnitten kontinuierlich sinkt, ist mit einem weiteren Absinken der Geschwindigkeit zu rechnen (siehe die dritte Zeile in Abbildung 3.12). Die Analyse der Verkehrssituation muss demnach die Verkehrskennzahlen zeitlich und/oder räumlich korreliert betrachten, um rechtzeitig Entwicklungen und Trends zu erkennen. Schlüsselfaktor Sensoren Verkehrsdaten bilden die Basis jeder Verkehrssteuerung und können auf unterschiedlichen Wegen erhoben werden. Das Fallbeispiel beschränkt sich auf die Betrachtung der Datenerhebung entlang der Verkehrsinfrastruktur durch Sensoren. Zwei unterschiedliche Arten von Sensoren kommen hierbei im Straßenverkehr zum Einsatz:

80


1. Induktionsschleifen Sensoren in Form von Induktionsschleifen sind in die Fahrbahn eingelassen und emittieren Daten, sobald Fahrzeuge die Schleife passieren, und stellen so kontinuierlich Verkehrsdaten in Echtzeit zur Verfügung. Abhängig vom Typ eines Sensors können die emittierten Daten unterschiedliche Verkehrsmesswerte enthalten, z.B. die Anzahl Fahrzeuge oder die Geschwindigkeit. 2. Kontrollsignalsensoren Weitere Sensoren im Umfeld des Verkehrsnetzes stellen zusätzliche Messdaten zur Verfügung, die nicht direkt den Verkehrsfluss betreffen. Dies sind beispielsweise Daten von Verkehrsampeln, Wetterstationen, Notruftelefonen, Mauterfassungsgeräten usw.

Sensor 2378

Sektion 12 Von Messegelände bis Hannover-Zentrum

Hannover Messegelände

Sensor 2373

B6 Sektion 11 Von Autobahn 37 bis Messegelände

A37

Abb. 3.13 Beispiel für die Positionen von Sensoren in Straßenabschnitten

Die Abbildung 3.13 zeigt exemplarisch die Einteilung einer Straße in benachbarte Abschnitte sowie die Positionen von Sensoren in diesen Straßenabschnitten. Die von den Sensoren emittierten Daten können als Ereignisse aufgefasst werden. Die Sensoren liefern somit eine große Menge von Ereignissen, die verarbeitet werden müssen, um die aktuelle Verkehrssituation zu analysieren und, wenn notwendig, rechtzeitig geeignete Steuerungsmaßnahmen veranlassen zu können. Wie solche Maßnahmen aussehen können, zeigt bereits die Tabelle 3.3 durch die Zuordnung von Verkehrssituationen zu möglichen Steuerungsaktionen. Es gibt einige besondere Schlüsselanforderungen, mit denen sensorbasierte Verkehrsmanagementsysteme fertig werden müssen [86]: • Sehr große Datenmengen Aufgrund der großen Anzahl von Sensoren in einem Straßennetz und der enormen Anzahl von Verkehrsmitteln, die sich kontinuierlich auf diesem Straßennetz bewegen, entsteht ein riesiges Volumen an Verkehrsdaten. Hinzu kommen noch die Umfelddaten, die ebenfalls in sehr großen Mengen zur Verfügung stehen können.


81

• Feingranulare Daten Die durch einen Sensor emittierten Daten enthalten normalerweise nur wenige, zumeist sehr abstrakte technische Informationen (z.B. Sensor-ID, Zeitstempel, Messwert). Benötigt werden allerdings qualitative Daten auf einer höheren Abstraktionsstufe. Erst durch die Korrelation und Interpretation werden aus den Sensordaten numerische Verkehrsdaten, z.B. Verkehrsdichte oder durchschnittliche Geschwindigkeit in einem Straßenabschnitt und hieraus wiederum qualitative Verkehrs- bzw. Problemdaten, z.B. Unfall- oder Stauereignisse. • Unkorrelierte Daten Verkehrskontrollsysteme sind nicht an einem singulären Sensordatum interessiert, stattdessen an zeitlich oder räumlich korrelierten Ereignissen. Zum Beispiel müssen die Daten aller Sensoren in einem Straßenabschnitt korreliert werden, um die durchschnittliche Verkehrsdichte und -stärke zu ermitteln. In einem nachgelagerten Verarbeitungsschritt dienen die berechneten Verkehrskennzahlen dazu, entstehende Verkehrsprobleme wie Staus oder Unfälle zu diagnostizieren. • Kontinuierlicher Datenstrom Sensorbasierte Systeme sehen sich einem Strom von kontinuierlich eintreffenden Daten ausgesetzt. Folglich müssen diese Daten auch kontinuierlich verarbeitet werden, eine retrospektive Analyse der Daten ist für die aktive Steuerung der Verkehrsflüsse nicht sinnvoll. • Kurze Latenzzeit Ein Schlüsselfaktor für Verkehrsmanagement ist eine kurze Latenzzeit. Trotz ihrer enorm großen Menge müssen Sensordaten in Echtzeit verarbeitet werden. Die Lücke zwischen dem Zeitpunkt, an dem ein Sensor Daten emittiert, und der Zeit, zu der die Analyseergebnisse verfügbar sind, muss so kurz wie nur irgend möglich sein, um sofort auf Verkehrsstaus oder Unfälle reagieren zu können. Geeignete Systeme müssen eine Entscheidungsunterstützung in Echtzeit bieten oder ein “zero-latency“-Antwortverhalten aufweisen [44]. • Datenqualität Fehlende, falsche oder doppelte Lesungen der Sensoren aufgrund von technischen Problemen oder Umfeldeinflüssen können zu schwerwiegenden Inkonsistenzen in den übermittelten Daten führen. Diese Inkonsistenzen gilt es zu erkennen und zu beheben [59]. EDA für Verkehrskontrolle und -steuerung Der Problembereich der Verkehrskontrolle und -steuerung weist wesentliche charakteristische Eigenschaften und Anforderungen auf, die in Abschnitt 2.5 bzw. 2.5.2 für potenzielle EDA-Anwendungsbereiche identifiziert werden. Demnach erscheint ein ereignisgesteuerter Lösungsansatz für diesen Problembereich als aussichtsreich. Intelligente Verkehrssteuerungssysteme beruhen auf einem großen Netzwerk von heterogenen Sensoren und müssen aus dem kontinuierlichen Strom von feingranularen Sensordaten (= Ereignisstrom) sowohl zeitliche als auch räumliche Beziehungen und Muster zwischen den Verkehrsdaten erkennen, hieraus qualitative Verkehrsdaten generieren und bei Bedarf geeignete Steuerungsaktionen einleiten.

82


In Anlehnung an Abbildung 2.11 zeigt die Abbildung 3.14, wie die komplexe Ereignisverarbeitung als zentrale Komponente in einem Verkehrskontroll- und -steuerungssystem eingesetzt werden kann. Muster über Ereignisströme Sensor 1 Complex Event Processing Sensor 2

ITInfrastruktur EDA

Sensor 3

Abb. 3.14 Korrelation und Aufbereitung von Daten zur Verkehrskontrolle und -steuerung

Erste Ansätze und Erfahrungen bei der Anwendung von Complex Event Processing für Sensornetzwerke in der Verkehrssteuerung liegen bereits vor [23, 27, 86]. In den nachfolgenden Kapiteln werden die eingeführten Konzepte der Ereignisverarbeitung jeweils anhand dieses Fallbeispiels verdeutlicht.

Teil II

Complex Event Processing – Konzepte

Teil II – Complex Event Processing – Konzepte vertieft die konzeptionellen Inhalte aus Teil I systematisch, indem Complex Event Processing als die zentrale Technologie einer Event-Driven Architecture ausführlich und detailliert vorgestellt wird. Die Repräsentation von Ereignissen durch Ereignismodelle, die Verarbeitung von Ereignissen mittels Ereignismustern und -regeln, der Aufbau einer CEP-Anwendung als Netzwerk von interagierenden, ereignisverarbeitenden Komponenten sowie die Behandlung der Ereignisse in den nachgelagerten Anwendungssystemen werden Schritt für Schritt erläutert. Die konkrete technische Umsetzung der präsentierten Konzepte wird einerseits anhand einer vereinfachten Regelsprache für die Ereignisverarbeitung, andererseits anhand der Open-Source-CEP-Engine Esper vorgestellt. Ein durchgehendes Fallbeispiel aus dem Bereich Verkehrskontrolle und -steuerung verdeutlicht exemplarisch, wie die vorgestellten Konzepte in einem größeren fachlichen Zusammenhang eingesetzt werden. Kapitel 4 – Ereignismodelle betrachtet das zentrale Konzept der Ereignisse im Detail. Abstraktion, Eigenschaften, Beziehungen, Hierarchien und Modellierung von Ereignissen werden behandelt, aus denen dann das Ereignismodell als Grundlage einer EDA-Anwendung resultiert. Durch den Einsatz der UML lassen sich die Ereignismodelle graphisch anschaulich beschreiben. Beispielhaft wird ein Ereignismodell für die Fallstudie entwickelt. Kapitel 5 – Ereignisverarbeitung befasst sich mit der Verarbeitung von Ereignissen durch Ereignismuster und -regeln. Anhand einer einfachen Pseudosprache sowie am Beispiel der konkreten Event Processing Language von Esper werden die wichtigsten Sprachkonstrukte für die Ereignisverarbeitung eingeführt. Event Processing Agents und Event Processing Networks sind wichtige Konzepte zur Entwicklung von EDA-Anwendungen, diese werden vorgestellt und auf das Fallbeispiel angewendet. Da unterschiedliche Typen von Ereignisverarbeitungssprachen existieren, werden diese Typen erläutert und konzeptionell verglichen. Kapitel 6 – Ereignisbehandlung beschreibt, wie erkannte Ereignismuster in den nachgelagerten operativen Anwendungssystemen behandelt werden. Hierzu werden die Aufgaben der Ereignisbehandlung von der Verarbeitung abgegrenzt und eine Integrationsarchitektur entworfen. Besondere Beachtung erfährt die Behandlung von Ereignissen in Geschäftsprozessen sowie die Visualisierung von Ereignissen. In der Fallstudie sind Verkehrsleitsysteme für die Behandlung der Verkehrsereignisse verantwortlich.

Kapitel 4

Ereignismodelle

Zusammenfassung Ereignisse sind das zentrale Konzept und die Basis einer Event-Driven Architecture. In diesem Kapitel werden die grundlegenden Eigenschaften und Konzepte von Ereignissen vorgestellt. Die Mächtigkeit der Abstraktion als eine der Schlüsseleigenschaften von CEP wird herausgearbeitet. Insbesondere wird gezeigt, welche unterschiedlichen Beziehungen und Hierarchien zwischen Ereignissen bestehen können. Ein besonderer Schwerpunkt dieses Kapitels ist die Erstellung von Ereignismodellen. Mithilfe der UML lassen sich graphische Ereignismodelle und Ereignis-Constraints beschreiben. Abschließend wird ein detailliertes Ereignismodell für die Fallstudie des Verkehrskontrollsystems entwickelt.

4.1 Ereignisse und Ereignisströme Ereignisse sind die zentralen datentragenden Informationseinheiten, die in einer Event-Driven Architecture verarbeitet werden. Unter einem Ereignis kann man ein beliebiges Vorkommnis verstehen, das sich zu einem bestimmten Zeitpunkt ereignet und in der fachlichen Domäne relevant ist [68]. Abstraktionsebenen von Ereignissen Die Ursachen, die Ereignisse auslösen, können sehr unterschiedlich sein und zu Ereignissen auf ganz verschiedenartigen Abstraktionsebenen führen. • Physikalisch/technische Ereignisse Physikalische oder technische Ereignisse beruhen auf der Beobachtung physikalischer Vorkommnisse. Sie enthalten in der Regel feingranulare Daten, die meist in großer Menge kontinuierlich und hochfrequent erzeugt werden. Häufig wird in diesem Zusammenhang von Randereignissen (events on the edge) gesprochen [93]. In der Regel müssen technische Ereignisse korreliert, d.h. zueinander in Zusammenhang gesetzt werden, um eine signifikante fachliche Be-


85

86

4 Ereignismodelle

deutung abzuleiten. Ein einzelnes Ereignis besitzt keine oder nur sehr begrenzte Aussagekraft. • Anwendungs- oder Geschäftsereignisse Anwendungs- oder Geschäftsereignisse spiegeln einen fachlichen Sachverhalt wider und werden durch die Unternehmensanwendungssysteme ausgelöst. Eine Unternehmensanwendung erzeugt ein Geschäftsereignis aufgrund einer bestimmten Datenkonstellation bzw. eines IT-internen Vorkommnisses, beispielsweise durch den Eingang einer Bestellung, die Änderung eines Datensatzes oder die Eingabe eines menschlichen Benutzers. Meist beschreiben Geschäftsereignisse Vorkommnisse auf einer höheren Abstraktionsebene als die der technischen Ereignisse und sind im fachlichen Anwendungskontext bedeutsamer. Ereignisse repräsentieren demnach bereits aufgrund ihres Ursprungs Informationen auf sehr unterschiedlichen Abstraktionsebenen. Darüber hinaus ist eine Schlüsseleigenschaft des Complex Event Processing (CEP), dass durch die Analyse der aufgetretenen Ereignisse neue Ereignisse auf einem höheren Abstraktionsniveau erzeugt werden können, d.h. die dort gewonnenen Erkenntnisse auch zu neuen Ereignissen führen. Ein Ereignis ist eine Abstraktion (abstraction) einer Menge von (einfachen) Ereignissen, wenn es diese Menge von Ereignissen zusammenfasst, repräsentiert oder aus ihnen eine fachliche Bedeutung ableitet [68]. Die enorme fachliche Relevanz und die Mächtigkeit des Konzepts der Abstraktion für das Verständnis von Geschäfts- und Systemzusammenhängen wird ausführlich in Abschnitt 2.1.3 diskutiert. Die Abbildung 4.1 zeigt beispielhaft drei verschiedene Betrachtungsebenen, die sich aufgrund der Abstraktion von Ereignissen ergeben. Die Abstraktionsebenen stellen unterschiedliche Sichten auf die Ereignismenge dar.

Abstraktionsgrad

komplexe Ereignisse

mittlere Ereignisse

einfache Ereignisse

Abb. 4.1 Abstraktion von Ereignissen über mehrere Ebenen

4.1 Ereignisse und Ereignisströme

87

Auf der untersten Ebene finden sich normalerweise die physikalischen oder technischen Ereignisse, wie sie z.B. durch Sensornetzwerke in Verkehrskontrollsystemen erzeugt werden. Auf den nächsthöheren Ebenen tragen die Ereignisse bereits eine fachliche Bedeutung, so dass von Anwendungs-, Geschäfts- oder Prozessereignissen gesprochen werden kann. Der Abstraktionsschritt erzeugt neue Ereignisse einer höheren Abstraktionsstufe aufgrund eines erkannten Beziehungsmusters und ist in der Abbildung durch die Pfeile angedeutet. Dabei reduziert sich in der Regel die Anzahl Ereignisse pro Abstraktionsstufe, während deren Informationsgehalt bzw. Informationswert zunimmt. Die konkrete Anzahl an Abstraktionsstufen für ein Anwendungsgebiet ist spezifisch für das jeweilige Gebiet und die betrachteten Fragestellungen. Charakterisierung von Ereignissen Genauso vielfältig wie die vielen verschiedenen Anwendungsdomänen sind auch die unterschiedlichen Arten von möglichen Ereignissen (die sogenannten Ereignistypen, siehe unten). Beispiele für Ereignisse sind eine Finanztransaktion, der Ausfall eines Servers, der Klick auf einen Web-Link, eine Zustandsänderung in einer Datenbanktabelle, die gemessene Niederschlagsmenge an einem Messpunkt oder die von einem Sensor gelesenen Daten. Um ein Ereignis verstehen, einordnen und weiterverarbeiten zu können, muss es sämtliche Informationen, die für die weiteren Verarbeitungsvorgänge erforderlich sind, als Ereignisdaten mit sich führen. Die Ereignisdaten beschreiben den Kontext bzw. das Umfeld, in dem das Ereignis aufgetreten ist, und bestehen aus allgemeinen Metadaten und spezifischen Kontextdaten. Die Vollständigkeit der Informationen ist notwendig, damit nicht während der Verarbeitung ständig zusätzliche Daten aus den Anwendungssystemen beschafft werden müssen.1 • Metadaten Zunächst muss jedes Ereignis allgemeine domänenunabhängige Metadaten beinhalten. Jedes Ereignis benötigt eine eindeutige Ereignis-ID, um es von anderen Ereignissen zweifelsfrei unterscheiden zu können, und einen Auftrittszeitpunkt (occurrence time) oder Zeitstempel (timestamp), der den Zeitpunkt des Auftretens des Ereignisses repräsentiert. Darüber hinaus ist es in vielen Fällen hilfreich, wenn jedes Ereignis weitere Informationen über die Ereignisquelle und den Ereignistyp enthält. • Ereigniskontext Darüber hinaus muss jedes Ereignis auch alle ereignisspezifischen Daten enthalten. Diese beschreiben den Kontext, in dem das Ereignis aufgetreten ist, und werden für die Ereignisverarbeitung benötigt. Beispielsweise enthält ein Finanztransaktionsereignis u.a. die Wertpapierkennnummer, den Transaktionstyp (Kauf/Verkauf) und die Anzahl der zu handelnden Wertpapiere.

1

Vergleiche auch die Diskussion zu dieser Problematik in den Abschnitten 3.1 und 7.3.3.

88

4 Ereignismodelle

Wird ein Ereignis durch eine Menge anderer Ereignisse verursacht, so können ihm auch diese Ereignisse als Daten hinzugefügt werden.2 Dadurch lässt sich der Ursprung eines Ereignisses leicht zurückverfolgen. • Zeitaspekte Der Einfachheit halber wird meistens angenommen, dass ein Ereignis keine zeitliche Dauer hat, also zeitlos ist, und sein Zeitverhalten durch den Auftrittszeitpunkt vollständig beschrieben ist. Sollen länger andauernde Vorgänge durch Ereignisse repräsentiert werden (z.B. der Download einer Datei), so lässt sich dies durch zwei separate Ereignisse abbilden: ein Start- und ein Endereignis, die zueinander in Beziehung stehen, da sie sich auf denselben Vorgang beziehen. Ereignistypen und Ereignisinstanzen Genauso wie sich in der Objektorientierung die Konzepte Klasse und Objekt unterscheiden lassen, kann in der Ereignisverarbeitung zwischen Ereignistypen und Ereignisinstanzen differenziert werden (siehe Abbildung 4.2). FlugbuchungsEreignis ID: Integer timestamp: Integer flugnummer: String abflug: String ziel: String datum: Date abflugzeit: Time

buchung1: FlugbuchungsEreignis ID=4711 timestamp=12641230999 flugnummer=LH1234 abflug=Hannover ziel=Madrid datum=12.7.2010 abflugzeit=08:30

buchung2: FlugbuchungsEreignis ID=8723 timestamp=12641231001 flugnummer=IB452 abflug=Barcelona ziel=Berlin datum=3.8.2010 abflugzeit=18:15

Ereignistyp

Ereignisinstanzen

Abb. 4.2 Ereignistypen und -instanzen

Ereignistyp Ein Ereignistyp (event type, event class) spezifiziert die grundlegenden Eigenschaften einer ganzen Klasse von gleichartigen Ereignissen [68]. Ein Ereignistyp definiert insbesondere die Attribute (event properties) einer Klasse von Ereignissen, so dass alle Ereignisse eines bestimmten Typs dieselbe Struktur der in ihnen enthaltenen Daten besitzen.

2

In [63] wird von einem kausalen Vektor (causal vector) gesprochen.

4.1 Ereignisse und Ereignisströme

89

So kann beispielsweise festgelegt werden, dass Ereignisse vom Typ Flugbuchung eine eindeutige Identifikationsnummer (ID), einen Zeitstempel, eine Flugnummer, einen Abflug- und Zielflughafen sowie Abflugdatum und -zeit enthalten. Ereignisinstanz bzw. Ereignisobjekt Eine Ereignisinstanz (event instance) bzw. ein Ereignisobjekt (event object) beschreibt ein konkretes Vorkommnis mit seinen allgemeinen und spezifischen Daten [117], d.h. es repräsentiert eine Ausprägung eines Ereignistyps. Bezogen auf das Beispiel in Abbildung 4.2 besitzt eine Ereignisinstanz die entsprechenden Daten für eine konkrete Flugbuchung (z.B. ID = 4711, Timestamp = 12641230999, Flugnummer = LH1234, Abflug = Hannover, Ziel = Madrid, Abflugzeit = 12. Juli 2010 um 8:30 Uhr). Häufig wird nicht präzise zwischen Ereignistypen und Ereignisinstanzen bzw. -Objekten unterschieden, sondern einfach der Begriff Ereignis verwendet. Auch in diesem Buch wird der Einfachheit halber von Ereignissen gesprochen, wenn der Bezug klar ist.3 Datenformate Die Ereignisinstanzen werden durch die Ereignisquellen erzeugt und in einem spezifischen Format aufbereitet und bereitgestellt. Beispielsweise erzeugen die Sensoren in einem Verkehrskontrollsystem fortlaufend Ereignisse in Form von technischen Datensätzen, die die gemessenen Verkehrsdaten enthalten. Die Sensoren verwenden dabei ein proprietäres technisches Datenformat. So können Ereignisinstanzen u.a. in Form von XML-Datensätzen, als CSV-Werte (Comma-Separated Values) oder als Key-Value-Paare dargestellt und verschickt werden. Sind Anwendungssysteme für die Ereigniserzeugung verantwortlich, so erzeugen sie häufig direkt eine Objektinstanz, also z.B. ein Java-Objekt, das unmittelbar weiterverarbeitet werden kann. Zurzeit existiert noch kein technisches Standardformat zum Austausch von Ereignisinstanzen. Entsprechende Adapterkomponenten müssen die gelesenen Ereignisse also zunächst in ein internes Verarbeitungsformat transformieren, das dann weiterverarbeitet werden kann (siehe Abbildung 3.6). Ereignisströme Ereignisgesteuerte Systeme sind dadurch gekennzeichnet, dass kontinuierlich neue Ereignisinstanzen unterschiedlicher Ereignistypen aus verschiedenen Quellen in die Ereignisverarbeitung einfließen (siehe Abbildung 4.3). Diese Flüsse von Ereignissen werden als Ereignisströme (event streams) bezeichnet, die weiterverarbeitet 3

Zwischen den Bezeichnungen Ereignisinstanz und Ereignisobjekt wird in diesem Buch nicht differenziert, die beiden Begriffe werden als synonym betrachtet. Ereignisinstanz betont mehr den Aspekt der Ausprägung eines Ereignistyps, während Ereignisobjekt eher die Repräsentation eines Ereignisses im IT-System hervorhebt.

90

4 Ereignismodelle

werden müssen (event stream processing). Ein Ereignisstrom ist eine linear geord-


Abb. 4.3 Ereignisstrom mit mehreren Quellen und Instanzen unterschiedlicher Typen

nete Folge von Ereignisinstanzen. In der Regel sind die Ereignisse entsprechend ihrer Auftrittszeit geordnet, denn die zeitliche Reihenfolge von Ereignissen ist oft für ihre weitere Verarbeitung von entscheidender Bedeutung. Beispielsweise werden bei Ereignissen, die den aktuellen Kurs eines bestimmten Wertpapiers anzeigen, zwei aufeinanderfolgende Ereignisse in Abhängigkeit von ihrer Reihenfolge als Kurssteigerung oder Kursabfall interpretiert. Es ist nicht immer garantiert, dass der Strom der an einer CEP-Komponente eintreffenden Ereignisse auch ihrer tatsächlichen Auftrittsreihenfolge entspricht: 1. Aufgrund unterschiedlicher Übertragungsdauern zwischen Ereignisquellen und CEP-Komponente kann sich die Reihenfolge der dort eintreffenden Ereignisse von der tatsächlichen Auftrittsreihenfolge unterscheiden. 2. Den Auftrittszeitpunkt eines Ereignisses bestimmt in der Regel die Ereignisquelle. Damit die in den unterschiedlichen Quellen zugeordneten Zeitpunkte auch die Wirklichkeit abbilden, ist es notwendig, die von ihnen verwendeten Uhren entsprechend zu synchronisieren [62]. Vom jeweiligen Anwendungsfall hängt es ab, wie wichtig es ist, dass der ankommende Ereignisstrom die Wirklichkeit exakt abbildet, und wie viel Aufwand gerechtfertigt ist, um dies zu erreichen. In der Praxis ist es meist ausreichend, den Ankunftszeitpunkt in der CEP-Komponente als Ordnungskriterium für Ereignisströme zu verwenden. In komplexen Anwendungsfällen müssen im Normalfall nicht nur ein, sondern mehrere Ereignisströme gleichzeitig verarbeitet werden. Wenn in einer Ereignismenge keine vollständige, sondern nur eine teilweise Ordnung (partial ordering) zwischen den Ereignissen vorliegt, wird auch von einer Ereigniswolke (event cloud) gesprochen [63, 68]. Ereignisströme sind naturgemäß unbegrenzt, d.h., der Strom der Ereignisse reißt nie ab, so dass eine theoretisch unbegrenzte Anzahl von Ereignissen erzeugt wird. Weil die nachgelagerten CEP-Komponenten nicht eine unendlich große Menge von Ereignissen verarbeiten können, werden nur diejenigen Ereignisse betrachtet, die in einem bestimmten Zeit- oder Längenfenster stattgefunden haben (siehe Kapitel 5).

4.2 Ereignisbeziehungen und -hierarchien

91

4.2 Ereignisbeziehungen und -hierarchien Ein einzelnes Ereignis besitzt häufig keine besonders hohe Aussagekraft, sondern gewinnt erst im Kontext mit anderen Ereignissen an Bedeutung. Um den Zustand eines ereignisorientierten Systems in seiner Gesamtheit verstehen zu können, sind Einzelereignisse in der Regel zu feingranular und müssen deshalb zu anderen Ereignissen in Beziehung gesetzt werden. Zum Beispiel lassen sich aus der Information, dass ein einzelnes Auto gerade den Sensor in einem Verkehrsleitsystem passiert hat, offensichtlich keine Erkenntnisse über den aktuellen Verkehrszustand ableiten. Nur wenn eine Vielzahl von Verkehrsereignissen in Zusammenhang gesetzt und diese insgesamt betrachtet werden, ist eine qualitative Beurteilung der Verkehrslage möglich. Beziehungen zwischen Ereignissen Beziehungen zwischen Ereignissen Ereignisse stehen zueinander in Beziehung (relationship), und zwar in zeitlichen, kausalen, Abstraktions- und anderen anwendungsspezifischen Beziehungen. Zeit und Kausalität führen zu einer partiellen Ordnung der Ereignisse [68]. Die unterschiedlichen Abhängigkeiten und Wechselwirkungen zwischen Ereignissen können anhand der folgenden Kriterien klassifiziert werden [68]. Zeitliche oder temporale Zusammenhänge Ereignis A ereignet sich vor Ereignis B. Ereignisbeziehungen sind oft durch zeitliche Abhängigkeiten charakterisiert. Zum Beispiel wird in einem Verkehrsmanagementsystem der zeitliche Verlauf von Verkehrsdaten betrachtet. Tritt an einem Sensor ein plötzlicher Geschwindigkeitsabfall auf, so kann dies auf ein Verkehrsproblem hinweisen. Ursächliche oder kausale Zusammenhänge Ereignis A verursacht Ereignis B, d.h., für ein Ereignis B ist das Auftreten eines Ereignisses A eine notwendige Bedingung. Beispielsweise wird im Szenario eines Internet-Shops das “Auslieferungsereignis“ für eine Ware durch ein entsprechendes “Bestellereignis“ verursacht. Ein besonders starker kausaler Zusammenhang liegt bei den sogenannten abgeleiteten Ereignissen (derived event) vor, die unmittelbar aus anderen Ereignissen entstanden sind. So kann zum Beispiel das Ereignis einer Unfallmeldung zu einem abgeleiteten Ereignis vom Typ “Verkehrsproblem“ führen. Fachliche Korrelationen Ereignisse können einander aufgrund fachlicher Zusammenhänge zugeordnet werden. Beispielsweise sind alle Geldtransaktionen, die mit derselben Kreditkarte durchgeführt werden, miteinander verbunden. Dieser Zusammenhang ist in Abbildung 4.4 durch die grauen Ereignisse und die gestrichelte Beziehung dargestellt. Ein weiteres Beispiel für eine fachliche Beziehung ist der Zusammenhang zwischen dem Start- und dem Endereignis für einen Vorgang mit zeitlicher Dauer.

92

4 Ereignismodelle

MasterCard 47112234 543,50 € Lufthansa xyz..

xyz..

Visa 909806762 1245,00 € Hilton

xyz..

xyz..

Visa 9873123787 265,00 € Avis

MasterCard 47112234 232,00 € Metro

MasterCard 47112234 520,00 € Hertz

AmericanExpress 9873123787 265,00 € Avis xyz..

xyz..

xyz..

xyz..

Abb. 4.4 Fachliche Korrelation von Ereignissen am Beispiel von Kreditkartentransaktionen

Wenn z.B. der Transport einer Ware durch zwei Ereignisse (Warenauslieferung und -eingang) repräsentiert wird, stehen diese beiden Ereignisse in einem unmittelbaren fachlichen Zusammenhang, da sie sich auf denselben Transportvorgang beziehen. Dieser Zusammenhang muss aus den Kontextdaten ersichtlich sein, die die Ereignisse mit sich führen. Aggregation von Ereignissen (composite events) Ein Ereignis A ist eine Aggregation (oder Gruppierung) der Ereignisse Bi , wenn alle Bi Teile von A sind oder die Daten der Einzelereignisse durch entsprechende Operationen zusammengefasst werden. Ein aggregiertes Ereignis stellt eine Abstraktion der Einzelereignisse dar. Die durch eine Aggregation zusammengefassten Einzelereignisse besitzen eine verbindende Eigenschaft: Zum Beispiel entstammen sie derselben Ereignisquelle oder besitzen gemeinsame anwendungsspezifische Attribute.4 So können einzelne Verkehrsereignisse, die an einem Sensor in einem Verkehrsmanagementsystem gemessen werden, zu einem Ereignis, das Durchschnittsverkehrsdaten liefert, zusammengefasst werden (siehe Abbildung 4.5).5

einfache Ereignisse

aggregiertes Ereignis

Abb. 4.5 Aggregation von Ereignissen

Komplexe Ereignisse (complex events) Die CEP-Komponente erzeugt ein komplexes Ereignis, wenn sie ein Beziehungsmuster im Ereignisstrom erkennt. Komple-

4

Zum Beispiel ist dies dieselbe Wertpapierkennnummer bei Kursereignissen oder dieselbe Kontonummer bei Geldtransaktionen. 5 In [68] wird sogar gefordert, dass aggregierte Ereignisse stets alle Einzelereignisse (members) enthalten.

4.2 Ereignisbeziehungen und -hierarchien

93

xe Ereignisse können deshalb ebenfalls als Abstraktion einfacher Ereignisse aufgefasst werden (siehe Abbildung 4.6).

komplexe Ereignisse

Abstraktion

einfache Ereignisse

Abb. 4.6 Erzeugung komplexer Ereignisse durch Abstraktion einfacher Ereignisse (nach [63], S. 57)

Im Gegensatz zu aggregierten Ereignissen fasst ein komplexes Ereignis nicht nur einfach Einzelereignisse zusammen, sondern zieht mithilfe intelligenter Regeln neue Rückschlüsse und Erkenntnisse aus den vorhandenen Ereignissen.6 Komplexe Ereignisse lassen sich gegen einfache atomare Ereignisse (atomic oder raw events) abgrenzen, die als feingranulare Ereignisse unmittelbar in der Realität auftreten. Ein Beispiel liefert ein System zum Wertpapierhandel: Einfache Kursänderungsereignisse werden auf ein komplexes, aus vielen Einzelereignissen abgeleitetes Kauf- oder Verkaufsereignis abgebildet. Diese Ableitung bzw. Folgerung (inference) beinhaltet umfangreiches Expertenwissen, in diesem Fall aus der technischen Aktienanalyse. In der Erzeugung von komplexen Ereignissen liegt die eigentliche Stärke einer CEP-Komponente, denn diese berücksichtigt die Wechselwirkungen und Abhängigkeiten der aufgetretenen Ereignisse. Komplexe Ereignisse bieten letztendlich das, was mit CEP erreicht werden soll: das fachliche Verständnis eines kontinuierlichen Stroms feingranularer Ereignisse. Komplexe Ereignisse bieten zudem ein probates Mittel der Abstraktion, durch das sich Ereignisse auf unterschiedlichen Abstraktionsebenen verarbeiten lassen (siehe oben und in Abschnitt 2.1.3). 1. Einerseits abstrahieren komplexe Ereignisse von den Detaildaten der zugrunde liegenden einfachen Ereignisse. 2. Andererseits lassen sich komplexe Ereignisse als Resultat eines bestimmten Ereignismusters, dessen genaue Einzelheiten im Folgenden nicht mehr einbezogen werden müssen, verstehen. Die hier genannten Beziehungstypen sind nicht immer eindeutig voneinander abgrenzbar, oft liegen auch Mischformen vor. 6

Im Gegensatz zu aggregierten Ereignissen enthalten komplexe Ereignisse nicht unbedingt die zugeordneten Einzelereignisse.

94

4 Ereignismodelle

Ereignishierarchien Die in einer Event-Driven Architecture betrachteten Ereignistypen bilden normalerweise Hierarchien. Analog zum Konzept der Vererbung in der Objektorientierung lassen sich neue Ereignistypen als Spezialisierung, d.h. als ein Untertyp von vorhandenen Ereignistypen, definieren. Ereignishierarchie Durch Generalisierung und Spezialisierung entsteht eine hierarchische Beziehung zwischen Ereignistypen. Die datentragenden Attribute eines Obertyps werden hierbei von dessen Untertypen übernommen. Wiederum analog zur Objektorientierung gibt es auch abstrakte Ereignistypen, für die keine Ereignisinstanzen existieren. Sie dienen der Strukturierung der Ereignishierarchie und definieren die gemeinsamen Attribute mehrerer Ereignistypen. Im Gegensatz zu den abstrakten Ereignistypen besitzen die konkreten Ereignistypen Ereignisinstanzen. Abbildung 4.7 zeigt ein einfaches Beispiel.7 AbstractEvent eventID timestamp

Wertpapiertransaktion wertpapiernummer anzahl börsenplatz

Kauf kaufpreis

Verkauf verkaufspreis

Abb. 4.7 Ereignishierarchie mit Ober- und Untertypen

Der abstrakte Ereignistyp AbstractEvent definiert für alle abgeleiteten Ereignistypen eine ID und einen Zeitstempel als Metadaten. Offensichtlich gibt es keine Instanzen für diesen Ereignistyp, da dieser Typ keinerlei Informationen über den Ereigniskontext enthält. Der ebenfalls abstrakte Ereignistyp Wertpapiertransaktion besitzt drei weitere Attribute und zwei spezialisierte Ereignisuntertypen: Kauf und Verkauf. Eine Ereignisinstanz vom Typ Kauf besitzt demnach die datentragenden Attribute eventID, timestamp, wertpapiernummer, anzahl, börsenplatz und kaufpreis. Mit geeigneten Ereignishierarchen lassen sich auch Ereignismuster (siehe Kapitel 5) einfacher formulieren: Regeln, die für einen Ereignisobertyp definiert sind, 7 Abstrakte Ereignistypen sind in einer Ereignishierarchie durch einen kursiven Typnamen gekennzeichnet.

4.3 Modelle

95

beziehen sich auch automatisch auf alle definierten Untertypen. In unserem Beispiel könnte eine Regel, die den Umsatz für ein bestimmtes Wertpapier bestimmen soll, mithilfe des Ereignistyps Wertpapiertransaktion formuliert werden: Die Regel bezieht sich in diesem Fall sowohl auf Kauf- als auch auf VerkaufEreignisse.

4.3 Modelle Weil Ereignisse das zentrale Konzept einer EDA sind, ist es sinnvoll, sie mithilfe eines Ereignismodells präzise und formal zu definieren [24].8 Ein Ereignismodell soll das vollständige Wissen über die im System auftretenden Ereignisse beschreiben. Obwohl Ereignisse in EDA-Systemen von entscheidender Bedeutung sind, gibt es überraschenderweise in den meisten existierenden Systemen keine präzise definierten Ereignismodelle [95]. Ereignismodell Ein Ereignismodell (event model) definiert alle verwendeten Ereignistypen mit deren Attributen, Eigenschaften, hierarchischen Abhängigkeiten und Beziehungen auf den verschiedenen Abstraktionsebenen. Darüber hinaus werden in dem Modell auch die weiteren Einschränkungen für Ereignisinstanzen in Form von Constraints spezifiziert (s.u.). Im Ereignismodell sind also die strukturellen Eigenschaften der Ereignisse spezifiziert, die von ihrer weiteren Verarbeitung unabhängig sind. Deshalb enthält das Ereignismodell auch keinerlei Verarbeitungslogik. Verantwortlich für die Ereignisverarbeitung sind die CEP-Komponenten in der Verarbeitungsschicht (siehe Abschnitt 3.1.3). In ihnen sind entsprechende Verarbeitungsregeln definiert, um Muster in den Ereignisströmen zu finden und passende Aktionen anzustoßen (siehe Kapitel 5). Die Regeln sind auf Basis des Ereignismodells definiert, d.h., die Regeln verwenden ausschließlich im Ereignismodell definierte Ereignistypen und verletzen nicht die dort definierten Einschränkungen und Festlegungen. Die Abbildung 4.8 zeigt den Zusammenhang zwischen dem Ereignismodell und der Ereignisverarbeitung. Dieser Ansatz entkoppelt die Definition der vorliegenden Ereignisstrukturen von der Ereignisverarbeitung und führt damit zu einer verbesserten Systemarchitektur. Insbesondere ist dabei zu beachten, dass die strukturellen Eigenschaften der Ereignisse meist sehr stabil und nur in seltenen Fällen Änderungen unterworfen sind. Die Verarbeitungsregeln werden hingegen regelmäßig geändert und angepasst, um die Ereignisverarbeitung zu optimieren.

8

Ähnlich wie ein Datenmodell die zentrale Grundlage für ein Informationssystem bildet oder ein UML-Klassendiagramm die Basis für eine objektorientierte Software ist.

96

4 Ereignismodelle Ereignisverarbeitung (CEP)

Ereignisinstanzen

Ereignisinstanzen


Ereignisregeln

Regel

Regel

Regel

Ereignistyp

Ereignistyp Constraint



Ereignismodell

Abb. 4.8 Zusammenspiel von Ereignismodell und Ereignisverarbeitung

Spezifikation von Ereignismodellen mit UML Zur formalen Beschreibung von Ereignismodellen existieren derzeit keine spezifischen Standards. Aufgrund der Ähnlichkeit zwischen Objektklassen und Ereignistypen ist es aber naheliegend, die UML (Unified Modeling Language) [81] auch für die Spezifikation von Ereignismodellen einzusetzen. Ein Ereignistyp kann als Objektklasse mit entsprechenden Attributen, Referenzen und Hierarchien, aber ohne Methoden aufgefasst werden. Damit können Ereignismodelle durch UMLKlassendiagramme, wie bereits in Abbildung 4.7 gezeigt, dargestellt werden. Die Abbildung 4.9 zeigt die für die Modellierung benötigten Modellelemente. In den meisten praktischen Anwendungsfällen sind die Möglichkeiten der UML ausreichend, um aussagekräftige Ereignismodelle zu erstellen. Die graphische Darstellung von Ereignismodellen in UML-Diagrammen verschafft einen guten Überblick über die in einer EDA-Anwendung vorhandenen Ereignisse und deren Struktur. Um komplexere semantische Abhängigkeiten zwischen Ereignistypen zu formulieren, reicht die UML aber nicht mehr aus. Zum Beispiel lassen sich in der UML unterschiedliche Formen von Beziehungen nicht genauer charakterisieren. So könnte man zum Beispiel eine Beziehung namens wirdAusgelöstDurch als transitiv definieren, die ausdrückt, dass das Auftreten eines Ereignisses ein anderes Ereignis auslöst. Gilt für drei Ereignisse a, b und c: a wirdAusgelöstDurch b und b wirdAusgelöstDurch c, so folgt daraus, dass auch a wirdAusgelöstDurch c gilt. Um semantisch reichhaltige Modelle zu definieren, bedarf es entsprechender Ontologiesprachen, beispielsweise Sprachen aus dem Fachgebiet des Semantic Web [11], wie RDF [111], RDF-S [112] oder OWL [110]. Diese Ansätze sind Ge-

4.4 Ereignis-Constraints

97

Typname Attribut_1 Attribut_2

abstrakter Ereignistyp mit Attributen

Typname Attribut_1 Attribut_2

konkreter Ereignistyp mit Attributen

Typ_A

0..1

Typ_B

Typ_B Ereignistyp Typ_A ist eine Spezialisierung von Typ_B Typ_A

1 Instanz vom Typ_A steht zu 0 oder 1 Instanz vom Typ_B in Beziehung

Abb. 4.9 Modellelemente beim Einsatz von UML für Ereignismodelle

genstand der aktuellen Forschung und würden den Rahmen der Darstellung in diesem Buch sprengen. Der interessierte Leser sei auf die Literatur verwiesen, z.B. wird in [24] gezeigt, wie Ontologien in Ereignismodellen eingesetzt werden können.

4.4 Ereignis-Constraints Mit graphischen Modellen, wie z.B. UML-Klassendiagrammen, lässt sich die Struktur von Ereignismodellen gut beschreiben, also die gegebenen Ereignistypen, deren Attribute und Beziehungen. Um diese strukturelle Beschreibung weiter zu präzisieren, ist es in vielen Einsatzgebieten wünschenswert, Einschränkungen für die Modellelemente zu definieren. Zum Beispiel: • Beschränkung der zulässigen Werte der Attribute eines Ereignistyps So sollte beispielsweise die von einem Sensor gemessene Fahrzeuggeschwindigkeit sinnvollerweise im Intervall [0, 250] liegen. Gerade bei sensorbasierten Systemen können aufgrund technischer Probleme falsche oder inkonsistente Ereignisdaten generiert werden. Beispiele dafür sind Ausreißer (outlier) für bestimmte Messwerte. • Bedingungen für die Gleichheit zweier Ereignisse Oft werden bei sensorbasierten Ereignisquellen, beispielsweise bei RFID-Lesegeräten, Ereignisse mehrfach erzeugt (duplicate reads) oder real stattfindende Ereignisse werden nicht erkannt (missing reads) [59]. Solche zusätzlichen Bedingungen können in Form von Constraints als Metainformationen dem Ereignismodell hinzugefügt werden. Ereignis-Constraints Constraints definieren Einschränkungen in Form von Bedingungen, die sämtliche Ereignisinstanzen eines bestimmten Typs erfüllen müssen.

98

4 Ereignismodelle

Zur Definition von Constraints existieren spezielle Sprachen. In der Objektorientierung hat sich die Object Constraint Language (OCL) inzwischen als Standard etabliert [80]. Die OCL lässt sich auch für die Präzisierung von Ereignismodellen einsetzen. In OCL lassen sich Constraints in Form sogenannter Invarianten beschreiben, das sind Bedingungen in Form von booleschen Ausdrücken, die für alle Instanzen eines Ereignistyps gelten müssen. Das folgende Codebeispiel zeigt, wie ein Constraint in OCL definiert werden kann. 1 2

context StockEvent inv : 0 < stockValue

Für alle Ereignisse vom Typ StockEvent ist eine Invariante (inv) festgelegt (Zeile 1), nämlich, dass der Wert des Attributs stockValue immer größer als 0 sein muss. Das nachfolgende Beispiel definiert, wann zwei Ereignisinstanzen vom Typ RfidEvent identisch sind: Wenn zwei Ereignisse e1, e2 am selben Sensor erzeugt wurden, dieselbe Tag-ID besitzen und einen sehr nah beieinander liegenden Auftrittszeitpunkt haben (Zeilen 3-6) , dann werden sie als identisch (Dublette) aufgefasst (Zeile 7). 1 2 3 4 5 6 7 8

context RfidEvent inv : f o r A l l I n s t a n c e s ( e1 , e2 | ( e1 . s e n s o r I D == e2 . s e n s o r I D AND e1 . t a g I D == e2 . t a g I D AND ( e1 . t i m e −e2 . t i m e ) < 0 . 0 1 ) i m p l i e s e1 = e2 )

Durch die Definition von Constraints lässt sich sicherstellen, dass nur “sinnvolle“ bzw. konsistente Ereignisse betrachtet werden. Dabei gibt es verschiedene Möglichkeiten, wie mit den Ereignissen, die einen Constraint verletzen, umgegangen werden kann: 1. Entfernen In vielen Fällen werden alle inkonsistenten Ereignisinstanzen aus dem Ereignisstrom herausgefiltert, so dass ausschließlich sinnvolle Ereignisse weiterverarbeiten werden. 2. Korrigieren Alternativ können Ereignisse korrigiert werden, beispielsweise indem fehlerhafte Attribute auf Defaultwerte gesetzt werden. Dies ist insbesondere dann sinnvoll, wenn das Ereignis nicht verloren gehen soll, nur weil eines seiner vielen Attribute fehlerhaft ist.


99

Unter Umständen werden auch fehlende Ereignisse erzeugt. Fehlende Ereignisse können anhand kausaler Zusammenhänge erkannt werden: wenn ein aufgrund anderer Ereignisse erwartetes Ereignis nicht aufgetreten ist.9 3. Ignorieren Gegebenenfalls können die Constraints auch ignoriert werden, d.h., die fehlerhaften Ereignisse werden in der CEP-Komponente weiterverarbeitet. In diesem Fall handelt es sich um sogenannte Soft Constraints10 . Die verwendeten Regeln müssen fehlertolerant sein, d.h., sie dürfen keine falschen Rückschlüsse aufgrund fehlerhafter Ereignisse ziehen. Die Einhaltung von Constraints und die Behandlung inkonsistenter Ereignisse muss durch entsprechende Regeln bei der Ereignisverarbeitung sichergestellt werden. Somit muss aus jedem Constraint eine entsprechende Regel abgeleitet werden, die z.B. fehlerhafte Ereignisse aus dem Ereignisstrom entfernt oder die Ereignisse korrigiert.

4.5 Fallstudie: Verkehrskontrolle und -steuerung Dieser Abschnitt greift das in Abschnitt 3.4 eingeführte Anwendungsszenario auf und stellt ein mögliches Ereignismodell für ein System zur Verkehrskontrolle und -steuerung vor. Struktur des Ereignismodells

Abstraktionsgrad

Als Ausgangspunkt für das Ereignismodell steht die Überlegung, welche grundsätzlichen Ereignisse in einem Verkehrskontrollsystem vorkommen. Diese werden dann in den nachfolgenden Schritten sukzessiv weiter verfeinert.

Problem Events

qualitative Problemdaten

Traffic Events

numerische Verkehrsdaten

Sensor Events

Sensordaten

Abb. 4.10 Grundlegende Abstraktionsebenen von Ereignissen in einem Verkehrskontrollsystem 9

Beispielsweise wird ein “Wareneingang-Ereignis“ durch ein “Bestell-Ereignis“ ausgelöst. Im Gegensatz zu Hard Constraints, die garantiert immer eingehalten werden.

10

100

4 Ereignismodelle

Im Grundsatz kann ein Verkehrskontrollsystem als ein ereignisgesteuertes Softwaresystem aufgefasst werden, das feingranulare Sensorereignisse in komplexere Verkehrsereignisse mit mehr Bedeutung transformiert. Abbildung 4.10 gibt einen Überblick über den Abstraktionsprozess, der aus zwei Schritten besteht: Zunächst werden die Sensor Events, die die in das Straßennetz eingelassenen Sensoren erzeugen, in einen Strom von Traffic Events transformiert, die den aktuellen Zustand des Verkehrsgeschehens mit entsprechenden Kennzahlen repräsentieren. Im zweiten Abstraktionsschritt werden im Strom der Traffic Events Beziehungsmuster gesucht, die auf ein Verkehrsproblem hinweisen, beispielsweise einen plötzlichen Geschwindigkeitsabfall. In solchen Fällen wird ein entsprechendes Ereignis vom Typ Problem Event generiert. Für die Entwicklung eines Verkehrskontrollsystems auf Basis einer EDA müssen die einzelnen Ereignistypen detaillierter spezifiziert werden. Die Abbildung 4.11 zeigt einen Ausschnitt eines vereinfachten Ereignismodells im Überblick.11 Das Modell verfeinert die drei in Abbildung 4.10 beschriebenen Typen von Ereignissen in weitere Untertypen. Abstract Event eventID timestamp

Sensor Event sensorID location

Loop Detector Event velocity

Cleaned Loop Detector Event

0..* origin

aggregates

*

Traffic Data Event density occupancy averageSpeed

Traffic Light Event color ∈ {green, red, yellow}

reasonedOn

*

Problem Event severity

Road Area Event roadArea pointOfTime

Sensor Behavior Event sensorID timeInterval

Accident Event affectedLanes

Traffic Jam Event length affectedRoads

causes

*

0..1 causedBy

Abb. 4.11 Ausschnitt aus dem Ereignismodell für ein Verkehrskontrollsystem

Abstract Event ist ein abstrakter Ereignistyp, der Metadaten enthält, die für alle Ereignistypen gelten; hier sind dies eine eindeutige ID zur Identifikation eines Ereignisses (eventID) sowie der Auftrittszeitpunkt (timestamp). Alle Ereignistypen erben diese Attribute von Abstract Event. 11

Abstrakte Ereignistypen sind durch kursive Typnamen gekennzeichnet.


101

Sensor Event ist der abstrakte Ereignistyp aller Ereignisse, die unmittelbar von den Sensoren im Verkehrsnetz ausgesendet werden. Sie enthalten die Rohdaten, die für die weitere Verarbeitung weder modifiziert noch aufbereitet sind. Als elementare Daten enthält jedes Sensorereignis eine Sensor-ID (sensorID) und Angaben über den Ort, an dem sich der Sensor befindet (location). Für spezielle Sensoren lassen sich die folgenden konkreten Unterereignistypen unterscheiden. • Traffic Light Event steht für Ereignisse, die von den Ampeln produziert werden, um ihren aktuellen Zustand (grün, rot, gelb) zu kennen. Der aktuelle Zustand der Ampeln ist notwendig, um eine Verkehrssituation realistisch beurteilen zu können. • Loop Detector Event ist die Klasse der Sensorereignisse, die von den in den Straßen installierten Induktionsschleifen erzeugt werden, wenn ein Fahrzeug vorbeifährt. Je nach Typ können diese Sensoren verschiedene Daten messen, wie zum Beispiel die Fahrzeuggeschwindigkeit (velocity). • Cleaned Loop Detector Event repräsentiert konsistente Sensorereignisse. Wie bereits in Abschnitt 4.4 erwähnt, sind aufgrund technischer Probleme die von den Sensoren gelieferten Ereignisse oft fehlerhaft und inkonsistent. Die Ereignisse vom Typ Cleaned Loop Detector Event erfüllen alle für die Loop Detector Events definierten Constraints. Dabei ist wichtig, dass den Ereignissen keine inhaltlich neuen Informationen hinzugefügt, sondern nur fehlerhafte Ereignisse korrigiert oder herausgefiltert werden. Mögliche Constraints für Loop Detector Events sind: 1 2

c o n t e x t Loop D e t e c t o r E v e n t i n v : 0 < = velocity

3 4 5 6 7 8 9 10

c o n t e x t Loop D e t e c t o r E v e n t i n v : f o r A l l I n s t a n c e s ( e1 , e2 | ( e1 . s e n s o r I D == e2 . s e n s o r I D AND ( e1 . t i m e −e2 . t i m e ) < 0 . 0 0 1 ) i m p l i e s e1 = e2 )

Es wird also festgelegt, dass die Geschwindigkeit stets größer als 0 sein muss und dass von demselben Sensor stammende Ereignisse mit sehr kurzer Zeitdifferenz als identisch angesehen werden. Traffic Data Event ist der abstrakte Ereignistyp für alle Ereignisse, die charakteristische Verkehrskennzahlen liefern. Beispiele für Kennzahlen, die ein Traffic Data Event definiert, sind die Verkehrsstärke (occupancy), -dichte (density) oder die Durchschnittsgeschwindigkeit (averageSpeed). Diese Kennzahlen wurden bereits in Abschnitt 3.4 eingeführt. Um diese Kennzahlen zu erhalten, muss die Ereignisverarbeitung eine Vielzahl von Loop Detector Events aggregieren. Ein Traffic Data Event kann als aggregiertes Ereignis (composite event) verstanden werden, das eine Vielzahl einzelner Sensor

102

4 Ereignismodelle

Events zusammenführt. Die Aggregation kann in zweierlei Dimensionen erfolgen, was im Ereignismodell entsprechend abgebildet ist: 1. Sensor Behavior Events aggregieren die an einem bestimmten Sensor (mit identischer sensorID) in einem Zeitinterval (timeInterval) ausgelösten Loop Detector Events. Das Zusammenführen von Ereignissen über einen Zeitraum kann auch als zeitliche Korrelation (temporal correlation) aufgefasst werden. 2. Road Area Events fassen die Loop Detector Events zusammen, die an den Sensoren in einem bestimmten räumlichen Bereich (roadArea) zu einem definierten Zeitpunkt12 (pointOfTime) ausgelöst wurden (spatial correlation). Der generierte Ereignisstrom von Traffic Data Events beschreibt die aktuelle Verkehrssituation durch numerische Verkehrskennzahlen, um die weitere Analyse der vorliegenden Verkehrssituation zu erleichtern. Problem Event als Ereignistyp beschreibt aufgetretene Verkehrsprobleme. Diese werden erkannt, indem die Ereignisströme der Traffic Data Events auf kritische Muster hin überprüft werden. Problem Events können als komplexe Ereignisse (complex events) aufgefasst werden, weil sie Ereignisse nicht nur mittels arithmetischer Operationen aggregieren, sondern auf Basis von komplexen Regeln, die Expertenwissen repräsentieren, erzeugen. In dem Ereignismodell sind sie als abstrakter Ereignistyp mit einem Attribut severity definiert, das die Schwere des Problems anzeigt. Es gibt zwei konkrete, davon abgeleitete Ereignistypen: 1. Accident Events kennzeichnen einen Unfall und enthalten als Kontext die Anzahl der betroffenen Fahrbahnen (affectedLanes). 2. Traffic Jam Events beschreiben einen Verkehrsstau und besitzen als Kontext die Gesamtlänge des Staus (length) und die Menge der betroffenen Straßenabschnitte (affectedRoads). Wenn ein Problem identifiziert worden ist, muss im Rahmen der Verkehrssteuerung eine angemessene Reaktion angestoßen werden. Dazu gehören Warnmeldungen, Änderung der zulässigen Höchstgeschwindigkeit oder die Sperrung bzw. Umleitung von Verkehrswegen. Für die konkreten Verkehrssituationen und Reaktionen sei auf die Abschnitte 5.8 und 6.6 verwiesen. Beziehungen im Ereignismodell Abschließend seien in unserem Ereignismodell noch die zwischen den verschiedenen Ereignistypen modellierten Beziehungen erläutert (siehe Abbildung 4.12 als Ausschnitt aus Abbildung 4.11). Zunächst gibt es die beiden Beziehungen aggregates und reasonedOn, die die Zusammenhänge zwischen den abstrakten Ereignistypen Sensor Event, Traffic Data Event und Problem Event aufzeigen und somit den Abstraktionsprozess aus Abbildung 4.10 im Modell repräsentieren.

12

Dabei kann es sich auch um ein relativ kleines Zeitintervall handeln.

4.5 Fallstudie: Verkehrskontrolle und -steuerung Sensor Event

aggregates

Traffic Data Event

*

Loop Detector Event

103

reasonedOn

Problem Event

*

origin 0..*

Accident Event

causedBy 0..1

Traffic Jam Event

causes

*

Cleaned Loop Detector Event

Abb. 4.12 Sicht auf die Beziehungen im Ereignismodell für ein Verkehrskontrollsystem

• Ein Traffic Data Event aggregiert mehrere Ereignisse vom Typ Sensor Event, um Verkehrskennzahlen zu bilden. • Ein komplexes Ereignis vom Typ Problem Event steht für eine Erkenntnis, die aus vielen Ereignissen vom Typ Traffic Data Event geschlussfolgert wurde. Beide Beziehungen sind gerichtet: Beispielsweise kennt ein Problem Event die Traffic Data Events, aus denen es abgeleitet wurde. Die umgekehrte Richtung gilt nicht: Ein Traffic Data Event kennt in der Regel nicht die aus ihm gezogenen Schlussfolgerungen. In der Hierarchie der Sensorereignisse verweist die Beziehung origin auf die Ursprungsereignisse für jedes einzelne Cleaned Loop Detector Event. Die Kardinalität 0..∗ bildet die verschiedenen Möglichkeiten ab: 1. Ist ein Loop Detector Event nicht fehlerhaft oder können seine Daten korrigiert werden, so korrespondiert es mit genau einem Cleaned Loop Detector Event (Kardinalität = 1). 2. Bei Ereignisdubletten werden zwei Loop Detector Events auf ein Cleaned Loop Detector Event abgebildet (Kardinalität > 1). 3. Bei verloren gegangenen Ereignissen wird ein neues Cleaned Loop Detector Event erzeugt, für das kein entsprechendes Loop Detector Event existiert (Kardinalität = 0). In der Hierarchie der Problemereignisse werden die Abhängigkeiten zwischen Problemen durch zwei Beziehungen abgebildet. Die Beziehung causedBy ist optional und verweist auf ein Unfallereignis, wenn dieses die Ursache für ein Traffic Jam Event ist. Darüber hinaus gibt es noch eine reflexive Beziehung zwischen Traffic Jam Events. Die Beziehung causes zeigt an, wenn ein Stau als Folge eines anderen Staus entstanden ist. Diese Beziehung ist transitiv: Wenn ein Stau s1 einen Folgestau s2 verursacht hat und dieser wiederum einen Stau s3, dann ist s1 letztendlich auch für s3 verantwortlich.

Kapitel 5


Zusammenfassung Die Verarbeitung von Ereignissen und das Erkennen von Ereignismustern bilden den Kern des Complex Event Processing. Dieses Kapitel führt in die Konzepte zur regelbasierten Ereignisverarbeitung ein, indem anhand einer vereinfachten Regelsprache die wesentlichen Sprachelemente zur Verarbeitung von Ereignissen vorgestellt werden – zum einen die Beschreibung von Ereignismustern, zum anderen das Auslösen von Aktionen. Am Beispiel der CEP-Engine Esper wird weiterhin gezeigt, wie eine EDA-Anwendung mit einer konkreten Ereignisverarbeitungssprache implementiert werden kann. Mit Event Processing Agents (EPA) und Event Processing Networks (EPN) werden zwei wesentliche Konzepte für die Strukturierung und Leistungsfähigkeit von CEP vorgestellt. Das Kapitel schließt mit der Beschreibung der am Markt verfügbaren CEP-Produkte und -Sprachen und endet mit der Fortführung des Fallbeispiels der Verkehrskontrolle.

5.1 Regeln zur Ereignisverarbeitung Die Ereignisverarbeitung (event processing) mit Techniken des Complex Event Processing (CEP) [63] ist das Kernkonzept für die Mächtigkeit einer Event-Driven Architecture und folglich bildet die Ereignisverarbeitungsschicht die zentrale Architekturebene einer EDA.1 Mithilfe von CEP erfolgt die Analyse und Bewertung aller aus unterschiedlichen Quellen stammenden Ereignisse. Die Kernaufgabe der Ereignisverarbeitung ist das Erkennen von Beziehungsmustern (event pattern) zwischen den Ereignissen in den Ereignisströmen. Dies ist in der nachfolgenden Abbildung 5.1 dargestellt: In einer sehr großen Menge von Ereignissen, die isoliert betrachtet in vielen Fällen keine Aussagekraft besitzen, sollen Muster (bzw. Situationen) erkannt werden, die für das Anwendungsfeld von Bedeutung sind. Beispielsweise geht es in einem Ver-

1

Vgl. die Ausführungen in den Abschnitten 3.1 und 3.2.


105

106

5 Ereignisverarbeitung


Abb. 5.1 Erkennen von Beziehungsmustern in einer Ereignismenge

kehrskontrollsystem darum, in der riesigen Menge der erzeugten Sensorereignisse kritische Verkehrssituationen zu erkennen. Ereignisverarbeitung versucht demnach, eine Bedeutung aus der riesigen Menge der bisher aufgetretenen Einzelereignisse zu extrahieren. Ziel ist es also, zu verstehen, in welchem Zustand sich das System derzeit befindet.2 Wie bereits in Kapitel 4 diskutiert, treten Ereignisse auf verschiedenen Abstraktionsstufen auf. Die Ausgangs- oder Randereignisse fließen durch Sensormessungen oder einfache Benutzereingaben in das System ein und besitzen meist einen einfachen Kontext in Form weniger Daten. Ein EDA-basiertes System transformiert in einem mehrstufigen Verarbeitungsprozess einzelne, wenig bedeutungsvolle Randereignisse in komplexe, fachlich aussagekräftige Ereignisse. Die Abbildung 5.2 visualisiert die typische Abfolge der Transformation von Ereignissen in einer EDA. Zunächst aggregiert die Ereignisverarbeitung eine sehr große Menge einfacher Randereignisse und leitet nachfolgend aus den aggregierten Ereignissen mithilfe von Expertenwissen einige wenige komplexe Geschäftsereignisse mit hohem fachlichem Informationswert ab. Eine Ereignistransformation findet statt, wenn ein relevantes Muster in dem Ereignisstrom vorkommt – z.B. wenn im zeitlichen Verlauf eines Aktienkurses eine bestimmte Formation erkennbar ist. Sobald ein solches Muster erkannt ist (pattern matching), erfolgt eine entsprechende Reaktion – beispielsweise die Erzeugung eines neuen Ereignisses auf einer höheren Abstraktionsebene, hier z.B. vom Typ “Kaufsignal für Aktie“. Mustererkennung mit konventionellen Programmiersprachen Mithilfe herkömmlicher imperativer bzw. objektorientierter Programmiersprachen wie Java oder C# lassen sich Muster in Ereignisströmen nur mit relativ hohem Aufwand finden. In der jeweiligen Programmiersprache muss der Algorithmus zur Mustererkennung im Detail implementiert werden. Die Mustererkennnung ist dabei ggf. durchaus aufwändig: Die Ereignisströme müssen eingelesen werden, relevante Er2 Der Abschnitt 2.1.3 beschreibt ausführlich die große fachliche Relevanz, die das Erkennen von Ereignismustern in den Ereignis- bzw. Datenflüssen eines Unternehmens für dessen Handlungsfähigkeit besitzt.

5.1 Regeln zur Ereignisverarbeitung Anzahl der Ereignisse

107

Randereignisse

Aggregierte Ereignisse Komplexe Geschäftsereignisse

Aussagekraft

Abb. 5.2 Transformation von Ereignissen in einer Event-Driven Architecture

eignisse zwischengespeichert und alle vorliegenden Ereignisse mit den gesuchten Mustern kontinuierlich abgeglichen werden. Als Sprachkonstrukte zur Beschreibung von Mustern kommen in konventionellen Sprachen typischerweise komplizierte if- und switch-Anweisungen zum Einsatz. Insgesamt führt diese imperative Form der Mustererkennung zu einem hohen Programmieraufwand. Darüber hinaus sind die Muster nur schwer im Programmcode erkennbar, über mehrere Stellen im Anwendungscode verstreut und entsprechend schlecht zu ändern und zu pflegen. Insbesondere erfordert die Änderung eines Musters ein erneutes Compilieren des Source-Codes. Abschnitt 2.2.2 bezeichnet dieses Vorgehen als implizite Form der Ereignisverarbeitung und zeigt die Grenzen konventioneller Technologien auf. Mustererkennung mit Regelsprachen Einen besseren Ansatz zur Musterkennung bieten spezielle Regelsprachen, mit deren Hilfe sich Ereignismuster und -reaktionen deklarativ beschreiben lassen, die sogenannten Event Processing Languages (EPLs). Ereignisregel Eine Ereignisregel (event processing rule) beschreibt eine spezifische Reaktion, die beim Auftreten einer bestimmten Ereigniskonstellation erfolgen soll. Jede Regel setzt sich aus einem Bedingungs- und einem Aktionsteil zusammen (WENN-DANN-Regel): • Der Bedingungsteil definiert einen Auslöser (trigger) und besteht aus einem oder mehreren miteinander verknüpften Mustern, mit denen der Ereignisstrom abgeglichen wird.

108


• Der Aktionsteil legt eine Reaktion oder Aktion (action) fest, die ausgeführt wird, sobald das Muster im Ereignisstrom vorkommt. Mögliche Aktionen sind das Erzeugen eines neuen Ereignisses oder das Anstoßen eines Dienstes in einem Anwendungssystem.

Durch die deklarative Formulierung von Ereignisregeln ist es möglich, die Mustererkennung auf einer hohen Abstraktionsebene zu definieren. Statt selber die einzelnen Schritte eines Algorithmus zur Mustererkennung zu implementieren, müssen lediglich die gesuchten Muster in einer dafür speziell vorgesehenen Deklarationssprache definiert bzw. modelliert werden. Eine entsprechende Event Processing Engine, also ein speziell auf die Verarbeitung von Ereignisregeln ausgelegter Regelinterpreter, verarbeitet diese Regeln entsprechend einem vorgegebenen Verarbeitungsmodell und kann ohne weiteren Programmieraufwand die Muster in den Bedingungsteilen der Regeln mit dem eingehenden Ereignisstrom abgleichen.3 Erkennt die Engine ein Muster, dann ist der Bedingungsteil der entsprechenden Regel erfüllt und die Engine führt den Aktionsteil der Regel aus. Die Ausführung einer Regel wird auch als Feuern bezeichnet. Der Abschnitt 3.3 diskutiert ausführlich die Vorteile, die aus der deklarativen Repräsentation und Verarbeitung von Ereignisregeln resultieren. Eine vereinfachte Beispielsprache zur Formulierung von Ereignisregeln, differenziert nach dem Bedingungsteil mit den Ereignismustern (Abschnitt 5.2) und dem Aktionsteil (Abschnitt 5.3), wird in den folgenden Abschnitten eingeführt. Auf das Thema Event Processing Engines geht der Abschnitt 5.5 genauer ein.

5.2 Konzepte zur Beschreibung von Ereignismustern Der Bedingungsteil einer Ereignisregel setzt sich aus einem oder mehreren verknüpften Ereignismustern zusammen. Dieser Abschnitt führt schrittweise die grundlegenden Elemente einer Sprache zur Beschreibung von Ereignismustern ein. Dazu wird eine einfache Pseudosprache eingeführt, um die grundlegenden Sprachkonzepte vorzustellen. Die Sprache ist bewusst einfach gehalten und nicht annähernd so umfangreich und mächtig wie in der betrieblichen Praxis eingesetzte Ereignisverarbeitungssprachen. Der Abschnitt 5.4 stellt dann mit dem Werkzeug Esper eine

3

Dieses Vorgehen ist vergleichbar mit der Abfragesprache SQL für relationale Datenbanken: Der Entwickler deklariert die Anforderungen an die gesuchten Daten (select * from PERSON where alter > 20). Das Datenbanksystem interpretiert die SQL-Abfragen und sucht dann in eigener Regie mittels optimierter Algorithmen die gesuchten Daten. Es ist nicht notwendig, selbst zu implementieren, wie die Datenbanktabellen schrittweise durchsucht werden, um die gewünschten Daten zu finden.

5.2 Konzepte zur Beschreibung von Ereignismustern

109

konkrete Open-Source-Event-Processing-Engine mit ihrer spezifischen Event Processing Language (EPL) vor [34].4 Die Grundlage für jedes Ereignismuster ist die Folge der bisher aufgetretenen Ereignisinstanzen, die sich wie folgt definieren lässt. Ereignisfolge Eine Ereignisfolge ist eine Sequenz von Ereignisinstanzen (event instance sequence) und kann folgendermaßen notiert werden: a1 b1 b2 c1 a2 b3 . Dabei bezeichnet ai eine Ereignisinstanz vom Typ A und der Index i steht für das i-te Auftreten eines Ereignisses dieses Typs. Die Ereignisinstanz a2 ist also das zweite Ereignis vom Typ A in einer Ereignisfolge.5 Im Folgenden werden Ereignisinstanzen durch Kleinbuchstaben und Ereignistypen durch Großbuchstaben bezeichnet. Ein Ereignismuster beschreibt eine bestimmte Situation in einer Ereignisfolge, die von besonderem Interesse ist und die dementsprechend erkannt werden soll.6 Ereignismuster Ein Ereignismuster (event pattern bzw. event processing pattern) legt Bedingungen an eine Ereignisfolge fest. Die Spezifikation der Bedingungen erfolgt mithilfe der Operatoren einer Ereignisalgebra. Eine Folge von Ereignisinstanzen erfüllt ein Muster, wenn sie die im Muster festgelegten Bedingungen erfüllt. In diesem Fall ist die Ereignisfolge eine Instanz des Musters [68]. Beispielsweise erfüllt die Ereignisfolge b2 c1 das Muster “auf ein Ereignis vom Typ B folgt eine Instanz vom Typ C“. Definition von Ereignismustern Eine Ereignisalgebra definiert Beziehungen und Einschränkungen für eine Menge von Ereignissen. Dabei sollen fachliche, zeitliche und kausale Zusammenhänge zwischen Ereignisinstanzen spezifiziert werden können. Als Grundlage eines Ereignismusters gilt es zunächst, die Sequenz der erwarteten Ereignistypen festzulegen. Eine solche Sequenz lässt sich mithilfe spezieller Operatoren einer Ereignisalgebra beschreiben. In [117] werden die Eigenschaften von Ereignisalgebren im Detail untersucht.

4

Eine genauere Einordnung von Esper in die Klasse der Event Processing Languages erfolgt in Abschnitt 5.7. 5 Eine Ereignisfolge ist ein definierter Ausschnitt aus dem potenziell unendlichen Ereignisstrom. 6 Abschnitt 2.1.3 diskutiert ausführlich die fachliche Bedeutung von Ereignismustern.

110


Ereignisalgebra (I): Ein ereignistypbasiertes Muster (event type pattern) definiert die am Muster beteiligten Ereignistypen. Dabei werden folgende Operatoren zwischen Ereignistypen genutzt: • Der Sequenzoperator A → B legt die Reihenfolge fest, in der Ereignisinstanzen der definierten Typen auftreten müssen. Im Beispiel muss ein Ereignis vom Typ B einer Instanz vom Typ A folgen. Dazwischen können durchaus Ereignisse anderer Typen auftreten. Zum Beispiel erfüllt die Ereignisfolge a1 c1 d1 c2 b1 das Muster A → B. • Der Simultanoperator A == B definiert, dass zwei Ereignisinstanzen zum selben Zeitpunkt eintreten müssen. • Die booleschen Operatoren ∧ und ∨ definieren unabhängig von der Reihenfolge, welche Typen von zwei Ereignisinstanzen auftreten müssen. A ∧ B bedeutet, dass ein Ereignis vom Typ A und eins vom Typ B vorliegen müssen. A ∨ B erfordert entweder ein Ereignis vom Typ A oder eins vom Typ B. • Der Negationsoperator ¬A beschreibt, dass keine Instanz von einem bestimmten Ereignistyp (hier A) auftreten darf. Dieser Operator ist nur sinnvoll, wenn er sich auf ein bestimmtes Betrachtungsintervall bezieht (siehe nachfolgend den Abschnitt über Sliding Windows).

Die folgenden Beispiele verdeutlichen, wie die verschiedenen Operatoren kombiniert werden können, um komplexe Muster zwischen Ereignistypen auszudrücken. Das Muster 1

A → ( B ∨ C)

sucht nach einer Ereignisfolge, in der nach einem Ereignis vom Typ A ein Ereignis vom Typ B oder vom Typ C auftritt. Beispielsweise erfüllen die Ereignisfolgen a1 d1 e1 b1 oder a1 d1 c1 dieses Muster. Das Ereignismuster 1

(A → ¬B → C)

erfordert eine Ereignisfolge, in der ein Ereignis vom Typ C einem Ereignis vom Typ A folgt, ohne dass ein Ereignis vom Typ B dazwischen liegt. Somit erfüllt die Folge a1 d1 c2 das Muster, aber a1 b1 d1 c2 hingegen nicht. In vielen Fällen reicht es nicht aus, in einem Muster nur die Ereignistypen mit den entsprechenden Reihenfolgebedingungen festzulegen. Vielmehr ist es erforderlich, auch den Kontext der Ereignisse genauer zu beschreiben.


111

Ereignisalgebra (II): Kontextbedingungen (context conditions) definieren Anforderungen an die Attributwerte einer Ereignisinstanz. Um Ereignisinstanzen in Mustern verwenden zu können, müssen folgende Sprachkonstrukte eingeführt werden: • Aliasnamen für Ereignisinstanzen ermöglichen es, in Bedingungen verschiedene Instanzen zu verwenden. Aliasnamen werden mit dem Schlüsselwort AS definiert. • Der ’.’-Operator beschreibt den Zugriff auf ein Ereignisattribut. • Mithilfe von Daten aus der Anwendungsdomäne lassen sich weitere Kontextbedingungen formulieren. Der Zugriff auf Anwendungswissen ist z.B. durch Java-Methodenaufrufe in Regeln möglich. Für die Beschreibung von Bedingungen können die üblichen, für die jeweiligen Datentypen definierten Operationen und Vergleichsoperatoren verwendet werden. Für numerische Datentypen sind dies beispielsweise +, −, /, ∗, , ≤, ≥, =, = usw. Die folgenden Beispiele zeigen, wie diese Sprachkonstrukte eingesetzt werden können. Beispielsweise sucht das Ereignismuster 1

( ( A AS a ) → ( B AS b ) ) ∧ ( a . v a l u e 1 = b . v a l u e 2 )

eine Ereignisinstanz vom Typ A, gefolgt von einer Instanz vom Typ B, deren Attribute value1 und value2 mit identischen Werten belegt sind. Ein Muster, das Daten aus der Anwendungsdomäne verwendet, ist: 1 2

T r a f f i c E v e n t AS e ∧ e . v e l o c i t y < (0. 5∗ Roadnet . get SpeedLi m i t ( e . l o c a t i o n ) )

Gesucht werden Ereignisse vom Typ TrafficEvent mit einer Geschwindigkeit, die weniger als 50% der Geschwindigkeitsbegrenzung in dem Straßenabschnitt beträgt, in dem das TrafficEvent aufgetreten ist. Im Beispiel stellt die Anwendungsklasse Roadnet eine Methode zur Abfrage der zulässigen Höchstgeschwindigkeit in einem bestimmten Straßenabschnitt bereit. Auswahl von Ereignisinstanzen Beim Abgleich eines vorliegenden Ereignisstroms mit einem Muster stehen gegebenenfalls mehrere Instanzen eines Ereignistyps zur Verfügung, um das Muster zu erfüllen: Zum Beispiel wird das Muster A → B → C im Ereignisstrom ....a1 b1 b2 c1 ... sowohl von der Ereignisfolge a1 b1 c1 wie auch von a1 b2 c1 erfüllt. Eine Auswahlentscheidung zwischen den Ereignisinstanzen b1 und b2 ist demnach notwendig.

112


Ereignisalgebra (III): Ereignisinstanzauswahl (event instance selection): Gibt es beim Auslösen eines Musters mehrere Ereignisinstanzen, die das Muster erfüllen, so findet eine entsprechende Auswahl statt. Für die Selektion der Ereignisinstanz sind verschiedene Strategien möglich: Beispielsweise kann die erste oder die letzte der aufgetretenen Instanzen gewählt werden. Durch entsprechende Schlüsselwörter wie first oder last lässt sich die Selektionsstrategie anzeigen. Die nicht gewählte Instanz steht dann ggf. für das Auslösen eines anderen Musters weiterhin zur Verfügung. Zum Beispiel selektiert das Muster 1

A → ( f i r s t : B) → C

die Ereignisfolge a1 b1 c1 aus der Ereignisfolge ....a1 b1 b2 c1 .... Verbrauch von Ereignisinstanzen Darüber hinaus muss festgelegt werden, ob eine Ereignisinstanz für das Auslösen mehrerer Muster verwendet werden kann. Ereignisalgebra (IV): Konsumieren von Ereignisinstanzen (event instance consumption): Es kann gewünscht sein, dass eine einzelne Ereignisinstanz mehrere Ereignismuster auslöst. In diesem Fall ist der Ereignistyp durch das entsprechende Schlüsselwort shared ausgezeichnet. Im folgenden Beispiel löst die Ereignisfolge a1 b1 b2 zweimal das Muster aus, nämlich die beiden Teilfolgen a1 b1 und a1 b2 . Die Ereignisinstanz a1 wird also zweifach verwendet. 1

( s h a r e d : A) → B

Sliding Windows Theoretisch können Ereignismuster sämtliche zuvor aufgetretenen Ereignisse berücksichtigen. Da jedoch kontinuierlich neue Ereignisse entstehen, liegt eine ständig wachsende und damit quasi unbegrenzt große Menge von Ereignissen vor, z.B. alle Aktienkurse der zurückliegenden Jahre. Um den Abgleich der Ereignisse mit einem Muster effizient – und möglichst in Echtzeit – zu erreichen, wird deshalb die Anzahl der betrachteten Ereignisse auf Ausschnitte aus der Ereignismenge beschränkt. Diese Ausschnitte werden durch sogenannte Sliding Windows beschrieben.


113

Ereignisalgebra (V): Sliding Windows beschränken die Anzahl der Ereignisse in einem Ereignisstrom. Dabei lassen sich Längen- (length windows) und Zeitfenster (time windows) unterscheiden. 1. Ein Längenfenster der Länge N berücksichtigt nur die letzten N Ereignisse des Ereignisstroms. 2. Ein Zeitfenster betrachtet nur diejenigen Ereignisse, die im definierten Zeitraum, beispielsweise in den letzten 5 Minuten, aufgetreten sind. Sliding Windows werden durch entsprechende Schlüsselwörter win:time:x bzw. win:length:y in eckigen Klammern spezifiziert. Die Abbildung 5.3 zeigt ein Längenfenster mit einem Ereignispuffer der Länge 5. Bei Ankunft eines neuen Ereignisses wird das älteste Ereignis gemäß der FIFOStrategie (First-In-First-Out) aus dem Puffer geschoben. ankommende Ereignisse

Längenfenster = 5 Ereignisse

Zeit

Abb. 5.3 Sliding Window – Längenfenster mit einem Puffer der Länge 5

Als Beispiel für ein Zeitfenster beschreibt das Muster A[win : time : 5min] die Menge der Ereignisinstanzen vom Typ A in einem Zeitintervall der letzten 5 Minuten. Im Beispielmuster 1

(A → B ) [ win : t i m e : 5 min ] → C

muss innerhalb eines Zeitintervalls von 5 Minuten ein Ereignis vom Typ B auf ein Ereignis vom Typ A folgen; anschließend wird zu einem beliebigen Zeitpunkt noch ein drittes Ereignis vom Typ C erwartet. Die Abbildung 5.4 stellt die Ereignisfolge bei einem Zeitfenster mit der Intervalllänge von 3 Zeiteinheiten dar. Jedes Ereignis besitzt eine bestimmte Gültigkeitsdauer (lease time), nach deren Ablauf es aus dem Fenster der betrachteten Ereignisse

114

5 Ereignisverarbeitung ankommende Ereignisse

Zeitfenster = 3 Zeiteinheiten

t1

t2

t3

t4 Zeit

Abb. 5.4 Sliding Window – Zeitfenster mit einer Länge von 3 Zeiteinheiten

entfernt wird, im Beispiel der Abbildung geschieht dies nach 3 Zeiteinheiten. Aus der Abbildung geht hervor, dass das Zeitfenster unterschiedlich viele Ereignisinstanzen enthalten kann. Die geeignete Größe eines Sliding Windows ist oft schwer zu ermitteln und kann erst aufgrund entsprechender Erfahrungen optimiert werden. Ist beispielsweise das Zeitfenster für die Sensordaten in einem Verkehrsleitsystem sehr klein gewählt, so kann das plötzliche Abbremsen oder Anhalten eines einzelnen Fahrzeuges schon als Verkehrsproblem interpretiert werden. Wählt man die Sliding Windows zu groß, so ist das System nicht mehr hinreichend reaktiv, entstandene Probleme werden erst (zu) spät erkannt. Aggregationen Das Konzept der Sliding Windows dient nicht nur dazu, die Menge der Ereignisse einzuschränken, sondern ermöglicht es auch, Ereignisse zeitlich zusammenzufassen. Dazu werden entsprechende Aggregationsfunktionen verwendet. Ereignisalgebra (VI): Aggregationsfunktionen fassen die Attributwerte von Ereignissen zusammen und beziehen sich meist auf ein Sliding Window. Typische Aggregationsfunktionen sind: • sum(): bildet die Summe eines Attributwertes über alle Ereignisse, • avg(): berechnet den Durchschnittswert eines Attributs, • min() und max(): liefern das Minimum bzw. Maximum des Wertes. Durch die Verwendung von Aliasnamen mit dem Schlüsselwort AS lassen sich die Ergebnisse von Aggregationsfunktionen innerhalb einer Regel verwenden. Das folgende Ereignismuster berechnet den Durchschnitt des Attributs price für alle StockEvent-Ereignisse der letzten 5 Minuten.

5.3 Aktionen in Ereignisregeln

1

115

S t o c k E v e n t . avg ( p r i c e ) [ win : t i m e : 5 min ] AS a v e r a g e P r i c e

Bei der bisherigen Betrachtung bleibt allerdings die Frage offen, wie oft die Durchschnittsberechnung im obigen Beispiel durchgeführt wird. Dabei gibt es zwei verschiedene Möglichkeiten: 1. Jedes Eintreffen eines StockEvent-Ereignisses löst eine erneute Berechnung aus. 2. Die Berechnung erfolgt erst nach Ablauf des Sliding Windows, d.h., für ein Zeitfenster von 5 Minuten erfolgt die Berechnung alle 5 Minuten, für ein Längenfenster der Größe 10 nach Eintreffen von 10 Ereignissen. In diesem Fall kann das zugehörige Sliding Window als Batch-Window (Schlüsselwort batch) spezifiziert werden. Das Beispielmuster von oben lautet dann für ein Batch-Window:

1

S t o c k E v e n t . avg ( p r i c e ) [ win : t i m e : b a t c h : 5 min ] AS a v e r a g e P r i c e

Zusammenhang zwischen Ereignismustern und Ereignismodell Zwischen den in diesem Abschnitt eingeführten Ereignismustern und dem Ereignismodell aus Abschnitt 4.3 besteht ein enger konzeptioneller Zusammenhang. Jeder in einem Muster verwendete Ereignistyp und jedes dort referenzierte Attribut muss im Ereignismodell definiert sein. Dieser Sachverhalt verdeutlicht nochmals die zentrale Bedeutung eines Ereignismodells für Entwicklung von Ereignisregeln.

5.3 Aktionen in Ereignisregeln Im Zuge der Ereignisverarbeitung überprüft die Event Processing Engine einer CEP-Komponente kontinuierlich den einfließenden Strom der Ereignisinstanzen, ob ein im Bedingungsteil einer Ereignisregel definiertes Muster erfüllt ist. Falls eine Ereigniskonstellation vorliegt, die ein definiertes Muster erfüllt, so wird der Aktionsteil der erfüllten Regel angestoßen, d.h., die Ereignisregel “feuert“. Ereignisregeln setzen ein Muster P() und eine Aktion action() zueinander in Beziehung und lassen sich in allgemeiner Form durch CONDITION P(e1 , e2 , ..., en ) ACTION action(e1 , e2 , ..., en ) beschreiben. Dabei ist e1 , e2 , ..., en eine zeitlich geordnete Folge von Ereignisinstanzen mit beliebigen Ereignistypen, die das Muster P erfüllt.

116


Die Mustererkennung (pattern matching) löst eine Aktion action(e1, e2 , ..., en ) mit dem Auftreten des letzten Ereignisses en aus, das für ein Muster benötigt wird. Aktion Eine Aktion action(e1, e2 , ..., en ) realisiert die Ereignisbehandlung und ist für eine angemessene Reaktion auf die eingetretene Ereignissituation verantwortlich. Dazu benötigt sie den Situations- bzw. Aktionskontext, weshalb ihr die auslösende Ereignisfolge (e1 , e2 , ..., en ) als Parameter übergeben wird. Der Aktionskontext beschreibt zeitliche, örtliche und weitere semantische Eigenschaften der für das Auslösen der Aktion verantwortlichen Ereignisse. Im Wesentlichen lassen sich zwei Arten von Aktionen unterscheiden, die nachfolgend in diesem Abschnitt erläutert werden, siehe auch Abbildung 5.5: 1. Erzeugen neuer Ereignisse Die Aktion erzeugt ein neues Ereignis, das entweder nur die Daten der auslösenden Ereignisse aufbereitet oder die durch das Eintreten des Musters gewonnenen Erkenntnisse beschreibt. Das neu erzeugte Ereignis fließt in Form einer Rückkopplung an die CEP-Komponente zurück und wird dort weiterverarbeitet. 2. Anstoßen von Diensten Die Aktion stößt einen Dienst (service) in einem nachgelagerten Anwendungssystem an. Dort führen die operativen Systeme eine entsprechende Geschäftsaktion aus.

CEP-Komponente Ereignisregel Bedingungsteil

Muster

Aktionsteil

Anwendungssystem Dienst

Abb. 5.5 Aktionen in Ereignisregeln: (1) Erzeugung neuer Ereignisse oder (2) Anstoßen von Diensten

Entsprechend muss es im Aktionsteil einer Ereignisregel ein Sprachkonstrukt create zum Erzeugen einer neuen Ereignisinstanz geben. So wird beispielsweise


117

durch create BuyEvent(share =‘ibm‘, limit = 5000, currency = ‘Euro‘) eine neue Ereignisinstanz vom Typ BuyEvent erzeugt, die den möglichen Kauf einer IBM-Aktie für 5000 Euro anzeigt. Erzeugen neuer Ereignisse Das Erzeugen neuer Ereignisinstanzen innerhalb einer Regel kann als Ereignistransformation verstanden werden. Die Ereignisfolge e1 , e2 , ..., en , die das Muster erfüllt hat, wird in eine oder mehrere neue Ereignisinstanzen transformiert. Verschiedene grundlegende Transformationsschritte lassen sich unterscheiden. 1. Zum einen existieren Transformationsschritte, die die Ereignisfolge zwar umwandeln, aber keine neuen Informationen hinzufügen: (a) Translation, (b) Filterung, (c) Aggregation und (d) Splitting 2. Zum anderen existieren Transformationen, bei denen die neu erzeugten Ereignisse mehr Informationen mit sich führen als die ursprüngliche Ereignisfolge: (e) Anreicherung mit Kontextwissen und (f) Synthese komplexer Ereignisse (a) Translation: Ein Übersetzungsschritt überführt die Daten einer Ereignisinstanz in ein anderes (Daten-)Format bzw. in einen anderen Ereignistyp (siehe Abbildung 5.6).

originäres Ereignis

Translation

übersetztes Ereignis

Abb. 5.6 Translation eines Ereignisformats in ein anderes Format

Ereignisse stammen aus verschiedenen heterogenen Quellen, wie z.B. Sensoren oder Softwaresystemen, und liegen folglich auch in unterschiedlichen Formaten vor. Ein Standardschritt in der Ereignisverarbeitung besteht aus der Abbildung heterogener Ereignisinstanzen auf ein einheitliches Standardformat. Ereignisinstanzen können beispielsweise als XML-Datensätze, Java-Objekte oder CSV-Werte dargestellt sein.7 Darüber hinaus unterstützen verschiedene Softwaresysteme unterschiedliche Datentypsysteme, so dass auch Datenwerte durch eine Typkonvertierung ggf. in ein Standardformat überführt werden müssen.8

7

Vgl. Abschnitt 4.1. Beispiele sind unterschiedliche Genauigkeiten für numerische Datentypen oder verschiedene Codierungen für Strings.

8

118


(b) Filterung (filtering): Um mit der riesigen Menge der erzeugten Ereignisse umgehen zu können, werden die für eine fachliche Fragestellung relevanten Ereignisse aus einer Ereignisfolge herausgefiltert (siehe Abbildung 5.7). Das Filtern reduziert die Anzahl der betrachteten Ereignisse und ist ein wesentliches Konzept für die Effizienzsteigerung der Ereignisverarbeitung.9

vollständige Ereignisfolge

Filterung

relevante Ereignisse

Abb. 5.7 Filtern von Ereignissen

Beispielsweise sollen für ein System zur Erkennung von Kreditkartenbetrugsfällen nur Ereignisse, die Zahlungen mit einem Wert größer als 500 Euro repräsentieren, betrachtet werden. Entsprechend filtert die Ereignisregel alle Ereignisse mit einem größeren Umsatzwert aus dem Ereignisstrom heraus. Die folgende Ereignisregel zeigt die konkrete Umsetzung: 1 2 3

CONDITON ( T r a n s f e r E v e n t As t ) ∧ ( t . amount > 500) ACTION c r e a t e R e l e v a n t T r a n s f e r ( n r = t . nr , amount = t . amount )

Den CONDIT ION-Teil der Regel erfüllen nur TransferEvent-Ereignisse mit einem Betrag größer als 500 – dieses Ereignismuster implementiert das Filtern der Ereignisse. Der ACT ION-Teil erzeugt dann eine neue Instanz des Ereignistyps RelevantTransfer und initialisiert diese Instanz mit den Attributwerten des TransferEvent-Ereignisses. Genau genommen filtert die obige Regel keine Ereignisse aus dem Ereignisstrom heraus, sondern selektiert die sinnvollen Ereignisse und kopiert sie in einen neuen Ereignistyp, im Beispiel in den Typ RelevantTransfer. In manchen CEPUmgebungen – wie beispielsweise Esper – gibt es überhaupt keinen Befehl zum Löschen (delete) von Ereignisinstanzen. Das entspricht der Sichtweise, dass Ereignisse nicht ungeschehen gemacht werden können. In solchen Umgebungen kann, wie im obigen Beispiel gezeigt, ein eigener Ereignistyp für die gefilterten Ereignisse eingeführt werden. Eine weitere Möglichkeit zur Reduktion der Ereignismenge bietet die Aggregation von Ereignissen. 9 Je nach dem eingenommenen Blickwinkel können entweder die relevanten Ereignisse für die weitere Verarbeitung herausgefiltert werden oder aber die irrelevanten Ereignisse werden herausgefiltert und stehen damit für die weitere Verarbeitung nicht mehr zur Verfügung.


119

(c) Aggregation: Eine Aggregation fasst mehrere einfache Ereignisse zusammen, um aussagekräftige Daten zu erhalten (siehe Abbildung 5.8). Hierbei kommen u.a. die Aggregationsfunktionen aus Abschnitt 5.2 zur Anwendung. Insbesondere betrifft die Zusammenfassung oft zeitlich oder räumlich korrelierte Ereignisse.

einfache Ereignisse

Aggregation

aggregiertes Ereignis

Abb. 5.8 Aggregation von Ereignissen

Die folgende Regel erzeugt in einem Wertpapierhandelssystem Ereignisse, die den Durchschnittswert einer Aktie in den letzten 200 Tagen berechnen, also zur Bildung der 200-Tage-Linie genutzt werden können. 1 2 3

CONDITON ( S t o c k E v e n t As s ) [ win : t i m e : 2 0 0 d a y s ] ∧ s . name= ‘ i b m ‘ ∧ s . avg ( v a l u e ) AS a v e r a g e ACTION c r e a t e 200 DayAvgEvent ( name= s . name , v a l u e = a v e r a g e )

Die Regel betrachtet ein Zeitfenster von 200 Tagen für jedes ankommende StockEvent für den angegebenen Aktiennamen10 und berechnet den Durchschnittswert des Attributs value. Schließlich erzeugt die Regel im ACT IONTeil eine Ereignisinstanz vom Typ 200DayAvgEvent mit dem Namen des Ausgangsereignisses und dem kalkulierten Durchschnittswert. (d) Splitting: Ein Splitting-Schritt erzeugt aus einer Ereignisinstanz mehrere neue Instanzen, d.h., ein Ereignis wird in mehrere einzelne Ereignisse aufgebrochen (siehe Abbildung 5.9). Zum Beispiel kann in einem Lagerverwaltungssystem ein Splittung-Schritt das Ereignis einer umfangreichen Bestellung in mehrere Einzelereignisse, die jeweils eine Bestellposition repräsentieren, aufteilen. Diese neuen feingranulareren Ereignisse unterstützen die Berechnung genauerer Kennzahlen des Warenverkehrs. Zur Beschreibung von Ereignisregeln und -mustern werden häufig Informationen benötigt, die nicht unmittelbar in den Ereignissen enthalten sind, sondern in den 10

Aus Gründen der Vereinfachung ist in der Ereignisregel der Name der Aktie als fester Wert angegeben. Natürlich ist es in einer realen Anwendung sinnvoller, den Namen der Aktie als Parameter an die Regel zu übergeben.

120

Ereignis


Splitting

aufgeteilte Ereignisse

Abb. 5.9 Splitting einer Instanz in mehrere Instanzen

angebundenen Anwendungssystemen zur Verfügung stehen. Wie bereits oben beschrieben, lassen sich aus Anwendungsdaten stammende Kontextbedingungen beispielsweise in Form von Java-Methodenaufrufen formulieren. Um die Anzahl der Methodenaufrufe zu reduzieren und damit die Ereignisverarbeitung zu beschleunigen, bietet es sich an, direkt in den Ereignisinstanzen die benötigten Anwendungsdaten abzulegen. (e) Anreicherung mit Kontextwissen (content enrichment): Im ContentEnrichment werden Ereignisinstanzen mit zusätzlichen Daten aus den Anwendungssystemen angereichert (siehe Abbildung 5.10).

einfaches Ereignis

angereichertes Ereignis ContentEnrichment

Abb. 5.10 Anreicherung mit Kontextwissen (content enrichment)

Durch die Anreicherung der Ereignisinstanzen mit Kontextwissen werden die Instanzen selbst mit den für ihre Weiterverarbeitung erforderlichen Informationen versorgt, so dass in nachfolgenden Schritten keine weiteren Zugriffe auf Anwendungssysteme notwendig sind. Es existieren viele Beispielfälle, in denen die Ergänzung von Ereignisdaten durch Anwendungsdaten notwendig ist. Beispielsweise werden häufig eindeutige, aber fachlich wenig aussagekräftige Identifikationsnummern (IDs) – wie Personal- oder Artikelnummern – durch detailliertere Personal- oder Produktdaten ergänzt. Anschließend können Ereignismuster auch auf diese Attribute unmittelbar zugreifen. Insbesondere die Instanzen der Ausgangs- oder Randereignisse enthalten meist nur sehr wenige und rudimentäre Informationen. Typische Daten, mit denen Ereignisobjekte angereichert werden, sind die folgenden:


121

• In RFID-Systemen werden RFID-Lesegeräte-IDs auf reale geographische Orte und RFID-Tag-IDs auf Frachten, Waren oder Akten abgebildet. Eine RFIDTag-ID wird beispielsweise mit einer systembekannten Frachtnummer, Frachttyp, Lieferdatum usw. ergänzt. • Häufig werden räumliche Daten über die Topologie des Sensornetzes benötigt, um Muster formulieren zu können. Zum Beispiel muss in Verkehrsleitsystemen bekannt sein, welche Sensoren benachbart sind, denn bei großen Abweichungen an Nachbarsensoren kann auf Verkehrsprobleme geschlossen werden. • Gemessene quantitative Daten werden in Bezug zu historischen Daten gesetzt und in qualitative Daten transformiert. Zum Beispiel werden Temperaturwerte in Bezug zu normalen Werten als niedrig, normal oder hoch bewertet. Die Anreicherung führt auch zu einer fachlich verständlicheren Formulierung von Ereignismustern und -regeln. Zum Beispiel lassen sich in einem Verkehrskontrollsystem quantitative Geschwindigkeitsdaten in qualitative Verkehrsdaten umrechnen, wie beispielhaft in der folgenden Regel formuliert: CONDITON ( S e n s o r E v e n t As s ) ACTION c r e a t e T r a f f i c E v e n t ( s e n s o r I D = s . s e n s o r I D , v e l o c i t y = TrafficMgr . get Vel oci t y ( s . vel oci t y , s . sensorID ) )

1 2 3

Den Wert des Geschwindigkeitsattributs des neu erzeugten Ereignisses vom Typ TrafficEvent wandelt die von der Anwendungsklasse TrafficMgr bereitgestellte Methode getVelocity() in einen qualitativen Wert wie ’schnell’ oder ’langsam’ um. Dabei werden die am jeweiligen Streckenabschnitt zulässigen Höchstgeschwindigkeiten berücksichtigt. In den obigen Verarbeitungsschritten werden die Ereignisse nur sehr moderat geändert. Eine Schlüsseleigenschaft für die Mächtigkeit von Complex Event Processing liegt aber darin, aus der Masse der aufgetretenen Ereignisse gänzlich neue Rückschlüsse und Erkenntnisse zu folgern, und zwar durch die Ableitung von komplexen Ereignissen. (f) Synthese komplexer Ereignisse (synthesis of complex events): Neue komplexe Ereignisse entstehen als Abstraktion der in einem Ereignismuster in Beziehung gesetzten einfachen Ereignisse (siehe Abbildung 5.11). Muster zur Erzeugung komplexer Ereignisse stellen kausale, temporale, räumliche und sonstige semantische Beziehungen zwischen Ereignissen her, aus denen sich eine fachliche Bedeutung ableiten lässt. Beispielsweise wird zur Erkennung eines Phishing-Versuchs11 im Bankenumfeld nach auffälligen und ungewöhnlichen Verhaltensmustern beim Onlinebanking gesucht. Ein solches ungewöhnliches Verhaltensmuster tritt beispielsweise ein, wenn 11

Phishing (= password fishing) bezeichnet das unrechtmäßige Ausspähen von Zugangsdaten für Internetanwendungen.

122


Ereignisfolge

komplexes Ereignis Synthese

Abb. 5.11 Synthese komplexer Ereignisse anhand eines Ereignismusters

unmittelbar nach der Passwortänderung eines Online-Bankkontos ein hoher Geldbetrag von genau diesem Konto abgehoben wird. Die folgende Regel beschreibt ein solches Verhaltensmuster. 1 2 3 4 5

CONDITON ( P a s s w o r d C h a n g e E v e n t As p → W i t hdrawEvent AS w) [ win : t i m e : 1 5 min ] ∧ p . a c c o u n t ==w . a c c o u n t ∧ w . amount > 1 0 . 0 0 0 Euro ACTION c r e a t e P h i s h i n g E v e n t ( a c c o u n t =p . a c c o u n t )

Das Ereignismuster sucht Situationen innerhalb der Ereignismenge, in denen für dasselbe Konto ein WithdrawEvent auf ein PasswordChangeEvent innerhalb eines Zeitfensters von 15 Minuten folgt. An diesem Beispiel lässt sich sehr deutlich der mit komplexen Ereignissen verbundene Erkenntnisgewinn erkennen: Es werden nicht nur arithmetische Berechnungen durchgeführt, sondern eine auf Erfahrungen basierende Schlussfolgerung (inference) abgeleitet. Wenn nach einer unrechtmäßigen und erfolgreichen Änderung des Passworts anschließend sofort ein großer Geldbetrag abgehoben wird, leitet die Regel die Schlussfolgerung ab, dass es sich bei diesem Vorgang um einen Betrugsfall handeln könnte. Das neue komplexe Ereignis vom Typ PhishingEvent beschreibt die Situation auf einer höheren Abstraktionsebene als die beiden einfachen Ereignisse. Anstoßen von Diensten Die eigentliche Ereignisbehandlung als Reaktion auf das Auftreten eines spezifizierten Ereignismusters erfolgt in der Regel in den nachgelagerten Unternehmensanwendungen, in denen die ablauforientierten Geschäftsprozesse realisiert sind. Neben der Erzeugung neuer Ereignisse kann deshalb im Aktionsteil einer Regel auch ein Dienst12 eines Anwendungssystems ausgelöst werden. Insbesondere sollen am Ende der Ereignisverarbeitungskette die mittels CEP gewonnenen Erkenntnisse unmittelbar in die operativen Unternehmensanwendungen einfließen. Die Abbildung 5.12 visualisiert den Ablauf: Die CEP-Komponente aggregiert Randereignisse und transformiert diese in komplexe Ereignisse mit hoher fachlicher Aussagekraft. 12

Der Begriff Dienst ist in diesem Kontext als Oberbegriff für jedwede Art von Geschäftsabläufen bzw. -funktionalität zu verstehen, also Methoden, Funktionen, Abläufe in WorkflowManagementsystemen, Anzeigen in BAM-Anwendungen, Dienste im Sinne von SOA usw.


123


Operatives System Dienst

Randereignisse

Aggregierte Ereignisse

Komplexe Ereignisse

Dienst

Abb. 5.12 Anstoßen von Diensten aus dem CEP-System

Diese führen dann letztendlich zum Anstoßen eines nachgelagerten Dienstes, der die weitere fachliche Behandlung des Ereignisses durchführt. Beispielsweise wird in einem System zum Wertpapierhandel ein komplexes Ereignis vom Typ “Kaufsignal“ an das operative Handelssystem weitergeleitet. Das Handelssystem führt dann den eigentlichen Geschäftsprozess des Wertpapierkaufs – mit all seinen Details – Schritt für Schritt durch. Prozedurale Abläufe und ablauforientierte Prozesse sollten auch weiterhin mit konventionellen Softwarearchitekturen realisiert werden und folglich außerhalb der CEP-Komponente verbleiben. Die CEP-Komponente ist ausschließlich für die Verarbeitung von Ereignissen zuständig, über die nachgeordneten Abläufe hat sie idealerweise keinerlei Informationen. Weitere Details diskutiert das nachfolgende Kapitel 6 Ereignisbehandlung. Technisch gibt es unterschiedliche Möglichkeiten für das Anstoßen eines Dienstes aus einer Ereignisregel heraus: • Eine Ereignisregel (bzw. die CEP-Komponente) stellt die aus der Ereignisverarbeitung gewonnenen Erkenntnisse durch eine Nachricht (message) über eine nachrichtenorientierte Middleware zu Verfügung. Nachgelagerte Anwendungssysteme können dann auf die Nachricht zugreifen und entsprechende Dienste auslösen. Im Java-Umfeld kommt hierfür typischerweise JMS (Java Message Service) zum Einsatz und die Ereignisregel versendet entsprechend eine JMSNachricht. Der zugehörige Source-Code im Aktionsteil einer Regel sieht etwa wie folgt aus: QSender.send(event), wobei QSender eine Klasse ist, die die Verbindung zu einer JMS-Queue herstellt und Nachrichten per send(..) verschicken kann. • Der technisch einfachste Fall ist ein direkter Dienstaufruf in der Form call MyEventHandler.react(e1, e2, ..., en) im Aktionsteil der Regel. Diese Anweisung ruft für eine Klasse MyEventHandler die Methode react() auf und übergibt den Ereigniskontext in Form der auslösenden Ereignisse als Parameter.13 • Statt eines direkten Dienstaufrufs lässt sich auch ein indirekter Benachrichtigungsdienst verwenden. Dabei wird beim Ereignismuster ein Listener registriert, der eine festgelegte Methode (beispielsweise action()) implementiert. Jedes 13

Bei dieser Anweisung ist zu beachten, dass es sich technisch nicht um eine Objektmethode handelt: es gibt kein Objekt für das dieser Dienst aufgerufen wird. Vielmehr ist der Dienst technisch als statische Klassenmethode oder auch als Web Service [5] realisiert.

124


Mal wenn die Regel feuert, ruft die Event Processing Engine automatisch diese Methode auf. Einen solchen indirekten Mechanismus verwendet zum Beispiel das CEP-Werkzeug Esper. Der nachfolgende Abschnitt geht explizit auf dieses Konzept ein. Zusammenhang zwischen Aktionen und Ereignismodell Auch zwischen dem Ereignismodell und den Aktionen aus diesem Abschnitt besteht ein direkter konzeptioneller Zusammenhang. Sämtliche im Aktionsteil einer Regel mit dem Sprachkonstrukt create erzeugten Ereignisinstanzen müssen zu Ereignistypen gehören, die im Ereignismodell definiert sind. Nur definierte Ereignisse dürfen also in den Verarbeitungsregeln erzeugt werden. Da vielfach komplexe Ereignistypen erst während der Entwicklung der CEPKomponente erkannt werden, unterliegt das Ereignismodell einer entsprechenden Dynamik. Mit weiteren Verarbeitungsregeln können auch immer neue Ereignistypen hinzukommen. Diese Dynamik ist bei einem Vorgehensmodell für die Entwicklung von EDA-Anwendungen geeignet zu berücksichtigen (siehe das Vorgehensmodell in Kapitel 9). Darüber hinaus dürfen die in den Ereignisregeln erzeugten Ereignisse natürlich auch nicht die im Ereignismodell spezifizierten Constraints verletzen (siehe Abschnitt 4.4). Wenn beispielsweise ein Constraint für das Attribut “stockValue“ im Ereignistyp “StockEvents“ Werte größer als null festlegt, dann darf keine Ereignisinstanz mit einem negativen Attributwert erzeugt werden. Aktionen und Constraints Streng genommen gehören Constraints nicht zur eigentlichen Ereignisverarbeitung, sondern definieren bereits im Ereignismodell die an Ereignisinstanzen gestellten Bedingungen, um inkonsistente oder “sinnlose“ Ereignisse zu verhindern. Letztendlich lässt sich aber jeder Constraint durch eine geeignete Ereignisregel abbilden, die – im Idealfall – automatisch aus dem Constraint generiert wird. Wie sehen nun solche Regeln aus? 1. Constraint-Formulierung im Bedingungsteil Die in einem Constraint definierten Bedingungen finden sich als Ereignismuster im Bedingungsteil einer Regel wieder. 2. Constraint-Behandlung im Aktionsteil Die Art der Behandlung der Ereignisse, die als fehlerhaft erkannt werden, erfolgt im Aktionsteil. Dabei stehen grundsätzlich zwei Möglichkeiten zur Verfügung: a. Korrektur der inkonsistenten Daten der betroffenen Ereignisinstanz (vergleichbar der Anreicherung um Kontextwissen). b. Entfernen der fehlerhaften Ereignisinstanz aus dem Ereignisstrom (vergleichbar dem Filtern). Zur Veranschaulichung der Abbildung von Constraints auf Ereignisregeln dient die folgende, in OCL formulierte Bedingung:

5.4 Ereignisregeln mit Esper

125

context StockEvent inv stockValue > 0

1 2

Dieser Constraint kann jetzt in die beiden nachfolgenden Ereignisregeln umgesetzt werden: StockEvent-Ereignisse mit positivem Wert kopiert die Regel in ein Ereignis vom Typ CleanedStockEvent um. Fehlerhafte StockEventEreignisse mit einem negativen Wert werden korrigiert, indem die Regel den Attributwert auf 0 setzt.14 1 2

CONDITON S t o c k E v e n t As s ∧ s . v a l u e ≥0 ACTION c r e a t e C l e a n e d S t o c k E v e n t ( sym bol = s . symbol , v a l u e = s . v a l u e )

3 4 5

CONDITON S t o c k E v e n t As s ∧ s . v a l u e 100

1

Dieses Muster selektiert alle StockEvent-Ereignisse, die sich auf IBM-Aktien beziehen und einen Wert größer als 100 aufweisen. Deutlich erkennbar ist die Ähnlichkeit zu einer Datenbankabfrage mit den folgenden Elementen: • From-Klausel Die From-Klausel legt fest, welche Ereignistypen betrachtet werden, in diesem Fall sind dies Ereignisse vom Typ StockEvent. Darüber hinaus kann die Menge der betrachteten Ereignisse noch durch ein in der From-Klausel spezifiziertes Sliding Window eingeschränkt werden.19 • Select-Klausel Die Select-Klausel definiert, welche Ereignisattribute selektiert werden; ’*’ bedeutet (wie bei SQL in Datenbankabfragen), dass alle Attribute des Ereignistyps betrachtet werden. • Where-Klausel In der Where-Klausel können die Ereignistypen, die in der From-Klausel definiert sind, noch eingeschränkt werden. Im Beispiel sollen die Attribute symbol und price entsprechende Werte besitzen. Jedes Mal wenn ein StockEvent-Ereignis mit diesen Eigenschaften ankommt, ist das Muster erfüllt und eine entsprechende Aktion wird ausgeführt. Wie das in Esper funktioniert, zeigt der folgende Code. 1 2 3 4

S t r i n g s t m t = " s e l e c t ∗ from S t o c k E v e n t where sym bol = ’ ibm ’ and p r i c e >100 " ; EPStatement esperSt m t = stockEventAgent . getEPAdministrator ( ) . createEPL ( stmt ) ;

5

e s p e r S t m t . s e t S u b s c r i b e r ( new M y P a t t e r n S u b s c r i b e r ( ) ) ;

6

Im ersten Schritt wird aus einem String, der das Ereignismuster repräsentiert (Zeilen 1-2), ein Esper-Statement esperStmt erzeugt und dem EPA übergeben. Dazu 19

Auf die Verwendung von Sliding Windows in Esper geht der nächste Abschnitt im Detail ein.


129

wird aus der den EPA repräsentierenden Esper-Instanz stockEventAgent ein EPAdministrator-Objekt erzeugt. Dieses Objekt stellt die Methode createEPL() zur Verfügung, mit der ein Ereignismuster in dem EPA registriert werden kann (Zeilen 3-4). Hierdurch erfolgt die Aufnahme eines neuen Ereignismusters in die Regelbasis eines EPA. Den Aktionsteil einer Regel realisiert Esper durch ein Subscriber-Objekt: Dieses Objekt wird durch die Methode setSubscriber() beim Ereignismuster (hier: esperStmt) registriert (Zeile 6). Jedes Mal wenn das Ereignismuster feuert, wird in dem Subscriber-Objekt die dort implementierte Methode update() aufgerufen. Der folgende Java-Code zeigt die Implementierung der Subscriber-Klasse. 1 2 3 4 5

public c l a s s MyPatternSubscriber { public void update ( StockEvent evt ){ Syst em . o u t . p r i n t l n ( e v t . g e t S y m b o l ( ) + " " + e v t . g e t P r i c e ( ) ) ; } }

Jede Subscriber-Klasse muss eine Methode namens update() implementieren. Dabei muss die Signatur der Methode den selektierten Ereignisattributen entsprechen. Weil in diesem Fall alle Attribute von StockEvent per select * ausgewählt werden, enthält die update()-Methode ein StockEvent-Objekt als Parameter. Jedes StockEvent-Ereignis, das das Muster erfüllt, wird dann als aktueller Parameter an update() übergeben und kann ganz normal verwendet werden. Der Befehl in Zeile 3 gibt einfach die beiden Attribute symbol und price auf der Konsole aus. Werden im Ereignismuster mehrere Daten selektiert, beispielsweise s e l e c t ∗ , avg ( p r i c e ) from S t o c k E v e n t where sym bol = ’ ibm ’

1

so muss die Update-Methode eine dazu passende Signatur besitzen, in diesem Fall: update(StockEvent e, double avg).20

5.4.3 Ereignismuster in Esper Anhand einiger Beispiele zeigt dieser Abschnitt, wie Ereignismuster in der Sprache EQL definiert werden. Dabei werden die in den vorangegangenen Abschnitten eingeführten Sprachkonstrukte aufgegriffen. 20

In Esper gibt es u.a. auch sogenannte Listener, die auf das Auslösen von Ereignismustern reagieren können. Die update()-Methode in Listenern ist nicht streng typisiert, sondern enthält als Ereignisparameter Arrays von generellen EventBeans, deren Daten erst durch explizites Casting verfügbar sind und das Schreiben von Aktionen umständlicher machen. Allerdings lassen sich bei einem Esper-Statement mehrere Listener-Objekte statt nur eines Subscriber-Objektes registrieren. Genaueres ist in der Esper-Dokumentation zu finden ([35], in Kapitel 9.3).

130


Ereignistypbasierte Muster Auch in EQL ist es möglich, komplexe ereignistypbasierte Muster zu beschreiben, und zwar mithilfe des Sprachkonstrukts pattern[ ]. Das folgende Beispiel veranschaulicht die Syntax. 1 2 3

s e l e c t s . symbol , n . d e s c r i p t i o n , s . time−n . ti m e from p a t t e r n [ n=NewsEvent −> s = S t o c k E v e n t ( sym bol = n . sym bol ) ] where s . sym bol= ’ ibm ’

Ereignistypen und Aliasnamen Die From-Klausel bezieht sich in dem Beispiel auf ein ereignistypbasiertes Muster, das im pattern-Teil spezifiziert ist. Das Muster benötigt zwei Objekte der beiden Ereignistypen NewsEvent und StockEvent, für die Aliasnamen eingeführt werden: n=NewsEvent und s=StockEvent. Mit n und s werden also die beiden Ereignisse bezeichnet, die das Pattern erfüllen. Sequenzoperator Im Pattern legt der Sequenzoperator -> die zeitliche Reihenfolge der Ereignisse fest: n muss vor dem Ereignis s stattfinden. Schließlich muss noch eine Bedingung für das Ereignis s gelten: Der Wert des Attributs symbol muss mit dem Attributwert symbol im Ereignis n übereinstimmen. Join-Operation Diese Bedingung kann – ähnlich wie bei SQL in Datenbanken – als eine Art Join-Operation aufgefasst werden. Der NewsEvent- und der StockEvent-Ereignisteilstrom werden zusammengeführt. In der Select-Klausel werden als Ergebnisdaten die Attribute symbol und description von den Objekten s und n betrachtet sowie der zeitliche Abstand zwischen dem Auftreten von s und n berechnet (s.time-n.time).21 Kontextbedingungen Der Kontext der auslösenden Ereignisse lässt sich an zwei Stellen im Ereignismuster festlegen: 1. Innerhalb des Patterns kann eine Bedingung für einen Ereignistyp spezifiziert werden (hier: StockEvent(symbol = n.symbol). 2. Weitere Kontexte lassen sich in der Where-Klausel festlegen, hier sollen nur StockEvent-Ereignisse betrachtet werden, die sich auf die IBM-Aktie beziehen. Boolesche Operatoren Darüber hinaus stehen auch die anderen in Abschnitt 5.2 eingeführten Sprachkonzepte zur Verfügung. In Ereignismustern in Esper können mit den booleschen Operatoren Ereignistypen verknüpft werden. • ODER-Operator Das folgenden Muster gibt ein Beispiel für eine ODER-Verknüpfung. Im Ereignisstrom wird ein auftretendes NewsEvent- oder ein StockEvent-Ereignis

21 In der zugehörigen Subscriber-Klasse hat die update(String, String, int)-Methode entsprechend drei Parameter mit den zur Select-Klausel passenden Datentypen.


131

selektiert. Sobald eine Ereignisinstanz eines dieser beiden Typen ankommt, feuert das Pattern.22 select s ,n from p a t t e r n [ n= NewsEvent or s = S t o c k E v e n t ]

1 2

• UND-Operator Alternativ kann natürlich auch ein logisches UND verwendet werden. Das folgende Pattern erlaubt, dass in beliebiger Reihenfolge ein NewsEvent- und ein StockEvent-Ereignis der IBM-Aktie auftreten. Sobald im Ereignisstrom zwei solche Ereignisse eingetroffen sind, feuert das Pattern. select s ,n from p a t t e r n [ n= NewsEvent and s = S t o c k E v e n t ( sym bol = ’ ibm ’ ) ]

1 2

• Negationsoperator Der NOT-Operator beschreibt den Sachverhalt, dass ein bestimmtes Ereignis nicht stattgefunden hat. Daher bezieht sich dieser Operator immer implizit auf ein Zeitintervall. Das folgende Pattern beschreibt zwei nacheinander stattfindende StockEvent-Ereignisse s1 und s2, die sich auf dasselbe Wertpapier beziehen und eine Preissteigerung von 20% aufweisen. Gleichzeitig wird verlangt, dass es keine Nachricht zwischen dem Auftreten von s1 und s2 gibt. s e l e c t s1 , s2 from p a t t e r n [ s1 = S t o c k E v e n t −> ( s2 = S t o c k E v e n t ( sym bol = s1 . symbol , p r i c e > 1 . 2 ∗ s1 . p r i c e ) and not NewsEvent ( sym bol = s1 . sym bol ) ) ]

1 2 3 4

Auswahl und Verbrauch von Ereignisinstanzen Die bisher gezeigten Ereignismuster feuern genau einmal. Sind alle für ein Muster erforderlichen Ereignisse aufgetreten, stoppt die Verarbeitung der Regel. Wird beispielsweise das folgende Pattern auf die Ereignisfolge a1 a2 a3 b1 b2 a4 b3 a5 angewendet, so feuert das Pattern einmalig nach dem Eintreffen des Ereignisses b1 , d.h., ausschließlich die Ereignisfolge a1 b1 löst das Muster aus. 1 2

select a ,b from p a t t e r n [ a=EventA −> b= EventB ]

Soll ein Pattern wiederholt ausgeführt werden, lässt sich dies in Esper durch das Schlüsselwort every steuern. Die nachfolgende Tabelle 5.1 variiert das Pattern der vorhergehenden Regel (A -> B) und wendet sie auf die Folge a1 a2 a3 b1 b2 a4 b3 a5 an. 22

Die Signatur der update-Methode besteht in diesem Fall aus zwei Parametern, wobei beim Aufruf der Methode nur ein Parameter instanziiert ist.

132


Tabelle 5.1 Verwendung von every in Esper-Pattern für die Ereignisfolge a1 a2 a3 b1 b2 a4 b3 a5 Pattern A every A A→B every (A → B)

Beschreibung

auslösende Ereignisse

Das Pattern feuert nach dem ersten Auftreten {a1 } eines Ereignisses vom Typ A und stoppt dann. Das Pattern feuert bei jedem Auftreten eines {a1 } {a2 } {a3 } {a4 } Ereignisses vom Typ A. {a5 } Das Pattern feuert nur einmalig.

{a1 b1 }

Nach Auftreten einer Instanz von A sucht das {a1 b1 } {a4 b3 } Muster nach einer Instanz von B. Wurde diese gefunden, feuert das Pattern und die Suche beginnt erneut.

every A → B

Das Pattern feuert bei jeder Instanz von A, die {a1 b1 } {a2 b1 } {a3 b1 } von einem B-Typ gefolgt wird. Dabei wird ein {a4 b3 } B-Ereignis ggf. mehrfach verwendet.

A → every B

Das Pattern feuert bei einer Instanz von A, ge- {a1 b1 } {a1 b2 } {a1 b3 } folgt von jeder Instanz vom Typ B. Dabei wird ein A-Ereignis ggf. mehrfach verwendet.

every A → every B Das Pattern feuert bei jeder Instanz von A, ge- {a1 b1 } {a2 b1 } {a3 b1 } folgt von jeder Instanz vom Typ B. Dabei wer- {a1 b2 } {a2 b2 } {a3 b2 } den A- und B-Ereignisse mehrfach verwendet. {a1 b3 } {a2 b3 } {a3 b3 } {a4 b3 }

Der every-Operator in Esper bildet die in Abschnitt 5.2 vorgestellten Konzepte zur Auswahl und zum Verbrauch von Ereignissen nicht exakt ab. Es existieren weder spezielle Operatoren wie first oder last, um die im Pattern verwendeten Ereignisinstanzen zu selektieren, noch besteht die Möglichkeit, mittels shared explizit die mehrfache Verwendung eines Ereignisses zuzulassen. Esper wählt standardmäßig die erste Instanz oder – bei Verwendung von every – jede Ereignisinstanz aus. Damit im Fall von every wirklich jede Ereignisinstanz ein Pattern auslöst, werden die Ereignisse anderer im Pattern genutzter Typen gegebenenfalls mehrfach verwendet. Insgesamt lässt sich also in Esper die Auswahl (instance selection) und das Konsumieren (instance consumption) von Ereignisinstanzen steuern – wenn auch nicht ganz präzise. In praktischen Anwendungsfällen dürften die zur Verfügung gestellten Mechanismen aber durchaus ausreichend sein. Sliding Windows Esper ist speziell auf die Verarbeitung von Ereignisströmen ausgelegt und bietet entsprechend umfangreiche Sprachkonstrukte zur Definition von Sliding Windows. Längenfenster Das folgende Ereignismuster gibt ein Beispiel für die Definition eines Fensters mit festgelegter Länge.


1 2

133

s e l e c t sum ( p r i c e ) from S t o c k E v e n t . win : l e n g t h ( 3 )

Für den StockEvent-Ereignisteilstrom wird ein Längenfenster der Größe 3 definiert und die Summe des price-Attributs selektiert. Abbildung 5.14 veranschaulicht die Arbeitsweise. Jedes Kästchen repräsentiert ein StockEventEreignis mit dem entsprechenden Preis. Bei der Ankunft jedes neuen Ereignisses wird die Summe aus den price-Attributen der letzten drei Ereignisse erneut berechnet. Zum Zeitpunkt t4 kommt eine StockEvent-Instanz mit dem Wert ’30’ an und es werden die Preise der letzten drei Ereignisse erneut aufsummiert. win:length(3) 20

t1

20

t2

20

10

t3

20

10

5

t4

20

10

5

30

t5

20

10

5

30

win:length_batch(3) 20

30 35 45 50

45

85 sum(price)

Abb. 5.14 Summenberechnung in einem Sliding Window der Länge 3

Batch-Window Soll nicht bei jedem ankommenden Ereignis eine neue Berechnung durchgeführt werden, lässt sich dieses Verhalten durch sogenannte BatchWindows steuern (siehe Abbildung 5.14, rechte Spalte). Ein Batch-Window führt bei einem Längenfenster der Länge 3 immer erst nach der Ankunft von 3 Ereignissen eine neue Berechnung durch. Im Beispiel erfolgt die Summenbildung also nach Berechnung der Summe in t1 erst wieder in t4 und danach in t7. Zeitfenster Natürlich ist es in Esper auch möglich, Zeitfenster zu definieren. Esper unterscheidet dabei wiederum zwischen normalen Zeitfenstern (StockEvent.win:time(3 sec)) und Batch-Zeitfenstern (StockEvent.win:time_batch(3 sec)). Bei normalen Zeitfenstern werden bei jedem Eintreffen eines Ereignisses alle zurückliegenden Ereignisse betrachtet, die im spezifizierten Zeitraum aufgetreten sind. Bei Batch-Zeitfenstern werden erst nach dem Ablauf des definierten Zeitintervalls neue Auswertungen durchgeführt, die sich auf die Ereignisse im definierten Zeitraum beziehen. Pattern Guards Auch innerhalb des Sprachkonstruktes pattern[ ] sind Sliding Windows anwendbar. Die zeitlichen Einschränkungen sollen sich unter Umständen nur auf einzelne Bestandteile des Patterns beziehen. Zu diesem Zweck wer-

134


den in Esper sogenannte Pattern Guards der Form timer:within(3 sec) eingeführt. Die Bedeutung soll anhand des folgenden Beispiels erklärt werden: 1 2 3 4 5 6

s e l e c t s1 , s2 from p a t t e r n [ e v e r y ( s1 = S t o c k E v e n t −> s2 = S t o c k E v e n t ( sym bol = s1 . symbol , p r i c e > ( s1 . p r i c e ∗ 1 . 2 0 ) ) ) where t i m e r : w i t h i n ( 2 h o u r s ) ]

Dieses Muster sucht nach aufeinanderfolgenden Ereignisfolgen von StockEvent-Ereignissen, bei denen die Aktie eines bestimmten Unternehmens eine Preissteigerung von mindestens 20% aufweist. Als zusätzliche Bedingung soll diese Änderung im zeitlichen Abstand von maximal 2 Stunden aufgetreten sein. Das Muster verwendet den every-Operator, weil auch nach einer erfolgreichen Suche die Verarbeitung des Ereignisstroms fortgesetzt werden soll. Aggregationen Auch in Esper lassen sich mit einer Reihe von Aggregationsfunktionen Berechnungen über einer Menge von Ereignissen durchführen. Die wichtigsten Funktionen sind in der folgenden Tabelle 5.2 dargestellt. Tabelle 5.2 Überblick über die in Esper angebotenen Aggregationsfunktionen Funktion

Bedeutung

sum(*)

zählt die Anzahl der aufgetretenen Ereignisse

sum()

berechnet die Summe eines Attributs über eine Ereignisfolge

avg()

berechnet den Durchschnitt eines Attributs über eine Ereignisfolge

min()

bestimmt den minimalen Wert eines Attributs über eine Ereignisfolge

max()

bestimmt den maximalen Wert eines Attributs über eine Ereignisfolge

Das folgende Beispiel zeigt die Verwendung einer solchen Aggregationsfunktion. 1 2 3

s e l e c t avg ( p r i c e ) from S t o c k E v e n t . win : l e n g t h ( 1 0 ) where sym bol = ’ ibm ’

Das Muster betrachtet das Längenfenster StockEvent.win:length(10) der letzten 10 StockEvent-Ereignisse. In diesem Fenster werden die IBM-Aktien –


135

wie in der Where-Klausel spezifiziert – selektiert und darüber der Durchschnittspreis der IBM-Aktie berechnet. Das oben betrachtete Längenfenster ist nicht durch die Where-Klausel beschränkt, d.h., es enthält in der Regel auch andere als IBM-Aktien, und somit liegen dem berechneten Kursdurchschnitt weniger als 10 IBM-Aktien zugrunde. Soll stattdessen der Durchschnittspreis für die letzten 10 eingetroffenen StockEvent-Ereignisse mit dem Wert symbol=’ibm’ berechnet werden, so muss diese Bedingung schon bei der Definition des Fensters angegeben werden: s e l e c t avg ( p r i c e ) from S t o c k E v e n t ( sym bol = ’ ibm ’ ) . win : l e n g t h ( 1 0 )

1 2

Soll nun der Durchschnittswert nicht nur für eine bestimmte Aktie, sondern für alle Unternehmen berechnet werden, so lässt sich dies in Esper leicht mit Gruppierungsfunktionen erreichen. Ein Beispiel zeigt der folgende Code: 1 2 3

select symbol , avg ( p r i c e ) from S t o c k E v e n t . s t d : g r o u p b y ( sym bol ) . win : l e n g t h ( 1 0 0 ) group by sym bol

In Zeile 2 werden mithilfe des Ausdrucks std:groupby(symbol) die Ereignisse im Fenster StockEvent.win:length(100) gruppiert, d.h., für jeden Symbolwert wird eine eigene Sicht, eine Sub-View, gebildet.23 Der Durchschnitt wird jetzt also nicht über 100 beliebige Aktien gebildet, sondern ausschließlich über die Aktien des selben Symbols, die im Fenster der letzten 100 Ereignisse vorkommen. Die Group-by-Klausel in Zeile 3 ist zusätzlich erforderlich, damit die Durchschnittsberechnung (avg(price)) auch für jedes Symbol separat erfolgt. Bei jedem neu ankommenden StockEvent-Ereignis wird der Durchschnittspreis für das jeweils zugehörige Symbol berechnet. Soll nicht bei jeder Ereignisankunft eine erneute Berechnung durchgeführt werden, so lässt sich dies durch ein Batch-Fenster realisieren.24 Ein Batch-Fenster gibt nur nach jeweils 100 Ereignissen eines Symbols den Durchschnittswert aus. Schon an diesen wenigen Beispielen lässt sich erkennen, dass es sehr viele Möglichkeiten zur Verwendung von Aggregationsfunktionen und Sliding Windows in der Esper-EQL gibt. Die Syntax ist sehr kompakt, aber erfordert auch sehr aufmerksames Hinschauen, um die genaue Semantik eines spezifizierten Musters zu verstehen.

23 24

Dies ist mit Views in Datenbanksystemen vergleichbar. StockEvent.std:groupby(symbol).win:length_batch(100)

136


5.4.4 Aktionen in Esper Wie bereits in Abschnitt 5.3 beschrieben, können auch in Esper bei Eintreten eines Musters grundsätzlich zwei Arten von Aktionen ausgelöst werden: (a) Anstoßen eines Dienstes in einem Anwendungssystem oder (b) Erzeugen neuer Ereignisse. (a) Anstoßen von Diensten Das Auslösen eines beliebigen Anwendungsdienstes kann in der update()-Methode der Subscriber-Klasse realisiert werden. Die Event Processing Engine von Esper führt den Musterabgleich durch und ruft die update()-Methode des registrierten Subscriber-Objekts auf, sobald das Muster erfüllt ist. In Abschnitt 5.4.2 steht ein entsprechendes Beispiel. Die Parameter der update()-Methode müssen mit der Select-Klausel des Ereignismusters korrespondieren. Hier ein weiteres Beispiel für eine solche Subscriber-Klasse, die auf das Muster select * from BuySignalEvent reagieren und empfohlene Aktien kaufen soll. 1 2 3 4 5 6

public c l a s s BuySignalEventSubscriber { public void update ( BuySignalEvent evt ){ S t o c k T r a d i n g t r a d i n g = TradeM anager . g e t I n s t a n c e ( ) ; t r a d i n g . buy ( e v t . g e t S y m b o l ( ) , e v t . p r i c e ( ) ) ; } }

Die update()-Methode soll in diesem Fall also auf ein aufgetretenes BuySignalEvent-Ereignis reagieren und bekommt es deshalb als Parameter übergeben. Für die Implementierung der Methode ist zunächst ein Objekt notwendig, mit dessen Hilfe der Zugriff auf das Anwendungssystem erfolgt, um die dort angebotenen Dienste aufzurufen. In Zeile 3 dient diesem Zweck das Objekt trading, das über spezielle anwendungsspezifische Methoden erzeugt wird. Anschließend kann der eigentliche Dienst im Anwendungssystem – hier die Methode buy() – aufgerufen werden, dem entsprechende Parameter aus dem BuySignalEvent-Objekt übergeben werden (Zeile 4). (b) Erzeugen neuer Ereignisse Soll in Esper ein neues Ereignis erzeugt werden, so kann dies ebenfalls in der update()-Methode einer Subscriber-Klasse geschehen. Dazu wird einfach ein Ereignisobjekt erzeugt und explizit mit der Methode sendEvent() an eine EsperInstanz mit eigener Event Processing Engine geschickt. Der dazu erforderliche Source-Code wurde bereits in Abschnitt 5.4.1 im Detail gezeigt. Dieses Vorgehen ist besonders interessant, wenn das Ereignis an einen anderen oder mehrere Event Processing Agents geschickt werden soll, wie in den nachfolgenden Abschnitten zum Thema Event Processing Networks noch gezeigt wird.


137

Allerdings ist bei diesem Ansatz die Erzeugung neuer Ereignisse nicht direkt in den Regeln erkennbar, sondern in den Subscriber-Klassen versteckt. In gewissem Sinne ist hier die Regelbasis nicht vollständig, weil wichtige Aspekte des Regelsystems fehlen: nämlich die Erzeugung neuer Ereignisse. Deshalb besteht in Esper die Möglichkeit, auch innerhalb einer Ereignisregel neue Ereignisinstanzen zu erzeugen. Dies geschieht mithilfe der Insert-Klausel. Die folgende Regel zeigt ein Beispiel, wie im System für den Wertpapierhandel ein MovingAverageEvent (siehe Ereignismodell in Abbildung 5.13) erzeugt werden kann. 1 2 3 4

i n s e r t i n t o M ovi ngAverageEvent ( symbol , a v e r a g e ) s e l e c t symbol , avg ( p r i c e ) from S t o c k E v e n t . s t d : g r o u p b y ( sym bol ) . win : ti m e ( 2 0 0 d a y s ) group by sym bol

Die Insert-Klausel erzeugt jedes Mal, wenn das zugehörige Ereignismuster aus den Zeilen 2-4 feuert, ein neues Ereignis vom Typ MovingAverageEvent mit den beiden Attributen symbol und average. Die beiden Attribute der Insert-Klausel korrespondieren mit denen, die in der Select-Klausel des Ereignismusters ausgewählt sind. Das eigentliche Ereignismuster berechnet wieder den 200-Tage-Durchschnittskurs einzelner Aktientitel. In der From-Klausel wird ein entsprechendes Zeitfenster für eine Dauer von 200 Tagen ausgewählt, dabei werden die StockEventEreignisse nach den Aktiensymbolen gruppiert. Die Group-by-Klausel sorgt dafür, dass der Durchschnitt gemäß der Gruppierung für jedes Symbol getrennt berechnet wird. Das so erzeugte MovingAverageEvent-Ereignis wird in den Ereignisstrom eingefügt und kann durch weitere Regeln verarbeitet werden. Zum Beispiel liest die folgende Regel einfach die Ereignisse. 1 2

s e l e c t symbol , a v e r a g e from M ovi ngAverageEvent

Insgesamt betrachtet können MovingAverageEvent-Ereignisse als Aggregation von einfachen StockEvent-Ereignissen aufgefasst werden. Dabei werden die Ereignisse mit demselben Symbolwert korreliert. Abschließend soll nun noch gezeigt werden, wie ein komplexes Ereignis vom Typ BuySignalEvent erzeugt werden kann. Dieses Ereignis repräsentiert ein Kaufsignal, das in dem Fall eintreten soll, wenn der aktuelle Preis einer Aktie den 200-Tage-Durchschnitt übersteigt. Im Detail ist die Regel wie folgt aufgebaut. Ein BuySignalEvent enthält die beiden Attribute symbol und price und wird erzeugt, sobald das in den Zeilen 25 definierte Ereignismuster ausgelöst wird. Die From-Klausel verwendet ein Pattern, das zwei Ereignisteilströme betrachtet: StockEvent und MovingAverageEvent.

138

1 2 3 4 5


i n s e r t i n t o B u y S i g n a l E v e n t ( symbol , p r i c e ) s e l e c t s . symbol , s . p r i c e from p a t t e r n [ e v e r y s = S t o c k E v e n t −> m = M ovi ngAverageEvent ( sym bol = s . sym bol ) ] where s . p r i c e > m. a v e r a g e

In dem Pattern (Zeilen 3-4) werden ein StockEvent-Ereignis s und ein MovingAverageEvent m miteinander verglichen, die folgende Eigenschaften erfüllen: Sie sollen sich auf die selbe Aktie beziehen (symbol=s.symbol) und der aktuelle Kurswert (s.price) soll größer sein als der errechnete Durchschnittspreis (m.average). Die Reihenfolgevorschrift (s->m) sorgt dafür, dass nach Ankunft eines StockEvent der nachfolgend berechnete, – und damit aktuelle – Durchschnittswert für den Vergleich verwendet wird. Das Ereignismuster verbindet zwei Teilströme von Ereignissen und führt damit – wie in relationalen Datenbanken – einen Join durch. Die Verknüpfungsbedingung für den Join ist im Pattern durch den Ausdruck(symbol=s.symbol) festgelegt: Ist ein StockEvent-Ereignis s mit bestimmtem Symbolwert aufgetreten, dann wird ein nachfolgendes MovingAverageEvent-Ereignis gesucht, das denselben Symbolwert besitzt.25 Bewertung von Esper Insgesamt bietet Esper mit seiner Esper Query Language (EQL) eine ausdrucksstarke Event Processing Language, mit der sich die in Abschnitt 5.2 eingeführten generellen Sprachkonzepte für eine Ereignisverarbeitungssprache nahezu ausnahmslos abbilden lassen. Die Implementierung einfacher Ereignismuster gelingt schnell und ohne Probleme. Allerdings erfordert die Einarbeitung in Esper-EQL aber auch einige Mühe, da die Sprache relativ umfangreich ist und darüber hinaus SQL-ähnliche Sprachelemente mit einer eigenen Pattern-Sprache mit temporalen Operatoren mischt. Darin liegt – wie auch bei anderen Programmiersprachen – ein inhärenter Widerspruch: Einerseits besteht der Wunsch nach mächtigen Sprachkonstrukten, mit denen sich auch spezielle Anforderungen leicht erfüllen lassen, andererseits wird dadurch die Sprache schnell umfangreich und komplex. In diesem Abschnitt offenbarte sich dieses Dilemma vielleicht besonders bei den Esper-Konzepten zur Definition von Sliding Windows. Es gibt viele verschiedene Möglichkeiten, Betrachtungsfenster zu definieren, und anfangs ist es nicht ganz einfach, das adäquate Sprachkonstrukt aus der Vielzahl der Möglichkeiten zu finden. Dieser Abschnitt beschränkt sich auf die Vorstellung weniger, grundlegender Sprachelemente von Esper. Für den kompletten Sprachumfang und mehr praktische Beispiele sei auf die Dokumentation [35] und die Esper-Webseiten [34] verwiesen. 25

Ähnlich wie in relationalen Datenbanken lassen sich auch in Esper verschiedene Arten von Joins definieren, u.a. Left-Outer-Join, Right-Outer-Join. Details sind dazu in der Dokumentation zu finden [35].

5.5 Event Processing Agents und Event Processing Engines

139

5.5 Event Processing Agents und Event Processing Engines Regelbasierte Systeme ermöglichen eine sehr kompakte und elegante Spezifikation der Ereignisverarbeitung. Die vorgestellten Ereignisregeln sowohl in der eingeführten Pseudosprache der Abschnitte 5.2 und 5.3 als auch die Esper-Regeln zeigen, dass sich schon mit wenigen Zeilen einer Ereignisverarbeitungssprache komplexe Ereignismuster definieren lassen. Bei einer solchen deklarativen Beschreibung von Anwendungswissen muss sich der Entwickler nicht selbst darum kümmern, wie die Auswertung der Regelmenge erfolgt. Diese Aufgabe nimmt ein Regelinterpreter (rule engine) dem Entwickler ab. Complex Event Processing stellt einige spezifische Anforderungen an die zugrunde liegenden Regelinterpreter, nämlich die Verarbeitung von kontinuierlich einfließenden Strömen von Ereignissen sowie die Fähigkeit zur Verarbeitung von hochfrequenten Massenereignisdaten. Für Regelinterpreter, die explizit für Complex Event Processing (bzw. Event Stream Processing) entwickelt wurden, hat sich die Bezeichnung Event Processing Engine etabliert.26 Zum Beispiel verwaltet eine Event Processing Engine selbständig die verschiedenen Sliding Windows und aggregiert die darin enthaltenen Ereignisdaten. So ist es nicht mehr notwendig, den dafür erforderlichen imperativen Code selber zu schreiben, der Schritt für Schritt die Ereignisse sammelt, vergleicht und auswertet. Die in Abschnitt 3.2.1 eingeführten Event Processing Agents (EPA) als zentrale CEP-Komponente bilden die Bausteine einer Event-Driven Architecture und enthalten eine Event Processing Engine als wichtigsten Bestandteil. Wie in Abbildung 3.7 dargestellt, sind neben der Event Processing Engine das Ereignismodell und die Ereignisregeln die weiteren grundlegenden Elemente eines EPAs. Event Processing Agent (EPA) bzw. CEP-Komponente Ein Event Processing Agent (EPA) ist eine Softwarekomponente, die für die Verarbeitung von Ereignissen zuständig ist und damit als Ausführungseinheit der Ereignisregeln dient. Im Einzelnen führt ein Event Processing Agent die folgenden Aufgaben durch (siehe auch Abbildung 5.15): • Monitoring des Eingangsstroms Zunächst überwacht der EPA den eingehenden Strom der einfließenden Ereignisse und filtert ggf. die für ihn bestimmten Ereignistypen heraus. Darüber hinaus prüft er die Konsistenz der eintreffenden Ereignisinstanzen auf Basis der Constraints des Ereignismodells und bereinigt eventuell aufgetretene Fehler. • Mustererkennung Als Kernaufgabe führt der EPA eine Mustererkennung (pattern matching) durch. Dazu werden Ereignisregeln (event processing rules) mithilfe des Regelinterpreters auf den relevanten Ereignisströmen ausgeführt. Um Muster auffinden zu 26

Abkürzend auch als CEP-Engine bzw. ESP-Engine bezeichnet.

140


können, muss der EPA sämtliche Ereignisobjekte verwalten, die in den Sliding Windows seiner Regeln enthalten sind. Diese Ereignisse bilden die eigentliche Datenbasis der Mustererkennung. • Reaktion Sobald der EPA ein Muster erkennt, leitet er eine entsprechende Reaktion ein. Die durch ein Muster korrellierten örtlich, zeitlich oder kausal zusammenhängenden Ereignisse werden nun zu aggregierten oder komplexen Ereignissen verdichtet. Diese neuen Ereignisse können dann zu anderen EPAs weitergeleitet werden (forward events) oder die Ausführung eines Anwendungsdienstes auslösen (trigger service).


Eingangsstrom Monitoring

Mustererkennung

Constraints

Regelbasis

Ereignismenge

Reaktion

Dienste auslösen

Ereignisse weiterleiten

Ausgangsstrom

Abb. 5.15 Aufgaben eines Event Processing Agent

Anforderungen Die Event Processing Agents müssen verschiedene funktionale und nichtfunktionale Anforderungen erfüllen. • Verarbeitung von Ereignisströmen Zunächst sollen EPAs in der Lage sein, kontinuierliche Ereignisströme zu verarbeiten. Dazu muss die von ihnen verwendete Regelsprache die in Abschnitt 5.2 eingeführten Sprachkonzepte unterstützen. Besonders wichtig für die Ereignisverarbeitung ist die Unterstützung von Sliding Windows mit den entsprechenden Aggregationsfunktionen. • Reaktion in Echtzeit Die von einem EPA verwendeten Regelinterpreter müssen einen möglichst performanten Musterabgleich durchführen können. Je nach Anwendungsszenario ist es erforderlich, mehrere zehntausend bis zu mehreren hunderttausend Ereignissen pro Sekunde zu analysieren und zu bearbeiten. Wie bereits beschrieben, sollen die Ereignisse in einer Event-Driven Architecture in Echtzeit verarbeitet werden. Die eingesetzten Event Processing Engines müssen insbesondere optimiert sein, um sehr große Sliding Windows sowie temporale Abhängigkeiten effizient auswerten zu können. • Agilität bzw. Wartbarkeit Schließlich müssen die EPAs leicht gewartet und an neue Anforderungen angepasst werden können. Die Verwendung deklarativer Regeln anstatt imperativer

5.5 Event Processing Agents und Event Processing Engines

141

Verarbeitungsalgorithmen erleichtert bereits inhärent die Änderung der Ereignisverarbeitung. Darüber hinaus sollten EPAs idealerweise über eine entsprechende Infrastruktur zum Verwalten der Regeln verfügen. Derzeit gibt es noch relativ wenig Unterstützung bei der Entwicklung von Regelsystemen, es fehlen insbesondere Entwicklungsumgebungen mit Regeleditoren, Debuggern und speziell auf Regelsysteme angepassten Versionsverwaltungswerkzeugen. EPAs in Esper In Esper lässt sich das Konzept der EPAs relativ einfach umsetzen. Wie bereits in Abschnitt 5.4.1 beschrieben, können mehrere Esper-Instanzen erzeugt werden, wobei eine Esper-Instanz im Wesentlichen die gerade beschriebenen Aufgaben eines EPA übernimmt, d.h., eine Esper-Instanz realisiert einen Event Processing Agent. Der folgende Java-Code-Ausschnitt zeigt noch einmal schematisch den grundlegenden Ablauf zur Erzeugung und Initialisierung eines Esper-EPA (also einer EsperInstanz). Dabei sind drei Schritte erforderlich: 1 2

E P S e r v i c e P r o v i d e r epa1 = E P S e r v i c e P r o v i d e r M a n a g e r . g e t P r o v i d e r ( "myEPA1 " ) ;

3 4 5

EPStatement r u l e 1 = epa1 . g e t E P A d m i n i s t r a t o r ( ) . c r e a t e E P L ( " s e l e c t ∗ from MyEvent " ) ;

6 7

r u l e 1 . s e t S u b s c r i b e r ( new R u l e 1 S u b s c r i b e r ( ) ) ;

1. Der erste Schritt (Zeile 1-2) erzeugt eine Esper-Instanz (hier namens epa1). Dazu wird die Methode getProvider(<epaName>) der EPServiceProviderManager-Klasse verwendet. Unter dem übergebenen Namen (hier: "myEPA1") wird der EPA in der Managerklasse registriert. Bei erneuter Verwendung dieses Namens wird – wie bei einer Singleton-Methode [43] – die bereits unter diesem Namen erzeugte EPA-Instanz zurückgegeben. 2. Im EPA wird nun eine Ereignisregel registriert. Die Schnittstelle eines EPA zum Registrieren von Regeln liefert die Methode getEPAdministrator(), die wiederum createEPL() zur Verfügung stellt, um Regeln im EPA zu registrieren. Esper bezeichnet Ereignisregeln als EPStatements. Nach dem Registrieren der Regel wird diese von der im EPA integrierten Event Processing Engine ausgeführt. 3. Im dritten Schritt (Zeile 7) kann für eine Regel eine Aktion in Form eines Subscriber-Objekts registriert werden. Dieser Schritt ist optional, denn wie in Abschnitt 5.4.4 gezeigt – einige der Regeln erzeugen per insert neue Ereignisse und benötigen deshalb keinen Subscriber. Im Subscriber-Objekt können die Reaktionen auf ein erkanntes Muster implementiert werden, also beispielsweise der Aufruf eines beliebigen Dienstes oder das Senden einer Nachricht. Jeder EPA in Esper besitzt seine eigene Event Processing Engine, bei der beliebig viele Ereignisregeln registriert werden können. Das von Luckham [63] eingeführte

142


Konzept der Event Processing Agents als die zentralen Einheiten der Ereignisverarbeitung ist insbesondere wichtig, um die im nächsten Abschnitt vorgestellten Event Processing Networks (EPNs) umsetzen zu können. Die EPAs bilden die Bausteine für EPNs.

5.6 Event Processing Networks Zwar ermöglicht die Verwendung von Regeln eine sehr kompakte Darstellung der Ereignisverarbeitung, aber es ist mitunter schwierig, die Arbeit eines Regelinterpreters mit vielen Regeln zu verstehen und nachzuvollziehen. Das liegt vor allen Dingen daran, dass es in Regelsystemen sehr schwierig ist, den Kontrollfluss der Abarbeitung zu durchschauen. Löst zum Beispiel ein einzelnes Ereignis zwei Muster aus, so muss festgelegt sein, in welcher Reihenfolge die Regeln feuern.27 Aus diesem Grund führt Luckham [63] das Konzept der Event Processing Networks (EPNs) ein. Ein Event Processing Network erlaubt es, umfangreiche Regelwerke zu modularisieren, und vereinfacht damit die Entwicklung und Wartung einer Event-Driven Architecture.28 Event Processing Network (EPN) Ein Event Processing Network ist ein Netzwerk von Event Processing Agents (EPAs), die miteinander Ereignisse über Ereigniskanäle austauschen (siehe Abbildung 5.16). Ein EPN kennzeichnen dabei die folgenden Eigenschaften [102]: • Kommunikation zwischen EPAs In EPNs können EPAs miteinander kommunizieren. Dabei erfolgt die Kommunikation ausschließlich über den Austausch von Ereignissen. Der Mechanismus, mit dem Ereignisse zwischen den EPAs verteilt werden, hängt von der eingesetzten Plattform ab. Normalerweise kann ein EPA Ereignisse eines bestimmten Ereignistyps an einen anderen, an diesem Typ interessierten EPA schicken. • Modularisierung der Regeln EPNs integrieren mehrere leichtgewichtige EPAs mit wenigen Regeln zu einem mächtigen Gesamtsystem. Damit bieten sie ein Konzept zur Modularisierung und Strukturierung der Ereignisverarbeitungsregeln. Hierbei entspricht ein einzelner EPA einem Modul und das EPN der Integrationsplattform. Die Funktionsweise eines einzelnen EPA mit wenigen Regeln ist sehr viel leichter zu verstehen als ein monolithisches Regelsystem mit der Gesamtheit der Regeln. Die Abgrenzung der EPAs erfolgt dabei hauptsächlich nach fachlichen Gesichtspunkten. Ein 27

In den Regelinterpretern gelten deshalb Vorrangrelationen oder es lassen sich Prioritäten für einzelne Regeln festlegen, beispielsweise in Jess [60]. 28 Der Abschnitt 3.2.2 diskutiert ausführlich die herausragende konzeptionelle Bedeutung von Event Processing Networks für die Realisierung von leistungsstarken CEP-Anwendungen für den praktischen Einsatz.

5.6 Event Processing Networks

143

EPA enthält diejenigen Regeln, die einen bestimmten fachlichen Arbeitsschritt oder eine Geschäftsaufgabe durchführen, siehe auch die Diskussion der starken Kohäsion und losen Kopplung in Abschnitt 3.2.2. • Sequenzieller Kontrollfluss Ein EPN führt zu einem teilweise sequenziellen Kontrollfluss innerhalb des CEPSystems. Erst nachdem ein EPA ein Muster in seinem Ereignisstrom erkannt hat, reicht er seine Erkenntnisse in Form eines komplexen Ereignisses an einen anderen EPA weiter, der dann die Verarbeitung fortführt. Die sequenzielle Verarbeitung entspricht einer schrittweisen Verarbeitung der Ereignisse und macht die CEP-Komponente verständlicher und somit besser wartbar. • Physikalische Verteilung Weiterhin ist es aufgrund der Netzstruktur eines EPN einfach möglich, die EPAs auf verschiedene Hardwarekomponenten zu verteilen. Diese physikalische Verteilung ermöglicht eine bessere Skalierbarkeit bei Performance-Problemen, insbesondere wenn hochfrequente Ereignisströme verarbeitet werden müssen. Meist muss das Versenden der Ereignisse über das Netzwerk selbst implementiert werden. In Abhängigkeit von der vorhandenen Systeminfrastruktur und den gegebenen Anforderungen können beispielsweise Message-oriented Middleware (MOM), Web Services, RMI (Remote Method Invocation) oder CORBA eingesetzt werden.

Server 2

Server 1

EPA 1 Regeln

EPA 2

EPA 6

Regeln

Regeln

EPA 3 Regeln

Server 3 EPA 4

EPA 5

Regeln

Regeln

Abb. 5.16 Physikalische Verteilung eines Event Processing Network auf mehrere Server

Die Abbildung 5.16 zeigt ein Beispiel-EPN, das auf drei verschiedenen Serversystemen verteilt ist. Jeder EPA besitzt seine eigene Regelbasis und reicht Ereignisse an andere EPAs weiter. Die Kommunikation kann server-intern geschehen, wie beispielsweise zwischen EPA1 und EPA2, oder auch plattformübergreifend, wie zwischen EPA2 und EPA6. Beispielsweise kann in einem Verkehrskontrollsystem ein EPA dafür zuständig sein, Verkehrsdaten auszuwerten, ein anderer wiederum enthält die Regeln, um Verkehrsprobleme, wie Staus oder Unfälle, zu identifizieren. Das Beispiel zeigt auch, dass es Zyklen in EPNs geben kann. Beispielsweise können Ereignisse, die einen

144


erkannten Stau anzeigen, wieder in das EPN zurückfließen, wo dann weitere Rückschlüsse gezogen werden. Dynamische EPNs Die Topologie eines EPN kann sich gegebenenfalls dynamisch ändern. Während der Laufzeit lassen sich neue EPAs erzeugen und nicht benötigte EPAs wieder freigeben. Zum Beispiel könnten bei Performance-Problemen einige der vorhandenen EPAs vervielfacht werden, um Lastspitzen abzufangen. Darüber hinaus sind auch die Ereigniskanäle, also die Verbindungen zwischen den EPAs, dynamisch änderbar. Ein häufig eingesetztes Verfahren ist das Contentbased Routing (inhaltsbasierte Verteilung) [41] (siehe Abbildung 5.17).

content-based Routing

Ereigniskanäle

Abb. 5.17 Content-based Routing

Beim Content-based Routing entscheidet der Ereignistyp oder -inhalt darüber, an welchen EPA ein Ereignis weitergeleitet wird. In einem System zum Aktienhandel könnten z.B. Kursereignisse eines speziellen Typs an den EPA geschickt werden, der sich auf Aktien dieses Typs (Technologiewerte, Rohstoffe usw.) spezialisiert hat. EPNs in Esper In Esper lassen sich relativ einfach Event Processing Networks aufbauen, indem mehrere Event Processing Agents als Esper-Instanzen erzeugt werden, die untereinander Ereignisse austauschen. Bereits der vorherige Abschnitt hat gezeigt, wie sich EPAs in Esper erzeugen lassen. Hier noch einmal der zugehörige Code: 1 2

E P S e r v i c e P r o v i d e r epa1 = E P S e r v i c e P r o v i d e r M a n a g e r . g e t P r o v i d e r ( " EPA1 " ) ;

Unter dem eindeutigen Namen “EPA1“ wird ein neuer Event Processing Agent erzeugt, der dann – wie in Abschnitt 5.5 gezeigt – mit Regeln versorgt werden kann. Nachfolgende Aufrufe von getProvider("EPA1") liefern jeweils eine Referenz auf genau diesen EPA.

5.7 Realisierungsplattformen und Sprachtypen

145

Das Versenden eines Ereignisses an einen anderen EPA kann in Esper nur in einem Subscriber-Objekt angestoßen werden.29 Dies geschieht in zwei Schritten, wie der folgende Code zeigt. 1 2 3 4 5 6 7 8

public c l a s s MySubscriber { p u b l i c v o i d u p d a t e ( MyEvent e v e n t ) { E P S e r v i c e P r o v i d e r epa2 = E P S e r v i c e P r o v i d e r M a n a g e r . g e t P r o v i d e r ( "EPA2 " ) ; EPRuntime epa2Runt i m e = epa2 . get EPRunt i m e ( ) ; epa2Runt i m e . s e n d E v e n t ( e v e n t ) ; } }

Zunächst wird eine Referenz auf den Ziel-EPA erzeugt (Zeilen 3-4). Anschließend wird für diesen EPA das zugehörige Laufzeitobjekt vom Typ EPRuntime beschafft, das die Methode sendEvent(event) zur Verfügung stellt. Mit dieser Methode lassen sich dann Ereignisse an den Ziel-EPA senden. Befindet sich der Ziel-EPA auf einem entfernten Rechner, dann ist es notwendig, das Ereignis zunächst an diesen Rechner zu schicken, beispielsweise über eine Message-oriented Middleware (MOM) oder einen Web Service. Dort kann das Ereignis von einer speziellen Verteilungs- (oder Dispatcher-)Klasse (vgl. [6]) gelesen und mithilfe der oben gezeigten Java-Methoden an den gewünschten EPA geschickt werden.

5.7 Realisierungsplattformen und Sprachtypen Die ersten EDA-Plattformen entstanden an Hochschulen und Forschungseinrichtungen und wurden meist nur in einzelnen, speziellen Projekten eingesetzt [8, 115, 116]. Sie sind in der Regel noch nicht besonders ausgereift. Insbesondere beim Laufzeitverhalten, bei der zur Verfügung stehenden Dokumentation und den Entwicklungswerkzeugen gibt es entsprechende Defizite. Weil seit einiger Zeit das Fachgebiet Event-Driven Architecture jedoch immer mehr ins allgemeine Interesse rückt [98], steht mittlerweile eine Vielzahl von kommerziellen CEP-Produkten für den praktischen Einsatz zur Verfügung. Dabei gibt es eine Reihe von kleinen Spezialanbietern wie Coral8 [20], Aleri [2], UC4 [109], StreamBase [104] oder auch die schon vorgestellte Open-Source-Plattform Esper [34]. Darüber hinaus haben sich inzwischen auch die etablierten Middleware-Anbieter des Themas angenommen. Eine Studie der Forrester Research Group [72] nennt die Plattformen Progress Apama [89], TIBCO Business Events [108], IBM WebSphere Business Events [52] und Oracle Event-Driven Architecture Suite [83] als die derzeit führenden Produkte. Zurzeit entwickelt sich der Markt noch sehr dynamisch und es ist noch nicht abzusehen, welche Produkte sich langfristig durchsetzen werden. Erst recht gibt es 29

Oder in einem – hier nicht behandelten – Listener-Objekt, siehe die Esper-Dokumentation [35].

146


noch keine Standards, so dass die Produkte sehr heterogen sind. Im Wesentlichen bietet eine CEP-Plattform die beiden folgenden Komponenten an: 1. eine proprietäre Event Processing Language (EPL) als Ereignisverarbeitungssprache, mit deren Hilfe sich Ereignisse, Ereignismuster und Regeln beschreiben lassen, sowie 2. einen spezifischen Regelinterpreter, der als Laufzeitumgebung für die Ereignisregeln dient und die Ereignisströme verarbeitet. Als Bezeichnung für Regelinterpreter, die speziell auf die Anforderungen von CEP ausgelegt sind, hat sich der Fachbegriff Event Processing Engine (oder CEP-Engine) etabliert. Dabei werden zwei Entwurfsziele angestrebt. Zum einen muss ein extrem hoher Durchsatz erreicht werden, d.h., die Verarbeitung von mehreren hunderttausend Ereignissen pro Sekunde soll möglich sein, zum anderen sollen die Latenzzeiten für die Reaktion auf Ereignisse möglichst kurz sein. Sprachtypen Die von den Plattformen zur Verfügung gestellten EPLs unterscheiden sich aus konzeptioneller Sicht zum Teil sehr deutlich. Im Wesentlichen lassen sich zwei Arten von Sprachen unterscheiden: 1. Continuous Query Languages (CQL) als SQL-ähnliche Abfragesprachen für Ereignisströme und 2. allgemeine Regelsprachen Continuous Query Languages Ereignissprachen vom Typ Continuous Query Language (CQL) [7, 9] sind ganz speziell auf die Verarbeitung von Ereignisströmen ausgerichtet und stark an die Syntax von SQL-Abfragen angelehnt. Es gibt allerdings auch einige bedeutsame Unterschiede zwischen CQL und SQL: CQL-Abfragen werden nicht einmalig auf einem statischen Datenbestand, sondern kontinuierlich auf permanent einfließenden Datenströmen ausgeführt. Zurzeit gibt es keinen allgemeinen Sprachstandard für CQLs, trotzdem bieten die meisten kommerziellen Produkte eine eigene CQL zur Ereignisverarbeitung an. Die in diesem Kapitel vorgestellte Esper-EQL ist dabei ein typisches Beispiel für eine Continuous Query Language. Wie bereits aus der Einführung von Esper deutlich wird, existieren einige signifikante Erweiterungen von CQL gegenüber SQL. Die CQL-Sprachen ermöglichen die Definition von Sliding Windows und bieten die Möglichkeit, Ereignismuster mit temporalen Abhängigkeiten zu definieren. CQL-Sprachen sind in der Regel relativ einfach zu lernen, weil sie stark an SQL angelehnt sind. Zudem ist SQL eigentlich die einzige deklarative Sprache, die zum “Allgemeingut“ der meisten Softwareentwickler gehört, was ein wesentlicher Pluspunkt für die Akzeptanz von CQL ist. Somit ist die Hürde, die Softwareentwicklung mit einer CQL zu beginnen, recht niedrig. Allerdings vermischen CQL-Sprachen – wie auch das Beispiel Esper zeigt – meist verschiedene Konzepte und Paradigmen. Zum einen erfolgt eine Vermischung der SQL-Syntax mit speziellen Operatoren einer Ereignisalgebra, zum anderen

5.7 Realisierungsplattformen und Sprachtypen

147

kommen weitere Konzepte wie Sliding Windows und Listener/Subscriber zum Auslösen von Aktionen hinzu. Dadurch werden CQL-Regeln oft etwas unübersichtlich und schwer zu verstehen. Allgemeine Regelsprachen Allgemeine Regelsprachen (rule languages) wie zum Beispiel Jess [60], ILOG JRules [53] oder JBoss Drools [54] sind nicht speziell auf die Verarbeitung von Ereignisströmen, sondern auf die Abbildung von Geschäftsregeln (business rules) ausgerichtet. Diese Sprachen besitzen eine homogene Syntax und beschreiben deshalb die gewünschten Ereignisregeln meist strukturierter und klarer verständlich als CQL-Sprachen. Zudem sind Aktionen unmittelbar mit den Bedingungen verbunden. Um einen ersten Eindruck dieses Sprachtyps zu vermitteln, wird exemplarisch eine Jess-Regel vorgestellt. Die allgemeine Struktur einer Regel zeigt der folgende Code. Der Bedingungs- und der Aktionsteil einer Regel werden syntaktisch durch einen Pfeil ⇒ getrennt. Wenn alle Bedingungen links des Pfeils ⇒ erfüllt sind, werden die Aktionen ausgeführt. 1 2 3 4 5

( d e f r u l e M ei neRegel ( Bedi ngung 1 ) ( Bedi ngung 2 ) . . . ( Bedi ngung N) ⇒ ( A k t i o n 1 ) . . . ( A k t i o n M) )

Die nachfolgende Regel namens buySignal veranschaulicht nun, wie eine Regel in der Praxis aussehen kann. Sie vergleicht zwei StockEvent-Ereignisse, die jeweils die Attribute time, symbol und price besitzen, auf die mit entsprechenden Aliasnamen (t1, s1, p1) bzw. (t2, s2, p2) zugegriffen werden kann (Zeilen 2-3). Damit die Regel feuert, müssen drei Bedingungen erfüllt sein:30 1. Die beiden StockEvent-Ereignisse treten zeitlich hintereinander auf, d.h. t2 ist größer als t1 (Zeile 4). 2. Beide Ereignisse beziehen sich sich auf das selbe Symbol (Zeile 5). 3. Es muss eine Preissteigerung von 20% vorliegen (Zeile 6).

1 2 3 4 5 6 7 8

( d e f r u l e buySignal ( S t o c k E v e n t ( t i m e ? t 1 ) ( sym bol ? s1 ) ( p r i c e ? p1 ) ) ( S t o c k E v e n t ( t i m e ? t 2 ) ( sym bol ? s1 ) ( p r i c e ? p2 ) ) ( t e s t (> ? t2 ? t1 )) ( t e s t (= ? s1 ? s2 ) ) ( t e s t ( > ? p2 ( 1 . 2 ∗ ? p1 ) ) ) => a s s e r t ( BuyEvent ( sym bol ? s1 ) ) )

30 Jess nutzt für die Spezifikation von Bedingungen die polnische Notation und stellt die Operator (hier beispielsweise “>“) vor die Operanden (hier t2 und t1).

148


Falls zwei StockEvent-Ereignisse auftreten, die den Bedingungsteil erfüllen, feuert die Regel und im Aktionsteil wird ein BuyEvent erzeugt, mit dem entsprechenden Symbol als Attribut (Zeile 7). Eine ausführliche und gut lesbare Einführung in Jess bietet [42]. Ein großer Nachteil von allgemeinen Regelsprachen ist typischerweise das Fehlen von Sprachkonstrukten, um die vielfältigen zeitlichen Aspekte zwischen Ereignissen unmittelbar abzubilden. Deshalb müssen Sliding Windows, das NichtAuftreten von Ereignissen und weitere temporale Abhängigkeiten zwischen Ereignissen mit entsprechendem Aufwand selbst implementiert werden [33]. Insgesamt ist die Definition von Ereignismustern damit schwieriger und umständlicher. Darüber hinaus sind allgemeine Regelsysteme nicht auf die effiziente Verarbeitung von hochfrequenten Ereignisströmen ausgerichtet. Allgemeine Regelsysteme wie Jess verwenden den RETE-Algorithmus, der keine der in einer Ereignisalgebra benötigten temporalen Operatoren zulässt. Aktuell gibt es aber einige Arbeiten zur Integration temporaler Abhängigkeiten in den RETE-Algorithmus [12], [97] und [114]31 . Weil die Werkzeuge einer kontinuierlichen Weiterentwicklung unterliegen, wird auf einen Vergleich an dieser Stelle verzichtet. Der aktuelle Stand und die Unterschiede zwischen den verschiedenen Plattformen werden u.a. in [14], [33] und [46] detaillierter untersucht. Neuere Entwicklungen Die Entwicklung neuer und eigener Sprachen für Complex Event Processing ist ein aktuelles und sehr aktives Forschungsfeld und es gibt eine Anzahl an Vorschlägen für neue Ereignisverarbeitungssprachen [1, 30, 47]. Diese Sprachen setzen sich aber bisher in der Praxis noch nicht durch, in der Regel, weil sie keine entsprechende Produktreife besitzen. Trotzdem bieten diese Vorschläge eine Reihe von innovativen Ideen und interessanten Ansätzen. Mittlerweile gibt es auch erste Ansätze, in allgemeinen Regelsprachen temporale Konzepte für die Verarbeitung von Ereignisströmen zu integrieren und sie so für die Entwicklung einer CEP-Komponente attraktiv zu machen. Der im Open-SourceProjekt JBoss enthaltene Regelinterpreter Drools wurde jüngst für die Verarbeitung von Ereignisströmen erweitert. Das Projekt Drools Fusion [55] erweitert die bisherige allgemeiner Regelsprache um Sliding Windows und weitere temporale Aspekte hin zu einer Event Processing Language. Generelles Ziel der Sprachentwicklung für die Ereignisverarbeitung ist es, mächtigere Sprachen zu schaffen, die die Entwicklung von EDA-basierten Systemen vereinfachen. Aktuell weisen die meisten existierenden Sprachen noch einige Unzulänglichkeiten auf: • Die Sprachen zur Beschreibung von Ereignismustern sollten homogener sein und nicht verschiedene Sprachparadigmen vermischen. 31

Der RETE-Algorithmus ist ein effizientes Verfahren zur Erkennung von Mustern in regelbasierten Expertensystemen.


149

• Es sollten mächtigere Sprachkonstrukte zur Beschreibung von Korrelationen zur Verfügung stehen. • Die Modellierung der Ereignisregeln sollte durch graphische Spezifikationssprachen vereinfacht werden [95, 101]. • Die meisten EPLs sind auf die Definition von Ereignismustern eingeschränkt. Sie unterstützen nicht den Entwurf und die Ausführung von Event Processing Networks als Netzwerk von interagierenden CEP-Engines. Generell lassen sich die zurzeit vorhandenen Systeme gut nutzen, um Complex Event Processing in EDA-basierten Anwendungssystemen zu implementieren. Allerdings befinden sich die zur Verfügung stehenden Sprachkonstrukte noch auf relativ niedrigem Abstraktionsniveau. Um die Entwicklung von EDA-basierten Systemen für die Zukunft zu vereinfachen, wären mächtigere Sprachen zur Ereignisverarbeitung wünschenswert. Es gibt durchaus einige Ansätze für neue Event Processing Languages. Beispielsweise wird in [48] eine Sprache vorgestellt, die die Definition von Ereignismodellen und die Konstruktion von EPNs innerhalb der Sprache zulässt. Die Sprache wird mithilfe einer modellgetriebenen Softwareentwicklung [87, 103] auf Esper abgebildet.

5.8 Fallstudie: Verkehrskontrolle und -steuerung Anhand der Fallstudie eines Verkehrskontrollsystems wird zum Abschluss dieses Kapitels vorgestellt, wie die eingeführten Konzepte der Ereignisverarbeitung in einem größeren fachlichen Zusammenhang angewendet werden können. Das Verkehrskontrollsystem soll auf Basis der von den Sensoren gemessenen Verkehrsdaten die aktuelle Verkehrslage analysieren und sich anbahnende Probleme zeitnah erkennen, um so angemessene Reaktionen bzw. verkehrsleitende Maßnahmen vorschlagen zu können. Weil das System Entscheidungsträger bei ihrer Arbeit unterstützt, gehört es zur Kategorie der Decision Support Systems bzw. Entscheidungsunterstützungssysteme. Die Darstellung in diesem Abschnitt orientiert sich an [26] und [86]. Die Umsetzung des CEP-Systems erfolgt in zwei Schritten: dem Entwurf des Event Processing Network (in Abschnitt 5.8.1) sowie der Vorstellung einiger exemplarischer Ereignisregeln (in Abschnitt 5.8.2).

5.8.1 Event Processing Network des Verkehrskontrollsystems Der Ausgangspunkt für die Architektur des Event Processing Network ist das in Abschnitt 4.5 präsentierte Ereignismodell. Die Abbildung 5.18 zeigt noch einmal eine etwas vereinfachte Variante des Modells mit den Ereignistypen und Attributen, die für die Fallstudie notwendig sind.

150

5 Ereignisverarbeitung Abstract Event eventID timestamp

Sensor Event sensorID location

Loop Detector Event velocity

aggregates

*

Traffic Data Event density occupancy averageSpeed

Sensor Behavior Event sensorID averageSpeed

reasonedOn

*

Road Area Event roadArea

Problem Event severity

Traffic Jam Event sensorID velocity

Abb. 5.18 Vereinfachtes Ereignismodell mit den im Beispiel verwendeten Ereignistypen

Das Ereignismodell bildet den Abstraktionsprozess aus Abbildung 4.10 ab. Die Abstraktionsschritte beim Übergang von einer Abstraktionsebene in die nächste Ebene entsprechen den verschiedenen Phasen der Ereignisverarbeitung: Sensordaten lassen sich zu qualitativen Verkehrsdaten verdichten, aus denen sich dann qualitative Problemdaten ableiten lassen. Im Verkehrskontrollsystem muss also die folgende Ereignistransformation durchgeführt werden: SensorEvent → TrafficDataEvent → ProblemEvent Die erforderlichen Ereignistransformationen bestimmen die Struktur des Event Processing Network. Für jeden einzelnen Transformationsschritt ist ein dedizierter Event Processing Agent mit eigenem Regelinterpreter und eigener Regelbasis verantwortlich. Das EPN zerlegt also die Ereignisverarbeitung in einzelne hintereinandergeschaltete Schritte.32 Abbildung 5.19 zeigt die Struktur des EPN für das Verkehrskontrollsystem mit den folgenden EPAs. Sensor Processing Agent Der Sensor Processing Agent verarbeitet die von den Sensoren gelieferten Loop Detector Events. Weil die Sensoren nicht eigenständig Ereignisobjekte erzeugen und den EPAs zustellen können, übernehmen diese Aufgabe spezielle Softwarekomponenten, die sogenannten In-Adapter. Diese Softwarekomponenten lesen die Sensordaten, transformieren sie in Ereignisobjekte und senden diese dann an den Sensor Processing Agent. In-Adapter werden in Abschnitt 6.2 des folgenden Kapitels genauer vorgestellt. Der Sensor Processing Agent führt mit entsprechenden Verarbeitungsregeln nun die folgenden Schritte durch: 32 In anderen Anwendungsszenarios können die Übergänge zwischen verschiedenen EPAs auch komplizierteren Vorgaben folgen.


151 Verkehrsnetzwerk (Induktionsschleifen)

EPN - Verkehrssteuerungssystem Sensor Processing Agent

Loop Detector Events

Traffic Analysis Agent

Bereinigung

Aggregierung

Filtern

Kontextanreicherung

Sensor Behavior Events Road Area Events

Ereignisfluss

Problemdiagnose Traffic Jam Events

Operative Systeme Strukturelle Daten

Diagnosis Agent

Historische Daten

Dienstaufruf

Aktionsplanung Datenfluss

Abb. 5.19 Event Processing Network für das Verkehrskontrollsystem

1. Schritt: Bereinigung Zunächst erfolgt ein Bereinigungsschritt (cleaning), um inkonsistente Ereignisobjekte zu erkennen und zu behandeln. Die Anforderungen an korrekte Ereignisobjekte sind durch die Constraints des Ereignismodells definiert. Zum Beispiel dürfen Loop Detector Events keine negativen Geschwindigkeitswerte aufweisen und müssen ggf. korrigiert bzw. entfernt werden. 2. Schritt: Filterung Anschließend kann der Sensor Processing Agent einen Filterungsschritt (filtering) durchführen. So sind Sensorereignisse mit Nullwerten, in denen kein Fahrzeug beobachtet werden konnte, ggf. ohne Interesse und können herausgefiltert werden. Das Filtern von Ereignissen kann in Esper nicht dadurch geschehen, dass der EPA die betroffenen Ereignisse einfach aus dem Ereignisstrom entfernt. Stattdessen leitet der EPA nur diejenigen Ereignisse an andere EPAs weiter, die auch für die Empfänger von Interesse sind. Dazu werden Filterregeln, wie select * from LoopDetectorEvent where velocity > 0, definiert. Das zugehörige Subscriber-Objekt wird bei jedem Ereignis, das diese Filterbedingung erfüllt, aufgerufen und sendet dann das Ereignis an den nächsten EPA weiter. Alle anderen Ereignisse werden nicht weitergereicht und in diesem Sinne herausgefiltert.

152


Traffic Analysis Agent Der Traffic Analysis Agent verarbeitet die eintreffenden, nun konsistenten Loop Detector Events, um daraus aussagekräftige numerische Verkehrskennzahlen in Form von Traffic Data Events abzuleiten. Weil einzelne von den Sensoren stammende Ereignisse zu feingranular sind, werden sie aggregiert, um die aktuelle Verkehrslage beurteilen zu können. Dabei kann die Aggregation im Szenario der Fallstudie in zweierlei Dimensionen durchgeführt werden. Der Traffic Analysis Agent erzeugt in einem Korrelationsschritt zeitlich korrelierte Sensor Behavior Events sowie räumlich korrelierte Road Area Events. 1. Sensor Behavior Events fassen die Sensorereignisse an einem bestimmten Sensor sx über einen definierten Zeitraum [t1 ,tn ] zusammen. So lässt sich die Durchschnittsgeschwindigkeit an diesem Sensor aus allen in dem Zeitintervall gemessenen Geschwindigkeiten v(sx ,t1 ), v(sx ,t2 ), v(sx ,t3 ), . . . , v(sx ,tn ) berechnen. Das Zusammenführen von Ereignissen über einen Zeitraum stellt eine zeitliche Korrelation (temporal correlation) dar. 2. Road Area Events aggregieren die Loop Detector Events, die zu einem bestimmten Zeitpunkt ty an räumlich benachbarten Orten x1 , x2 , . . . , xn stattgefunden haben.33 Zum Beispiel wird die Durchschnittsgeschwindigkeit über alle an einem bestimmten Straßenabschnitt befindlichen Sensoren berechnet v(sx1 ,ty ), v(sx2 ,ty ), . . . , v(sxn ,ty ). Das Zusammenführen von ortsnahen Ereignissen stellt eine räumliche Korrelation (spatial correlation) dar. Darüber hinaus führt der Traffic Analysis Agent in dem Beispiel einen Anreicherungsschritt mit Kontextdaten (content enrichment) durch. In diesem Schritt werden die von den Sensoren gemessenen quantitativen Geschwindigkeitswerte in qualitative Maße abgebildet. Eine gemessene Geschwindigkeit von 50 km/h kann erst in Bezug zur zulässigen Höchstgeschwindigkeit bewertet werden. Dazu greift der Traffic Analysis Agent auf die operativen Verkehrsleitsysteme zu und vergleicht die gemessenen Geschwindigkeiten mit den dort verwalteten Daten über das Verkehrsnetz. Die so bestimmten Verkehrskenngrößen können auch an die operationalen Systeme geschickt werden, um sie dort als historische Daten vorzuhalten. Aus diesen Daten kann das “normale“ Verkehrsverhalten abgeleitet werden, das zur Erkennung von Problemen hilfreich ist. Diagnosis Agent Der Diagnosis Agent verarbeitet die eingehenden Sensor Behavior Events und Road Area Events und versucht in einem Analyseschritt aus den Daten dieser Ereignisströme aufkommende Verkehrsprobleme – wie z.B. Staus – zu identifizieren. Letztendlich versucht dieser EPA, kritische Muster in den Ereignisströmen zu erkennen 33

Häufig ist für die räumliche Korrelation von Sensoren auch eine Anreicherung der Ereignisse durch den Zugriff auf geographische Daten notwendig. Zum Beispiel für die Feststellung, ob zwei Sensoren in benachbarten Straßenabschnitten liegen.


153

und ggf. Problem Events, wie beispielsweise Traffic Jam Events, zu erzeugen. Problem Events sind komplexe Ereignisse (complex events), weil sie nicht nur mittels einfacher arithmetischer Operationen entstehen, sondern auf Basis von komplexen Regeln, die Expertenwissen repräsentieren. Wenn ein Problem identifiziert worden ist, muss in einem entsprechenden Planungsvorgang (action planning) eine angemessene Reaktion angestoßen werden. Dies ist nicht Teil der eigentlichen Ereignisverarbeitung, sondern geschieht in den operativen Systemen. Vorteile des EPN Die Verteilung der Ereignisregeln auf verschiedene EPAs bietet zwei wesentliche Vorteile: 1. Jeder EPA übernimmt eine eng umrissene Aufgabe mit einer relativ kleinen Anzahl von Regeln und führt damit zu einer verbesserten Kohäsion. 2. Weiterhin lassen sich die EPAs auf mehrere virtuelle oder physikalische Server verteilen und so die Skalierbarkeit des Systems verbessern.

5.8.2 Ereignisregeln im Verkehrskontrollsystem Dieser Abschnitt zeigt exemplarisch wie sich in Esper Verarbeitungsregeln formulieren lassen. Die hier vorgestellten Regeln orientieren sich an den wesentlichen Verarbeitungsschritten, die in Abbildung 5.19 dargestellt sind. 1. Schritt: Bereinigen und Filtern Das Bereinigen und Filtern der von den Sensoren eingehenden Ereignisse kann im Sensor Processing Agent durch die folgende einfache Filterregel realisiert werden. Dieses Ereignismuster erfüllen alle LoopDetectorEvent-Objekte, deren Geschwindigkeitswert größer als 0 ist. 1 2 3

select ∗ from LoopDetectorEvent where v e l o c i t y > 0

Die zugehörige Subscriber-Klasse schickt jedes Ereignis, das das Muster erfüllt, an den Traffic Analysis Agent. Dazu wird eine Instanz des Traffic Analysis Agent beschafft (Zeilen 3-4), an die das Ereignis gesendet wird (Zeilen 5-6). 1 2 3 4 5 6 7 8

public c l a s s SensorAgentSubscriber { public void update ( LoopDetectorEvent event ){ EPServiceProvider tra fficAn alysisAg en t = EPServiceProviderManager . get Provi der ( " t r a f f i c A n a l y s i s " ) ; EPRuntime r u n t i m e = t r a f f i c A n a l y s i s A g e n t . get EPRunt i m e ( ) ; runtime . sendEvent ( event ) ; } }

154


2. Schritt: Aggregation und Anreicherung Der Traffic Analysis Agent aggregiert die ankommenden LoopDetectorEventEreignisse und berechnet aus ihnen aussagekräftige Verkehrskennzahlen. Das folgende Beispiel erzeugt neue SensorBehaviorEvent-Ereignisse, die die Durchschnittsgeschwindigkeiten an einem Sensor berechnen. Dazu wird ein Zeitfenster von 5 Minuten betrachtet, wobei durch groupBy(sensorID) die Durchschnittsberechnung für jede sensorID getrennt durchgeführt wird. Die Regel setzt ein Batch-Fenster ein, damit die Berechnungen nur alle 5 Minuten und nicht nach jedem Eintreffen eines Loop Detector Event durchgeführt werden.

2 3 4

i n s e r t i nto SensorBehaviorEvent ( sensorID , averageSpeed ) s e l e c t s e n s o r I D , R o u t e N e t . e v a l u a t e ( s e n s o r I D , avg ( v e l o c i t y ) ) from L o o p D e t e c t o r E v e n t . s t d : groupBy ( s e n s o r I D ) . win : t i m e _ b a t c h ( 5 min ) group by s e n s o r I D

Die Esper-Regel führt auch einen Anreicherungsschritt mit Kontextwissen durch. In der Select-Klausel wird die Methode evaluate() aufgerufen, die von einer Verwaltungsklasse (hier: RouteNet) zur Verfügung gestellt wird. Die Methode liefert eine qualitative Bewertung der errechneten Durchschnittsgeschwindigkeit (avg(velocity)) an einem bestimmten Ort (sensorID). Eine mögliche Kategorisierung wäre zum Beispiel {SLOW, NORMAL, FAST}. 3. Schritt: Problemdiagnose Der fachlich anspruchsvollste Schritt erfolgt im Diagnosis Agent, um aus den Verkehrskennzahlen sich anbahnende Problemsituationen zu erkennen (und möglichst proaktiv Steuerungsmaßnahmen einzuleiten). Wie bereits in Abschnitt 3.4 dargestellt, können Verkehrsprobleme als Abweichungen vom “normalen“ Verhalten verstanden werden. Die Abbildung 3.12 zeigt die verschiedenen Kategorien und Dimensionen der Problemdiagnose. Ebenen der Problemerkennung Sprunghafte Veränderung

Dimensionen der Problemerkennung zeitlich räumlich Geschwindigkeit pro Abschnitt

Geschwindigkeit

1

abrupte Änderung

40 39

18 40 42

Zeit

Abb. 5.20 Sprunghafte Änderung der Geschwindigkeit

abrupte Änderung


155

• Die Verletzung von vorgegebenen Schwellenwerten, beispielsweise das Absinken der Durchschnittsgeschwindigkeit unter einen definierten Wert, kann z.B. einen Stau signalisieren. • Sprunghafte Unterschiede der gemessenen Geschwindigkeiten zu aufeinanderfolgenden Zeitpunkten oder an benachbarten Sensoren lassen ebenfalls auf Probleme schließen. • Schließlich sind noch Entwicklungstrends von Interesse, wenn beispielsweise die beobachteten Geschwindigkeiten in einem Zeitraum oder in benachbarten Streckenabschnitten kontinuierlich sinken. In diesem Abschnitt soll nur eines dieser Probleme herausgegriffen werden, nämlich wie ein sprunghafte Änderung der Geschwindigkeit erkannt werden kann (siehe Abbildung 5.20). Die entsprechende Esper-Regel sieht folgendermaßen aus. 1 2 3 4 5 6 7 8

i n s e r t i n to Traffi cJam Event ( ‘hi gh‘ , sensorID , v e l o c i t y ) s e l e c t s2 . s e n s o r I D , s2 . a v e r a g e S p e e d from p a t t e r n [ e v e r y ( s1 = S e n s o r B e h a v i o r E v e n t −> s2 = S e n s o r B e h a v i o r E v e n t ( s e n s o r I D = s1 . s e n s o r I D ) ) where t i m e r : w i t h i n ( 1 min ) ] where s1 . a v e r a g e S p e e d = ’FAST ’ and s2 . a v e r a g e S p e e d = ’SLOW’

Das Ereignismuster zum Erkennen eines Geschwindigkeitsabfalls ist in den Zeilen 2 bis 8 spezifiziert. Es werden zwei innerhalb einer Minute aufeinanderfolgende SensorBehaviorEvent-Ereignisse s1 und s2 am selben Sensor betrachtet (Zeilen 3-7). Der kritische Geschwindigkeitsabfall wird dann angenommen, wenn sich innerhalb dieser einen Minute die Geschwindigkeit von ’FAST’ auf ’SLOW’ geändert hat. Erkennt die CEP-Engine dieses Muster im Ereignisstrom, so feuert die Regel und ein neues komplexes TrafficJamEvent-Ereignis wird erzeugt (Zeile 1). Das TrafficJamEvent-Ereignis signalisiert ein Verkehrsproblem und liegt somit auf der höchsten Abstraktionsebene. Das TrafficJamEvent-Ereignis enthält die qualitativen Problemdaten und kann als Nachricht an ein nachgelagertes Anwendungssystem gesendet werden und dort eine angemessene Reaktion auf das erkannte Problem einleiten.

Kapitel 6

Ereignisbehandlung

Zusammenfassung Auf erkannte Ereignisse und Ereignismuster muss selbstverständlich auch angemessen reagiert werden. Während die Ereignisverarbeitung die Muster erkennt und eine passende Reaktion auslöst, erfolgt die Ausführung der Reaktion in der Ereignisbehandlungsschicht. Dieses Kapitel grenzt die Verantwortlichkeiten der Behandlungsschicht klar von der Ereignisverarbeitung ab und beleuchtet die Integration sowie das Zusammenwirken der beiden Schichten. Besondere Beachtung erfährt das Auslösen und Unterbrechen von Geschäftsprozessen mittels Ereignissen sowie die Visualisierung von Ereignissen bei Tracking-and-Tracing- und BAM-Anwendungen. Die Fallstudie widmet sich den Systemkomponenten der Ereignisbehandlung in einem Verkehrsleitsystem.

6.1 Aufgaben der Ereignisbehandlung Bei der Entwicklung einer Event-Driven Architecture muss die eigentliche Behandlung der Ereignisse (event handling) von der Ereignisverarbeitung (event processing) sowohl logisch als auch physikalisch klar abgegrenzt sein. Diese Abgrenzung kommt in den logischen Schichten einer EDA1 zum Ausdruck. Die Verarbeitung von Ereignissen ist die Aufgabe des Complex Event Processing bzw. der CEP-Komponente und ist in der Regel in Form eines Event Processing Network (EPN) realisiert.2 Die Ereignisbehandlung hingegen erfolgt in einer nachgelagerten Schicht in den operationalen Systemen der jeweiligen Unternehmensanwendungen. Die Verantwortlichkeiten des Complex Event Processing und der operativen Anwendungssysteme lassen sich klar voneinander trennen.

1 2

Vgl. auch Abbildung 3.6. Siehe die Abschnitte 3.2.2 und 5.6.


157

158

6 Ereignisbehandlung

Verantwortlichkeiten des Complex Event Processing Die CEP-Komponente realisiert die Ereignisverarbeitung und besteht aus einem Netzwerk von leichtgewichtigen Event Processing Agents (EPAs), die mithilfe von Ereignisregeln nach signifikanten Mustern in den Ereignisströmen suchen. Die Komponente ist ausschließlich für die regelbasierte Verarbeitung von Ereignissen verantwortlich. Ereignismuster lassen sich, wie in Kapitel 5 vorgestellt, mit einer Event Processing Language (EPL) deklarativ und flexibel beschreiben. Darüber hinaus sind die zur EPL zugehörigen Regelinterpreter (Event Processing Engines) speziell auf die performante Verarbeitung dieser Regeln und extrem großer Ereignismengen ausgerichtet. Für das Beschreiben und Erkennen von Ereignismustern sind regelbasierte Sprachen prädestiniert. Allerdings stoßen regelbasierte Sprachen an ihre Grenzen, wenn Probleme algorithmisch behandelt werden müssen – die Lösung also aus einer fest vorgegebenen und klar strukturierten Folge von Verarbeitungsschritten besteht. Dies ist mit regelbasierten Sprachen nur sehr umständlich möglich, hierfür eignen sich imperative bzw. objektorientierte Programmiersprachen weitaus besser. Deshalb beschränkt sich die Aufgabe der CEP-Komponente auf das Erkennen und Verarbeiten von Mustern in großen Ereignismengen und das Anstoßen einer Reaktion. Aus diesen drei Schritten resultiert der in Abschnitt 3.1.1 eingeführte charakteristische Grundzyklus ereignisgesteuerter Systeme. Verantwortlichkeiten der operativen Systeme Die operativen Unternehmensanwendungssysteme sind dafür verantwortlich, alle Aktionen außerhalb der Ereignisverarbeitung auszuführen, die der Behandlung eines erkannten Ereignismusters dienen. Die operativen Systeme übernehmen also sämtliche Aufgaben der Ereignisbehandlung, die von der regelbasierten CEPKomponente nicht übernommen werden können. Folgende Fälle lassen sich unterscheiden: • Komplexe Algorithmen Die Maßnahmen der Ereignisbehandlung werden häufig durch einen Algorithmus beschrieben, der sich nicht oder nur sehr umständlich in Form von Ereignisregeln formulieren lässt. Eine Anwendung stellt einen Algorithmus typischerweise als Dienst zur Verfügung. Zum Beispiel muss bei einem Ereignis, das ein Verkehrsproblem anzeigt, ein komplexer Planungsalgorithmus durchgeführt werden, um die erforderlichen verkehrsregelnden Maßnahmen abzuleiten. • Ablauforientierte Prozesse Die fachlichen Geschäftsprozesse eines Unternehmens sind in den operativen Anwendungssystemen realisiert. Häufig sind Ereignisse bzw. Ereignismuster die Auslöser für die Initiierung oder Unterbrechung eines fachlichen Prozessablaufs. Die CEP-Komponente stößt einen Geschäftsprozess oder einen Teilprozess an, realisiert sind die Abläufe aber in den nachgelagerten Unternehmensanwendungen.

6.2 Integration der CEP-Komponente

159

• Zugriff auf Nachbarsysteme Die Behandlung von Ereignissen erfordert oft den Zugriff auf unternehmensinterne und -externe Nachbarsysteme, wobei abhängig von der eingesetzten Middleware entsprechende Protokolle zum Einsatz kommen. Der dazu erforderliche technische Integrationscode sollte auf jeden Fall außerhalb der CEPKomponente – nämlich in den operativen Systemen – implementiert sein. Zum Beispiel muss auf ein Kaufsignalereignis im Wertpapierhandel die gewünschte Transaktion in dem Handelssystem der entsprechenden Börse angestoßen werden. • Benutzerinteraktionen Jedwede Interaktion zwischen einem menschlichen Benutzer und dem System erfolgt über die graphischen Benutzungsoberflächen (GUI) der Anwendungssysteme. Einerseits werden relevante Ereignisse auf der Benutzungsoberfläche visualisiert, damit eine Reaktion außerhalb des IT-Systems erfolgen kann, z.B. das Anfordern eines Notarztes bei einem Unfall durch ein Warnmeldungsfenster. Andererseits gibt es Ereignisse, die eine Benutzereingabe erfordern, beispielsweise um die vom System getroffenen Entscheidungen explizit zu bestätigen. Ereignisbehandlung Die Ereignisbehandlung (event handling) ist die Aufgabe der operativen Anwendungssysteme (Backend-Systeme). Diese Systeme führen komplexe Algorithmen durch, realisieren ablauforientierte Geschäftsprozesse, greifen auf benachbarte Systeme zu und interagieren mit dem Benutzer. Die CEP-Komponente ist ausschließlich für das regelbasierte Erkennen von Mustern in den Ereignisströmen zuständig. Im Aktionsteil der Regeln wird die Behandlung von Ereignissen delegiert, d.h., es werden lediglich Dienste oder Prozesse angestoßen, aber keine komplexen Algorithmen oder größeren Abläufe realisiert.

6.2 Integration der CEP-Komponente Die Integration der Ereignisverarbeitungs- und der -behandlungsschicht hat entscheidende Bedeutung für das reibungslose Zusammenspiel der CEP-Komponente mit den operativen Unternehmensanwendungen. Die Abbildung 6.1 zeigt die wesentlichen Komponenten einer Integrationsarchitektur. Adapter und Schnittstellen Zur Kapselung (information hiding) der EDA-Schichten erfolgt die Kommunikation zwischen Ereignisquellen, -verarbeitung und -behandlung ausschließlich über Adapter und Schnittstellen. In der CEP-Komponente sowie in den operativen Syste-

160


men übernehmen dedizierte Adapter- und Schnittstellenklassen das eigentliche Versenden und Empfangen von Ereignisnachrichten3 (siehe Abbildung 6.1). Adapter- und Schnittstellenklassen übernehmen die technische Umsetzung des Zugriffs auf die Ereignisquellen und Ereigniskanäle. Die Kommunikation ist damit gekapselt und von den zentralen Aufgaben der Schichten – der Ereignisverarbeitung durch Complex Event Processing und der Ereignisbehandlung in den operativen Systemen – entkoppelt. Durch die Kapselung ist es auch möglich, die technische Realisierung der Ereigniskanäle zu verändern oder die Ereignisquellen auszutauschen, ohne dass sich dies auf die CEP-Komponente oder die operativen Systeme auswirkt.

Sensoren

In-Adapter

In-Adapter

Complex Event Processing EPN EPA2

EPA4

EPA3

EPA1 EPA5

EPA6

Out-Adapter

EPA7

Fassade

Ereigniskanäle

CEP-Schnittstelle

CEP-Schnittstelle

CEP-Schnittstelle

Visualisierung

Geschäftsprozesse

Informationssystem

Operative Systeme Sensorereignisse

Ausgangskanal

CEP-Ereignisse

Eingangskanal


Dienstaufruf

Abb. 6.1 Integration des Complex Event Processing mit den operativen Systemen 3 Diese Klassen übernehmen die klassischen Aufgaben von Stub- und Skeleton-Klassen in verteilten Systemen, siehe [28]. In [51] wird auch von Messaging Gateways gesprochen.


161

In-Adapter Oft sind Ereignisquellen, wie zum Beispiel Sensoren oder RFIDLesegeräte, technisch sehr einfache Geräte, die nicht in der Lage sind, selbständig Ereignisse an EPAs zu verschicken. Stattdessen stellen sie eine einfache API zum Lesen der ausgelösten Sensorereignisse zur Verfügung.4 Das Lesen von Randereignissen übernehmen spezielle Softwarekomponenten in der Ereignisverarbeitungsschicht, sogenannte In-Adapter (vgl. [63]), die die Sensor-API nutzen, um den technischen Zugriff auf die Ereignisquellen zu implementieren. Darüber hinaus transformieren die In-Adapter die gelesenen proprietären Ereignisdaten in ein Standardformat, das von den Event Processing Engines in den EPAs verstanden wird. Abschließend senden sie die Ereignisse an dedizierte EPAs im EPN. In Abbildung 6.1 sind dies die EPA1 und EPA3. Die Randereignisse werden also von der CEP-Komponente abgeholt und gelangen somit über einen Pull-Mechanismus, auf den Abschnitt 6.5 genauer eingeht, in das EPN. Out-Adapter Der Out-Adapter sorgt in der CEP-Komponente für das Versenden von Ereignisobjekten an die nachgelagerten operativen Systeme, damit dort entsprechende Maßnahmen durchgeführt werden. Der eigentliche Versand geschieht mithilfe von Ereigniskanälen (s.u.), die technisch unterschiedlich realisiert sein können. Um Ereignisse versenden zu können, müssen sie in der Regel in eine Text- oder XML-Nachricht serialisiert werden. Alternativ können EPAs auch direkt Dienste in den operativen Systemen aufrufen. Solche EPAs enthalten dann Regeln, deren Aktionsteil mit den operationalen Systemen kommuniziert. Grundsätzlich mögliche Technologien sind u.a. Java-RMI, CORBA und Web Services [28]. Im Beispiel in Abbildung 6.1 ruft EPA6 direkt einen Dienst auf, und EPA5 schickt Ereignisse über einen Out-Adapter an die operativen Systeme. Fassade Die Fassade ist in der CEP-Komponente für den Empfang von Ereignissen zuständig. Auch die operativen Anwendungssysteme können Ereignisse erzeugen, die die CEP-Komponente berücksichtigen soll. Beispielsweise könnte ein Warenwirtschaftssystem ein Ereignis an die CEP-Komponente schicken, sobald eine Ware vergriffen ist. Dazu entnimmt die Fassade dem Ereigniskanal Ereignisnachrichten, transformiert sie in Ereignisobjekte und schickt sie dann an den entsprechenden Event Processing Agent.5 In Analogie zu dem bekannten Entwurfsmuster aus dem Software Engineering [43] verbirgt die Fassade die komplexe Struktur des EPN, da die Außenwelt ausschließlich über die Fassade mit dem EPN kommuniziert. Änderungen innerhalb des EPN schlagen nicht nach außen durch. Die operativen Systeme kennen keine EPAs oder gar die Topologie des EPN.6 Da die operativen Systeme ihre Ereignisse selbständig an die CEP-Komponente senden, handelt es sich hier um einen Push-Mechanismus (vgl. Abschnitt 6.5). 4

Technisch kann der Zugriff beispielsweise über eine Socket-Verbindung [28] erfolgen. Eine Fassade ist in diesem Kontext eine spezielle Form eines In-Adapters. 6 Gegebenenfalls könnte auch ein dedizierter EPA die Rolle der Fassade spielen. Er wäre dann der Außenwelt bekannt und empfängt alle Ereignisse aus den operativen Systemen. 5

162


CEP-Schnittstellen In den jeweiligen operativen Anwendungssystemen übernehmen spezielle CEP-Schnittstellen die Kommunikation mit der CEP-Komponente. • Die CEP-Schnittstelle entnimmt dem Ereigniskanal die Ereignisse und transformiert sie in ein Format, das an das Zielanwendungssystem weitergereicht werden kann. Beispielsweise wird ein Ereignis in ein C++-Objekt überführt und anschließend einer aufgerufenen C++-Methode als Parameter übergeben. Dazu muss die CEP-Schnittstelle wissen, auf welche Methodenaufrufe die ankommenden Ereignisse abgebildet werden sollen.7 • Umgekehrt werden Geschäftsereignisse des operativen Systems an die CEPKomponente geschickt. Dazu werden sie in eine Nachricht verpackt und über einen Ereigniskanal an die Fassade der CEP-Komponente weitergeleitet. Diese Architektur entkoppelt das Complex Event Processing und die operativen Anwendungssysteme vollständig voneinander. Das CEP-System kennt nicht die operativen Systeme, es weiß nicht, wie die von ihm weitergeleiteten Ereignisse behandelt werden. Die Reaktion auf die Ereignisse ist vollständig und autonom den nachgelagerten Anwendungssystemen überlassen. Umgekehrt besitzen die operativen Systeme keinerlei Wissen über die Verarbeitung der Ereignisströme. Sie werden lediglich über die finalen Schlussfolgerungen der CEP-Komponente in Kenntnis gesetzt. Damit ist mit der in Abbildung 6.1 gezeigten Integrationsarchitektur eine eindeutige Trennung der Verantwortlichkeiten (separation of concerns) [29] erreicht. Ereigniskanäle Die CEP-Komponente und die Anwendungssysteme kommunizieren über Ereigniskanäle miteinander. Ereigniskanal Ein Ereigniskanal (event channel) ist eine technische Infrastruktur, um Ereignisse zwischen den Schichten einer EDA bzw. zwischen EDA-Komponenten auszutauschen [68] – beispielsweise für den Austausch von Ereignissen zwischen der CEP-Komponente und den operativen Anwendungssystemen, zwischen der CEP-Komponente und Sensornetzwerken oder zwischen mehreren CEP-Komponenten in einem EPN. Aus Sicht der CEP-Komponente lassen sich Ausgangs- und Eingangskanäle unterscheiden. • Ausgangskanäle dienen dazu, Ereignisse aus der CEP-Komponente der Außenwelt mitzuteilen, • Eingangskanäle dienen dazu, beispielsweise Geschäftsereignisse (business events) aus den operativen Systemen in der CEP-Komponente zu empfangen. 7

Diese Abbildung kann durch einen Registrierungsmechanismus geschehen.


163

Die Ereigniskanäle können als eine konzeptionelle Komponente verstanden werden, die als Middleware dem Zweck dient, das Complex Event Processing und die operativen Systeme zu integrieren.8 Dabei gibt es viele unterschiedliche technische Möglichkeiten, um Ereigniskanäle zu implementieren. Mögliche Kandidaten sind Sockets, Remote Method Invocation (RMI), CORBA, Web Services und Messageoriented Middleware (MOM) [28]. Welche Technologie konkret für den Ereignistransport zum Einsatz kommt, hängt von den in den operativen Systemen und der CEP-Komponente zur Verfügung stehenden Technologien ab. MOM zur Realisierung von Ereigniskanälen Für die Realisierung eines Ereigniskanals bietet sich besonders der Einsatz einer Message-oriented Middleware (MOM) an. Die Abbildung 6.2 veranschaulicht die grundsätzliche Funktionsweise dieser Form einer Middleware. MOM Komponente A

Komponente B

Abb. 6.2 Verschicken von Ereignissen über eine Message-oriented Middleware

Eine Softwarekomponente A sendet Ereignisse eines bestimmten Typs als Nachricht an die Message-oriented Middleware, wo die Nachrichten in entsprechenden Warteschlangen verwaltet werden.9 Eine Softwarekomponente B, die sich bei der Middleware für Ereignisse dieses Typs registriert hat, wird ggf. über einen Ereigniseingang benachrichtigt und kann sich dann dieses Ereignis abholen. Etablierte MOM-Produkte für den Austausch von Nachrichten zwischen mehreren Anwendungskomponenten sind z.B. IBM Websphere MQ (ehemals MQSeries), BEA Tuxedo, Tibco Rendezvous oder weitere Produkte, die auf der JMSProgrammierschnittstelle (Java Messaging Service API) basieren. Als Alternative zu einer Message-oriented Middleware steht in Service-orientierten Architekturen ein Enterprise Service Bus (ESB) als nachrichtenbasierte Kommunikationsinfrastruktur zur Verfügung. Ein Enterprise Service Bus ist eine auf Standards basierende Integrationsplattform zur Umsetzung einer SOA. Ein ESB stellt neben einer Messaging-Komponente zusätzlich Mechanismen zum verteilten Betrieb, zur Transformation, zur Sicherheit und zum Deployment bereit und geht damit über die Möglichkeiten einer MOM hinaus. Der Einsatz einer Message-oriented Middleware bietet eine ganze Reihe von Vorteilen für die Umsetzung einer Event-Driven Architecture. Insbesondere lassen sich mit einer MOM die in Abschnitt 3.1.1 eingeführten Schlüsseleigenschaften, die aus dem Verarbeitungsmodell und dem Kommunikationsmuster einer EDA resultieren, 8 In [73] wird im Kontext von Ereigniskanälen auch von einem Enterprise Integration Backbone gesprochen. 9 Warteschlangen einer MOM können auch als Postfächer, wie sie aus normalen E-Mail-Systemen bekannt sind, betrachtet werden.

164


adäquat realisieren. In erster Linie sind die so verbundenen Komponenten äußerst lose gekoppelt. Die ereignisversendende Komponente kennt nur die Middleware, aber nicht die Komponenten, welche die Ereignisse letztendlich empfangen und weiterverarbeiten. Der Versand von Ereignissen in Form von einfachen Text- oder XML-Nachrichten ist darüber hinaus plattformunabhängig und erlaubt auch die einfache Integration von Legacy-Systemen. Operative Anwendungssysteme Schließlich zeigt die Abbildung 6.1 einige typische operative Anwendungssysteme, in denen die Reaktion auf komplexe CEP-Ereignisse implementiert ist. Es lassen sich dedizierte Systeme zur Visualisierung von Ereignissen, klassische Informationssysteme und Unternehmensanwendungen zur Ausführung von Geschäftsprozessen unterscheiden. Die beiden folgenden Abschnitte untersuchen die Behandlung von Ereignissen in Geschäftsprozessen (Abschnitt 6.3) sowie die Visualisierung von Ereignissen (Abschnitt 6.4) als mögliche Reaktionen.

6.3 Ereignisgesteuerte Prozesse Die möglichen Arten der Reaktion auf die in der Ereignisverarbeitung erkannten Ereignismuster sind nahezu unbegrenzt. Eine Event-Driven Architecture kann in den unterschiedlichsten Anwendungsszenarios eingesetzt werden und auf Ereignisse entsprechend vielfältig reagieren. Besondere Bedeutung kommt jedoch in den meisten Anwendungsfällen dem Auslösen von Geschäftsprozessen und dem Einfluss von Ereignissen auf den Ablauf der Prozesse zu. Ereignisse in Prozessen Meist stößt ein Ereignis in einer nachgelagerten Unternehmensanwendung einen Geschäftsprozess (business process) an, der einen komplexen Ablauf oder Algorithmus festlegt und durch eine Abfolge von Verarbeitungsschritten beschrieben werden kann. Prozesse lassen sich in einer beliebigen imperativen Programmiersprache realisieren. Idealerweise werden aber spezielle Prozessbeschreibungssprachen genutzt. Derzeit hat sich die Business Process Execution Language (BPEL) [79] im Umfeld von Service-orientierten Architekturen (SOA) als Standard etabliert. Mit BPEL spezifizierte Prozesse können in einer eigenen BPEL Process Engine ausgeführt werden.10 Das Auftreten eines Ereignisses kann nun zu folgenden Auswirkungen auf die Geschäftsprozesse führen: 10

Für eine vereinfachte Darstellung wird hier angenommen, dass es in den operativen Systemen eine dedizierte Geschäftsprozesskomponente bzw. -schicht gibt, die zum Beispiel durch eine BPEL Process Engine realisiert ist.

6.3 Ereignisgesteuerte Prozesse

165

• Erzeugung neuer Prozessinstanz Ein ankommendes Ereignis erzeugt eine neue Prozessinstanz (trigger instance), die ganz speziell auf dieses Ereignis reagiert. So kann ein Kaufsignalereignis im Wertpapierhandel eine neue Prozessinstanz erzeugen, in der die für den Aktienkauf erforderlichen Schritte durchgeführt werden.11 • Prozessunterbrechung Ein Ereignis kann auch zur Unterbrechung eines bereits laufenden Prozesses führen (interrupt process). Insbesondere wenn eine ungewöhnliche Situation oder Störung auftritt, muss der normale Prozessverlauf unterbrochen werden, um auf diese Störung zu reagieren. In Prozessbeschreibungssprachen gibt es meist eigene Konzepte, um auf Ereignisse zu reagieren. So steht in BPEL das Sprachkonstrukt <eventHandler> zur Verfügung, mit dem auf aufgetretene Ereignisse außerhalb des normalen Prozessverlaufs reagiert werden kann [13]. Ähnlich wie bei Exception-Handlern in klassischen Programmiersprachen wird dort der Source-Code zur Behandlung der Ereignisse realisiert. Die folgende Abbildung 6.3 zeigt am Beispiel des Fluggepäcktransports, wie die Ereignisbehandlung in der graphischen Prozessbeschreibungssprache BPMN 1.1. (Business Process Modeling Notation) [82] modelliert wird. Gepäcktransport

Route bestimmen Flugziel prüfen

Check-in

Gepäck transportieren Gepäck aufgeben Transportproblem

Route neu berechnen

Gepäck umleiten

Statusabfrage Status mitteilen Statusabfrage

Abb. 6.3 Ereignisbehandlung in mit BPMN modellierten Geschäftsprozessen

Beim Check-in wird zunächst das Flugziel geprüft und dann (parallel) das Gepäck aufgegeben sowie die Transportroute bestimmt. Anschließend erfolgt der ei11

In BPEL gibt es sogenannte Correlation Sets, mit denen sich BPEL-Prozessinstanzen definieren lassen. Die zu einem Correlation Set gehörigen Aktionen können mit dem Attribut “initiate=yes“ versehen werden, um neue Prozessinstanzen zu erzeugen. Näheres dazu ist in [79] zu finden.

166


gentliche Gepäcktransport und der Prozess ist beendet. Dies ist der normale Ablauf des Prozesses, der keine weiteren Ereignisse berücksichtigt. Kommt es zu einem Problem im Prozessablauf, wird der eingekreiste Subprozess ausgeführt, der eine neue Route berechnet und das Gepäck umleitet. Das Ereignis “Transportproblem“ ist ein Ereignis, das außerhalb des Prozesses auftritt. In einer Event-Driven Architecture könnte dieses komplexe Ereignis durch eine CEPKomponente erzeugt werden, die sämtliche Transportwege überwacht, um zum Beispiel auf Ausfälle oder Verspätungen unmittelbar reagieren zu können. Auch könnte die CEP-Komponente Barcodes oder RFID-Tags auswerten und die Fehlleitung des Gepäckstücks frühzeitig feststellen, noch weit bevor der Empfänger dies bemerkt hat, und dementsprechend reagieren. Für jedes aufgetretene Transportproblem wird eine neue Instanz des Subprozesses erzeugt, die für die Lösung genau dieses Problems verantwortlich ist. Im Idealfall erkennt CEP das Problem so rechtzeitig, dass durch die eingeleitete Reaktion das Problem bereits wieder behoben ist, bevor der Empfänger sein Gepäckstück erwartet. Darüber hinaus kann zu jedem Zeitpunkt während der Prozessdurchführung eine Statusabfrage durchgeführt werden, die in einem eigenen Subprozess dargestellt ist. Die Statusabfrage wird parallel und asynchron zum normalen Gepäcktransportprozess durchgeführt und endet mit dem Verschicken einer Statusnachricht. Das obige Beispiel zeigt, wie sich ein ereignisgesteuerter Geschäftsprozess durch eine ereignisgesteuerte Implementierung direkt abbilden lässt. Event-Handler Bereits bei der Modellierung der Geschäftsprozesse müssen die Ereignisse, die zu Unterbrechungen, Ausnahmen oder Fehlerbehandlungen führen können, sowie die dann erforderlichen Reaktionen spezifiziert werden. Ein Event-Handler enthält den Programmcode, der unmittelbar auf Ereignisse eines bestimmten Typs reagiert. Auf der Ebene eines Geschäftsprozesses bedeutet die Reaktion auf ein Ereignis stets eine Ausnahme, also die Abweichung vom normalen linearen Kontrollfluss. Die Aktivitäten in einem EventHandler können auch als ereignisgesteuerter Subprozess verstanden werden. Event-Handler unterscheiden sich vom normalen Prozesscode, denn die Ereignisbehandlung findet unabhängig und asynchron zur Standardprozessausführung statt. Ereignisse können jederzeit während der Ausführung einer Prozessinstanz stattfinden. Jeder Event-Handler besteht aus zwei Teilen: 1. Der erste Teil definiert den Ereignistyp, für den der Handler zuständig ist, sowie ggf. weitere Bedingungen. 2. Der zweite Teil enthält die auszuführenden Aktionen zur Behandlung des Ereignisses in Form von Geschäftslogik.

6.4 Visualisierung von Ereignissen

167

Oft findet im Event-Handler nur eine Delegation statt, d.h., der Handler stößt einen Dienst oder Subprozess an, der die konkrete Ereignisbehandlung durchführt.12 Insgesamt bleibt festzustellen, dass viele Prozessbeschreibungssprachen bereits Konzepte für ereignisgesteuerte Prozesse enthalten und so leicht in einer EventDriven Architecture zur ereignisgesteuerten Realisierung dieser Prozesse genutzt werden können.

6.4 Visualisierung von Ereignissen In vielen Anwendungsfeldern ist es besonders wichtig, die aufgetretenen Ereignisse in geeigneter Form zu visualisieren, insbesondere wenn menschliche Akteure die aktuelle Situation oder den Zustand eines Systems beurteilen sollen. Beispielsweise wünschen sich Wertpapierexperten eine graphische Darstellung der verschiedenen Märkte, um die aktuelle Marktlage und sich anbahnende Entwicklungen schnell einschätzen zu können. Für die Visualisierung kontinuierlicher Ereignisströme gibt es keine Patentrezepte. Eine geeignete Darstellung hängt sehr stark von den Anforderungen der jeweiligen Domäne und den gegebenen Daten ab. Generell ist jedoch die Menge der feingranularen Randereignisse in der Regel zu groß und muss deshalb entsprechend verdichtet werden. Diese Aufgabe übernimmt das Complex Event Processing, das zum Beispiel die in einem Sensornetzwerk produzierten Randereignisse aggregiert und somit die Anzahl der Ereignisse signifikant reduziert.13 Zur Visualisierung von verdichteten Ereignissen stehen bewährte Darstellungsmittel zur Verfügung, zum Beispiel spezielle Graphen, Dashboards oder Scorecards. Die Darstellung soll möglichst die zwischen den Ereignissen bestehenden Beziehungen und Korrelationen veranschaulichen. Darüber hinaus ist oft gewünscht, über Drill-down-Funktionen die zu verdichteten Ereignissen zugehörigen Detailinformationen abfragen zu können. Bisher existieren kaum Arbeiten, die sich speziell mit der Visualisierung von kontinuierlichen Datenströmen im Kontext von CEP beschäftigen [105]. Es ist also noch zu untersuchen, wie weit sich bekannte Techniken – beispielsweise aus dem Data-Warehouse- oder Business-Intelligence-Umfeld – auf die Darstellung von Ereignisströmen übertragen lassen. Tracking and Tracing Eine typische Anforderung an Logistik-Systeme ist eine Verfolgung (Tracking) und Rückverfolgung (Tracing) von Transportgütern.

12 Dieses Verhalten ist vergleichbar mit einem Event-Listener in graphischen Benutzungsoberflächen, der auch möglichst wenig Code enthalten sollte, siehe [29]. 13 Dies zeigt auch Abbildung 5.2.

168


• Beim Tracking soll lediglich der aktuelle Ort eines Objektes möglichst exakt bestimmt werden. • Beim Tracing soll auch die Spur des Objektes, also sein zurückgelegter Weg, nachverfolgt werden können. Die genaue Ortung von Produkten, Waren und sonstigen Objekten ist von entscheidender Bedeutung, um logistische Prozesse steuern zu können. Sich bewegende Objekte treten in unterschiedlichen Anwendungsdomänen auf, z.B. Güterverkehr, Gepäcktransport, Verkehrsüberwachung oder auch im Management von Dokumenten und Akten in Verwaltungen oder Kanzleien. Der Einsatz von Sensornetzwerken auf Basis von RFID oder GPS gewinnt immer größere Bedeutung [37] und bildet die technische Basis für die Nachverfolgung von Objekten. Gegenstände werden mit RFID-Tags oder -Transpondern versehen und beim Passieren eines RFID-Lesegeräts registriert. Der Abschnitt 2.5.2 stellt ein Beispiel vor, wie RFID-Technologie im Bereich der Laborlogistik eingesetzt werden kann. Die Abbildung 6.4 skizziert den Raumplan eines Großlabors, der sich zur Visualisierung des Standortes von Laborproben eignet. In dem Plan ist der aktuelle Aufenthaltsort eines Objektes (= Laborprobe) und sein Weg durch die verschiedenen Laborräume dargestellt.

Raum 7 2. Obergeschoss

L7 Raum 5

L8

L5 L4 Raum 6

RFID-Lesegerät

L6

Laborprobe mit Tag Weg durchs Labor

Abb. 6.4 Tracing von Laborproben in einem Großlabor

Probleme bei (Rück-)Verfolgung Allerdings ist eine Ortung von Waren und Transportgütern mittels RFID oft zu ungenau und mit Fehlern behaftet. Ein Leseereignis bedeutet lediglich, dass sich ein RFID-Tag im Einzugsbereich des Lesegerätes befin-

6.4 Visualisierung von Ereignissen

169

det. Weil aber der Lesebereich relativ groß ist, lässt sich ein einzelnes Tag nicht exakt orten. Darüber hinaus werden aufgrund technischer Probleme, z.B. durch Überlappung von RFID-Tags, einige Tags nicht gelesen (missing reads) oder es treten durch Reflexionen Falschlesungen (false positives) auf, d.h., manche Lesegeräte lesen Tags, die sich gar nicht unmittelbar in ihrem Einzugsbereich befinden. CEP für (Rück-)Verfolgung Für diese Ortungsprobleme kann Complex Event Processing Abhilfe schaffen. Spezielle Ereignisregeln berücksichtigen den bisher zurückgelegten Weg eines RFID-Tags oder den aktuellen Verarbeitungsstatus des Objektes (“bearbeitet“, “in Bearbeitung“, “archiviert“ etc.) und erlauben so Rückschlüsse über den aktuellen Aufenthaltsort. Da Objekte häufig in größeren Mengen bewegt werden, ist es oft hilfreich zu wissen, welche anderen Tags sich in unmittelbarer Nähe des gesuchten Objektes befunden haben. Dazu werden Tag-Ereignisse benachbarter Objekte durch entsprechende Regeln korreliert. CEP kann demnach einen wesentlichen Beitrag für die Konsistenz und Aktualität der visualisierten Informationen leisten und führt somit zu einem qualitativ höherwertigen Visualisierungsergebnis mit deutlich höherem Informationswert. Business Activity Monitoring Business Activity Monitoring (BAM) bezeichnet eine spezielle Klasse von Monitoring-Anwendungen, auf deren spezifische Anforderungen sowie deren besondere Eignung als Anwendungsgebiet für Complex Event Processing bereits der Abschnitt 2.5.1 eingeht (vgl. auch [77]). Der zielgruppenangemessenen Visualisierung der Resultate kommt im BAM eine entscheidende Bedeutung zu [105]. Business Activity Monitoring ist ein Ansatz, um geeignete Kennzahlen und Indikatoren für kritische Unternehmensprozesse in Echtzeit zu bestimmen [71]. Luckham spricht in diesem Kontext von IT-Blindheit (IT blindness): Eine riesige Menge von Ereignissen steht zwar prinzipiell zur Verfügung, aber die Bedeutung oder Semantik dieser Ereignisse für die Geschäftsprozesse und Unternehmensziele bleibt verborgen. Ziel von BAM ist es, diese IT-Blindheit aufzulösen und den Status der laufenden Prozesse auf Geschäftsebene verstehen zu können. Dazu müssen sämtliche für die Geschäftsprozesse relevanten Ereignisse gesammelt und zu Kennzahlen verdichtet werden. In dieser Weise werden die Resultate von Geschäftsabläufen analysiert und so visuell aufbereitet, dass sie den Prozessverantwortlichen in übersichtlicher und umfassender Form zur Verfügung stehen. Abbildung 6.5 veranschaulicht das Verdichten und Visualisieren von Ereignisströmen zu Kennzahlen. Auf der Basis der Kennzahlen lassen sich dann Entscheidungen fundierter treffen und die operativen Prozesse dynamisch steuern. Business Activity Monitoring geht weit über die reine Visualisierung von Ereignissen hinaus und nimmt eine Schlüsselstellung für ein unternehmensweites Controlling ein.

170


Abschnitt A

Abschnitt B

Business Activity Monitoring

Abschnitt C Auslastung

Auslastung

Km/H

Geschwindigkeit

A

Zeit

Verteilung A

Verteilung B

Verteilung C

S1 99 94 30 53 11

B

C

S2 37 53 73 67 33

Text Box

D

F

S3 14 46 98 92 46

G

S4 20 18 11 45 88

H

I

S5 75 45 34 78 45

Ereignisstrom

Abb. 6.5 Verdichtung und Visualisierung von Kennzahlen im Business Activity Monitoring

CEP für BAM Mithilfe eines CEP-basierten Business-Activitiy-Monitoring-Systems lässt sich ein Großteil der in Abschnitt 2.5.1 formulierten Anforderungen erfüllen [64]. Dazu definieren Ereignismuster unterschiedliche Abstraktionsebenen oder beschreiben die Verletzung einer Geschäftsregel oder andere kritische Situationen, die einer sofortigen Reaktion in Echtzeit bedürfen. Zum Beispiel lässt sich beim Supply Chain Management der Lagerbestand von Verarbeitungsgütern mithilfe von BAM in Echtzeit steuern. Jede Entnahme oder Einlieferung eines Artikels aus dem Lager führt zu einem Ereignis. Entsprechende Ereignismuster prüfen, ob der Lagerbestand eines Artikels unter einen bestimmten Schwellenwert sinkt, um dann ggf. eine Nachbestellung anzustoßen. Auch dieser Schwellenwert kann mithilfe von CEP-Regeln aus der Ereignishistorie abgeleitet werden. Er berücksichtigt u.a. die durchschnittliche Lieferzeit dieses Artikels und die durchschnittliche Verweildauer des Artikels im Lager. Entsprechende (Aggregations-)Regeln können beide Größen auf Basis der historischen Ereignisse bestimmen.

6.5 Erzeugen von Geschäftsereignissen Die Beziehung zwischen der Ereignisverarbeitungs- und -behandlungsschicht ist bidirektional: Einerseits löst die Ereignisverarbeitung Aktionen in den nachgelagerten operativen Systemen aus, andererseits können aber auch in den operativen Unternehmensanwendungen Vorkommnisse auftreten, die als (Geschäfts-)Ereignisse wiederum in die Ereignisverarbeitung einfließen. Demnach besteht eine weitere wichtige Aufgabe der operativen Anwendungssysteme innerhalb einer Event-Driven Architecture in der Erzeugung von Geschäftsereignissen, die sie an die CEP-Komponente schicken (vgl. Abbildung 6.1).

6.5 Erzeugen von Geschäftsereignissen

171

Geschäftsereignis Ein Geschäftsereignis (business event) repräsentiert eine Zustandsänderung innerhalb der Unternehmensanwendungen, die bei der Ereignisverarbeitung berücksichtigt werden soll. Die Geschäftsereignisse fließen über einen Eingangskanal als Ereignisstrom an die CEP-Komponente. Auf diese Weise ist eine Rückkopplung zwischen CEPKomponente und operativen Systemen erreicht: In der CEP-Komponente können relevante Änderungen innerhalb der operativen Systeme berücksichtigt werden. Diese Rückkopplung kann technisch durch zwei unterschiedliche Mechanismen geschehen (siehe Abbildung 6.6).

CEP-Komponente EPN

Operative Systeme Dienstaufruf (Pull)

Dienst

Geschäftsereignisse (Push)

Abb. 6.6 Push- und Pull-Mechanismus

1. Pull-Mechanismus Die CEP-Komponente greift in ihren Ereignisregeln auf Dienste der operativen Anwendungssysteme zu, um deren aktuellen Zustand zu erfragen und zu berücksichtigen. Der Informationsfluss ist also durch einen Pull-Mechanismus realisiert. Der Nachteil dieser Lösung ist, dass die CEP-Komponente nicht unmittelbar von relevanten Änderungen in den operativen Systemen erfährt. Darüber hinaus ist die CEP-Komponente relativ stark an die nachgelagerten Systeme gekoppelt, weil sie die genaue Aufrufsemantik der Dienste kennen muss. 2. Push-Mechanismus Die operativen Anwendungssysteme schicken von sich aus die erforderlichen Informationen über ein Geschäftsereignis an die CEP-Komponente. Hierbei handelt es sich also um einen Push-Mechanismus, mit dem die CEP-Komponente ohne Verzögerung über neue Zustände in den operativen Systemen benachrichtigt wird. Darüber hinaus sind dadurch CEP-Komponente und Anwendungssysteme durch den Austausch von Ereignisnachrichten sehr lose gekoppelt.

172


In den operativen Unternehmensanwendungen können ganz unterschiedliche Ursachen dafür verantwortlich sein, dass Geschäftsereignisse ausgelöst werden, zum Beispiel: • Datenänderung Der Datenbestand einer Anwendung kann eine bestimmte Konstellation erreicht haben, die der CEP-Komponente angezeigt werden muss. Zum Beispiel wenn der Lagerbestand eines bestimmten Artikels einen Schwellenwert unterschreitet. Technisch können solche relevanten Datenänderungen durch Trigger des Datenbanksystems oder auch durch Geschäftsregeln in den Anwendungssystemen erkannt werden. • Aufruf eines Dienstes Jeder Aufruf eines bestimmten Dienstes soll der CEP-Komponente mitgeteilt werden. Ein Beispiel ist ein Dienst zur Änderung eines Passwortes, für den jeder Aufruf als ein Geschäftsereignis “Passwortänderung“ an die CEP-Komponente gesendet wird. • Menschliche Interaktion Insbesondere können menschliche Benutzer durch Eingaben solche Entscheidungen treffen oder Aktionen auslösen, die für die Ereignisverarbeitung von Bedeutung sind. Insgesamt bleibt festzuhalten, dass die für ein Unternehmen relevanten Ereignismuster nicht nur externe feingranulare Randerereignisse, sondern auch abstraktere Geschäftsereignisse berücksichtigen müssen, die aus den operativen Anwendungssystemen in Form einer Rückkopplung in die CEP-Komponente zurückfließen.

6.6 Fallstudie: Verkehrskontrolle und -steuerung Im Anwendungsszenario des Verkehrskontrollsystems dient Complex Event Processing der Erkennung von Verkehrsproblemen. Dazu werden Muster in den Strömen der auftretenden Sensorereignisse gesucht. Die operativen Verkehrsleitsysteme führen alle erforderlichen Maßnahmen zur Behandlung eines erkannten Verkehrsproblems durch. Dazu initiieren sie Aktionen, die einen kritischen Zustand des Verkehrsnetzes in einen Normalzustand überführen. Komponenten der operativen Verkehrsleitsysteme Die Abbildung 6.7 zeigt die wesentlichen Systemkomponenten der Verkehrssteuerung sowie deren CEP-Schnittstellen. Die Komponenten der operativen Verkehrsleitsysteme entsprechen den Steuerungsaktionen des Maßnahmenkatalogs, der in Abschnitt 3.4 in Tabelle 3.3 dargestellt ist. Visualisierung (visualization) Im Verkehrsleitstand wird die aktuelle Verkehrslage auf Kontrollmonitoren visualisiert. Dazu werden die von der CEP-Komponente erzeugten Ereignisse direkt in einem Kartenausschnitt abgebildet und dargestellt.


Sensor Processing Agent

Traffic Analysis Agent

173 CEP-Komponente (Event Processing Network)

Diagnosis Agent

Fassade

Out-Adapter

Ereigniskanäle

Operative Systeme CEPSchnittstelle

CEPSchnittstelle

CEPSchnittstelle

CEPSchnittstelle

Visualisierung

Info-Panels

Benachrichtigung

Aktionsplanung

Historische Daten

Strukturelle Daten

CEP-Ereignisse

Ausgangskanal


Eingangskanal

Datenfluss

Abb. 6.7 Operative Leitsysteme im Verkehrskontrollsystem

Zum Beispiel sind auf einem Kontrollmonitor die Straßenabschnitte entsprechend den Verkehrsproblemen farbig hervorgehoben. Diese Darstellung lässt sich auch als spezielle Form des Ereignis-Trackings auffassen. Informationspanel Auf Schnellstraßen sind spezielle Anzeigetafeln angebracht, die zentral aus dem Verkehrsleitstand angesteuert werden können. Mithilfe entsprechender Meldungen können die Verkehrsteilnehmer zeitnah informiert bzw. gewarnt werden, um beispielsweise Staus auszuweichen oder Auffahrunfälle zu vermeiden. Die operativen Systeme erzeugen aussagekräftige Nachrichten und Hinweise und übertragen diese zu den Anzeigetafeln. Benachrichtigung (notification) Bei schwerwiegenden Problemen, etwa bei Unfällen, werden aus dem Leitstand Einsatzfahrzeuge von Polizei und Rettungsdiensten angefordert. Technisch können die operativen Systeme dazu beispielsweise die nächstgelegene Dienststelle suchen und automatisch eine Telefonleitung schalten. Aktionsplanung (action planning) Die Hauptaufgabe der operativen Verkehrssteuerungssysteme ist die Unterstützung bei der Entscheidungsfindung (decision support): Was sind die am besten geeigneten Maßnahmen zur Behebung eines bestimmten Verkehrsproblems. So kann durch Geschwindigkeitsbeschränkungen, geänderte Ampelschaltungen, Umleitungsempfehlungen und ggf. auch Straßensperrungen auf schwerwiegende Verkehrsprobleme reagiert werden. Dazu führen die operativen Systeme einen Aktionsplanungsschritt durch: Zunächst werden mögliche Ursachen für das aufgetretene Problem identifiziert und dann Maßnahmen

174


ergriffen, die diese Ursachen mildern oder aufheben. Weitere Details sind in [26] und [84] zu finden. Datenmanagement (data management) Schließlich halten die operativen Systeme auch die von der CEP-Komponente benötigten Kontextdaten vor. In den Event Processing Engines der EPAs gibt es meist keine Möglichkeit zur persistenten Speicherung von Daten, so dass diese Aufgabe den operativen Systemen obliegt. Die CEP-Komponente im Verkehrskontrollsystem muss einerseits strukturelle Daten, wie die Topologie des Straßennetzes, kennen. Andererseits benötigt sie auch historische Verkehrsdaten, um das “normale“ Verhalten zu einer bestimmten Tageszeit beurteilen zu können. Auf diese Daten wird in den Ereignisregeln durch Dienstaufrufe zugegriffen. Es handelt sich dabei um einen Anreicherungsschritt mit Kontextdaten (content enrichment), wie ihn Abschnitt 5.3 beschreibt. Alle diese in den operativen Verkehrsleitsystemen angestoßenen Maßnahmen befinden sich außerhalb der unmittelbaren Ereignisverarbeitung. Einerseits werden komplexe Algorithmen und Abläufe durchgeführt, z.B. bei der Aktionsplanung, andererseits werden technische Systeme, wie Ampeln und Anzeigetafeln, angesteuert. Kommunikation zwischen CEP-Komponente und Verkehrsleitsystem Die Kommunikation zwischen der CEP-Komponente und den operativen Verkehrsleitsystemen geschieht über logische Ereigniskanäle, die zum Beispiel durch eine nachrichtenbasierte Middleware realisiert sein können. Dabei sind zwei Richtungen zu unterscheiden: 1. Die CEP-Komponente sendet CEP-Ereignisse an die operativen Systeme über den Out-Adapter. Dieser Adapter packt beispielsweise ein Problemereignis in eine Nachricht und sendet sie an die Nachrichtenwarteschlange. Die Komponenten des operativen Leitsystems lesen mithilfe ihrer CEP-Schnittstellen die ankommenden Nachrichten, extrahieren die Ereignisse und stoßen entsprechende Prozesse an. Zum Beispiel erzeugt ein Problemereignis eine neue Instanz eines Aktionsplanungsprozesses. 2. Auf umgekehrtem Wege schicken die Leitsysteme Geschäftsereignisse zur CEPKomponente. Ein Beispiel für ein solches Geschäftsereignis ist im Kontext der Verkehrskontrolle eine Unfallmeldung, die in der Benachrichtigungskomponente eintrifft, oder eine Aktion der Aktionsplanungskomponente, die bei der Erkennung von Ereignismustern berücksichtigt werden muss. Wird beispielsweise eine Straße gesperrt, so muss dies in den Ereignisregeln entsprechend einbezogen werden. Die Geschäftsereignisse werden als Nachrichten an die Fassade der CEP-Komponente geschickt, wo sie ausgepackt und an den entsprechenden Event Processing Agent weitergereicht werden. Insgesamt führt diese Trennung der Verkehrsleitsysteme von der Ereignisverarbeitung zu einer äußerst losen Kopplung zwischen den beiden logischen Schichten einer Event-Driven Architecture. Die Ereignismuster lassen sich während des laufenden Betriebs ändern und optimieren, ohne dass sich dies auf die operativen Leitsysteme durchschlägt.

Teil III

Entwurfsmuster und Architekturen für EDA

Teil III – Entwurfsmuster und Architekturen für EDA stellt wichtige Konzepte für die professionelle Entwicklung von EDA-Anwendungen in der Praxis vor. Softwareentwicklungsprojekte im industriellen Maßstab sind äußerst komplexe Vorhaben. Das gilt selbstverständlich auch für EDA-Projekte. Diese Komplexität besteht auf zwei Ebenen: 1. Systemkomplexität: Wie wird das System richtig gebaut? 2. Prozesskomplexität: Wie wird der Entwicklungsprozess richtig gestaltet? Mit Entwurfsmustern und Referenzarchitekturen für EDA-Anwendungen werden in diesem Teil wesentliche Konzepte für den Entwurf und die Entwicklung von EDA-Anwendungen behandelt. Sowohl Entwurfsmuster als auch Referenzarchitekturen repräsentieren wichtiges Erfahrungswissen, um ein ereignisgesteuertes System richtig zu bauen, also um die Systemkomplexität zu beherrschen. Für die Gestaltung des Entwicklungsprozesses, also um die Prozesskomplexität zu beherrschen, werden Vorgehensschritte und ein Vorgehensmodell vorgestellt, die auf die spezifischen Anforderungen von ereignisgesteuerten Systemen zugeschnitten sind. Kapitel 7 – Entwurfsmuster stellt systematisch grundlegende Entwurfsmuster für EDA vor, und zwar differenziert nach Architektur- und Designmustern. Kapitel 8 – Referenzarchitekturen entwickelt auf Basis der Entwurfsmuster eine idealisierte Softwarearchitektur für EDA, die als Referenzarchitektur und somit als eine Art Blaupause für eine konkrete Architektur für ein spezielles Anwendungsszenario dienen kann. Kapitel 9 – Vorgehen bei der Entwicklung von EDA-Anwendungen Keine professionelle Softwareentwicklung ohne systematisches Vorgehen! In diesem Kapitel werden die spezifischen Prozessschritte und Aufgaben für die Entwicklung von ereignisgesteuerten Anwendungssystemen herausgearbeitet und in ein Vorgehensmodell integriert.

Kapitel 7

Entwurfsmuster

Zusammenfassung Für die Entwicklung einer Event-Driven Architecture sind Entwurfsmuster äußerst hilfreich, die Leitlinien und Konzepte für einen guten Systementwurf vorgeben. Dieses Kapitel stellt in systematischer Weise wichtige Entwurfsmuster für EDA auf verschiedenen Abstraktionsebenen vor. Architekturmuster legen die grundlegenden Ordnungsstrukturen eines EDA-Gesamtsystems fest. Designmuster beschreiben allgemeingültige Konzepte, die der Ereignisverarbeitung zugrunde liegen. Dieses Kapitel greift neben neuen Entwurfsmustern zum Teil auch Erkenntnisse aus den vorhergehenden Kapiteln auf und stellt diese in einen neuen Zusammenhang. Es wird ein Katalog von Entwurfsmustern präsentiert, der auf den verschiedenen Architekturebenen eingesetzt werden kann.

7.1 Muster in Event-Driven Architecture Bei der Entwicklung von Softwarearchitekturen und -systemen spielen Entwurfsmuster eine wichtige Rolle. Entwurfsmuster repräsentieren wertvolles Erfahrungswissen, das sich auf den Entwurf und die Entwicklung komplexer Systeme anwenden lässt. Was sind Entwurfsmuster? Die ursprüngliche Idee der Entwurfsmuster stammt von dem amerikanischen Architekturprofessor Christopher Alexander [3] und wurde von der “Gang-of-Four“ um Erich Gamma erfolgreich auf die Softwareentwicklung übertragen [15, 43]. Entwurfsmuster (Pattern) Ein Entwurfsmuster beschreibt eine erprobte Lösung für ein wiederkehrendes Entwurfsproblem bei der Entwicklung eines Softwaresystems. Die in einem Muster präsentierte Lösung lässt sich nicht unmittelbar in Source-Code umsetzen, sondern beschreibt vielmehr die grund-


177

178

7 Entwurfsmuster

sätzliche Lösungsidee. Ein Entwurfsmuster soll auf gleich gelagerte Probleme und unter verschiedenen Rahmenbedingungen anwendbar sein. Ein Muster kann als Schablone aufgefasst werden, die sich in vielen verschiedenen Problemszenarien einsetzen lässt. In der Regel sind Entwurfsmuster immer in derselben Struktur dargestellt [43]: • Kontext und Problem Der Kontext beschreibt die Situation, in der das vom Muster behandelte Problem auftritt. Das Problem wird durch die an eine Lösung gestellten Anforderungen und Randbedingungen beschrieben. Dabei sind insbesondere die Ziele wichtig, die eine mögliche Lösung erreichen soll, z.B. Redundanzfreiheit, Wartbarkeit, Änderbarkeit, Wiederverwendbarkeit. • Lösung Die Beschreibung der Problemlösung erfolgt auf einer relativ abstrakten Ebene anhand der beteiligten Softwarekomponenten und deren Verantwortlichkeiten. Es wird weder ein konkreter Entwurf noch eine konkrete Implementierung beschrieben. Mittlerweile gibt es in vielen verschiedenen Feldern der Softwareentwicklung spezielle Muster, die gewonnene Erfahrungen in strukturierter Form beschreiben und so wiederverwendbar machen. Etablierte Muster gibt es für die verschiedensten Anwendungsgebiete, zum Beispiel für die Analyse von Softwaresystemen [40], für verteilte Systeme [96] oder für bestimmte Plattfomen wie etwa JavaEE [6]. Hierarchie von Entwurfsmustern Entwurfsmuster lassen sich auf verschiedenen Abstraktionsebenen von Softwarearchitekturen einsetzen [15, 29]. In diesem Kapitel betrachten wir für Event-Driven Architecture die folgenden Kategorien:1 1. Architekturmuster oder strukturelle Muster Architekturmuster legen die grundsätzliche Struktur der Event-Driven Architecture fest. Sie definieren Ordnungsprinzipien und Leitlinien, mit deren Hilfe sich ein EDA-Gesamtsystem in Schichten, Teilsysteme und Komponenten zerlegen lässt. 2. Designmuster Designmuster beschreiben grundlegende und allgemeingültige Konzepte, die der Ereignisverarbeitung in einer Event-Driven-Architecture zugrunde liegen. Darüber hinaus können Verarbeitungsmuster als weitere Musterkategorie betrachtet werden [22]. Sie werden für die Realisierung der vorgestellten Architektur1

Die Nutzung der verschiedenen Begriffe erfolgt in der Literatur nicht immer einheitlich. Dieses Buch verwendet den Begriff “Entwurfsmuster“ als Obergriff – auch um Verwechselungen mit dem Konzept der “Ereignismuster“ zu vermeiden. Designmuster sind spezielle Entwurfsmuster, die Problem-Lösungspaare für eine bestimmte Abstraktionsebene der Softwareentwicklung liefern.

7.2 Architekturmuster

179

und Designmuster eingesetzt und sind wesentlich implementierungsnäher.2 Bei der Beschreibung der Designmuster werden wir einige der Verarbeitungsmuster in den Sprachkonstrukten wiedererkennen, die in Kapitel 5 vorgestellt werden.3 Entwurfsmuster und EDA Derzeit gibt es noch keine umfassenden Arbeiten, die Muster speziell für EventDriven Architecture und Complex Event Processing untersuchen [30].4 Dieses Kapitel hat zum Ziel, sämtliche generellen Leitlinien (best practices) und Erkenntnisse, die bei der Entwicklung von EDA-Systemen helfen, in kompakter und zusammenhängender Form darzustellen. Dies geschieht mithilfe eines Musterkatalogs, der einerseits neue Muster vorstellt, aber auch viele Regeln und Tipps aus den vorangegangenen Kapiteln zusammenträgt. Diese werden mit weiteren Hinweisen und Bewertungen ergänzt sowie neu strukturiert und in Zusammenhang gestellt.

7.2 Architekturmuster Architekturmuster beschreiben die globalen Strukturen, d.h. die Bestandteile einer Event-Driven Architecture bzw. einer EDA-Anwendung und deren Zusammenspiel. Dieser Abschnitt betrachtet EDA-spezifische Muster, die sich also direkt auf die CEP-Komponente oder die Schnittstellen zu den operativen Systemen beziehen.

7.2.1 EDA-Schichten Kontext und Problem: In einer Event-Driven-Architecture lassen sich grundlegend verschiedene Aufgaben unterscheiden. Zu den Aufgaben gehören der Zugriff auf die unterschiedlichsten Ereignisquellen, das Auffinden von Ereignismustern in den Ereignisströmen sowie die Reaktion auf spezielle Ereigniskonstellationen. Ziel der Softwarearchitektur ist, das EDA-System auf der obersten Abstraktionsebene zu strukturieren, seine verschiedenen Aufgaben voneinander abzugrenzen, zu entkoppeln und auf verschiedene Komponenten zu verteilen. Dabei sollen sich Änderungen innerhalb einer Komponente nicht auf das Gesamtsystem durchziehen.

2

Manche dieser Muster sind nicht neu, sondern finden sich in ähnlicher Form als sogenannte Messaging Patterns in der Anwendungsintegration (siehe [41]). 3 Design- und Verarbeitungsmuster lassen sich nicht immer scharf voneinander abgrenzen. 4 Das White Paper [22] stellt verschiedene Muster für die Gestaltung von CEP-Verarbeitungsregeln vor. Die meisten dieser Muster werden bereits in Abschnitt 5.4.4 behandelt.

180

7 Entwurfsmuster

Lösung: Analog zu konventionellen Softwarearchitekturen bietet sich auch für EDA-Systeme der Einsatz einer klassischen Schichtenarchitektur [15] an (siehe Abbildung 7.1). Schichten lassen sich als spezielle Teilsysteme auffassen, die eine besonders lose Kopplung aufweisen und nur sehr eingeschränkt miteinander kommunizieren. Eine Schicht n kennt keine der höher liegenden Schichten, sondern stellt ausschließlich der unmittelbar darüber liegenden Schicht n + 1 Dienste zur Verfügung [29].

Monitoring

Schicht 1


Schicht 2

Ereignisbehandlung

Schicht 3

Abb. 7.1 EDA-Schichten

In einer Event-Driven Architecture lassen sich drei verschiedene Standardschichten unterscheiden: 1. Monitoring-Schicht Die Monitoring-Schicht erkennt die von den verschiedenen Ereignisquellen gelieferten Informationen und transformiert diese in Ereignisse, die dann in der Ereignisverarbeitungsschicht verarbeitet werden können. Im Einzelnen übernimmt die Schicht die folgenden Aufgaben: • Durchführung des technischen Zugriffs auf die Ereignisquellen. • Erzeugung von Ereignisobjekten aus den von den Ereignisquellen produzierten Daten. Das Format der Ereignisobjekte ist einheitlich und an die in der Ereignisverarbeitung zulässigen Formate angepasst. • Weiterleitung der Ereignisse an die Ereignisverarbeitungsschicht. Damit übernimmt die Monitoring-Schicht die Aufgaben der In-Adapter sowie der Fassade, die Abschnitt 5.6 einführt. Alle Ereignisse, die von außen der Ereignisverarbeitung zugeführt werden, gelangen somit über diese Schicht in das System. Für jede Art von Ereignisquelle existiert ein eigener Adapter, der die technischen Details der Quelle kapselt. Als Resultat liefert die Monitoring-Schicht einen kontinuierlichen Strom von Ereignissen in einem einheitlichen Format. 2. Ereignisverarbeitungsschicht Die Ereignisverarbeitungsschicht ist für die regelbasierte Verarbeitung der eintreffenden Ereignisströme zuständig. Ihr Ziel ist, den kontinuierlich eintreffenden Ereignissen eine Bedeutung abzugewinnen. Dazu werden geeignete Ereig-


181

nismuster in einer Event Processing Language (EPL) deklariert und von einem Regelinterpreter ausgeführt. Die Ereignisverarbeitungsschicht liefert komplexe Ereignisse, die sie erzeugt, sobald ein Muster in den Ereignisströmen erkannt ist. 3. Ereignisbehandlungsschicht Die Ereignisbehandlungsschicht übernimmt die Behandlung von Ereignissen. Als mögliche Reaktionen werden beispielsweise die beobachteten Ereignisse visualisiert oder Prozessinstanzen ausgeführt. Insgesamt obliegt die Behandlung der für die Anwendungsdomäne relevanten Ereignisse den operativen Anwendungssystemen (siehe Kapitel 6). Die Kommunikation zwischen den Schichten erfolgt im Idealfall ausschließlich durch den Austausch von Ereignissen unterschiedlicher Granularität. Bewertung: Die drei EDA-Schichten beschreiben den globalen Kontrollfluss in einer EDAAnwendung [73] und trennen klar die drei zentralen Verantwortungen in ereignisgesteuerten Systemen: (a) Erkennen, (b) Verarbeiten, (c) Reagieren (siehe auch Abschnitt 3.1 und Abbildung 3.1). Diese Schichtenarchitektur entspricht den logischen Schichten einer EDA aus Abschnitt 3.1.3. Durch die Schichtenarchitektur sind die drei Hauptaufgaben voneinander entkoppelt. Die Monitoring-Schicht weiß nicht, was mit den von ihr produzierten Ereignisse weiter geschieht. Die Ereignisverarbeitungsschicht kennt keine technischen Details über die verschiedenen Ereignisquellen und weiß auch nicht, wie auf die von ihr abgeleiteten Ereignisse reagiert wird. Die Ereignisbehandlungsschicht hat hingegen nichts mit feingranularen Ereignissen zu tun und hat auch keine Kenntnis darüber, wie die ihr zugestellten Ereignisse entstanden sind. Somit lässt sich jede der drei Schichten leicht ändern oder gar austauschen, ohne dass sich dies auf die anderen Schichten auswirkt.

7.2.2 Ereignisagenten Kontext und Problem: Bei einer komplexen Ereignisverarbeitung, die auf einer großen Menge von Regeln beruht, existieren unterschiedliche Alternativen, in welchen physikalischen Ausführungseinheiten die Ereignisregeln verarbeitet werden. Aus Sicht der Softwarearchitektur handelt es sich um ein Abbildungsproblem.5 Die folgenden Anforderungen sind dabei zu erfüllen: • Verständlichkeit und Wartbarkeit Ein signifikanter Nachteil von regelbasierten Systemen ist die Schwierigkeit, den

5

In der UML werden solche Abbildungen durch Deployment-Diagramme beschrieben.

182

7 Entwurfsmuster

Kontrollfluss zu verstehen und nachzuvollziehen. Diese Problematik erschwert wesentlich die Wartbarkeit von Regelsystemen. • Performance und Skalierbarkeit Für die Verarbeitung von hochfrequenten Ereignisströmen in Echtzeit wird eine skalierbare Architektur benötigt, die auf verschiedene Hardwarekomponenten verteilt ist und eine Mustererkennung in extrem kurzen Reaktionszeiten ermöglicht. Lösung: Die Ereignisverarbeitungsregeln werden auf mehrere autonome Ereignisagenten (Event Processing Agents – EPAs) verteilt, die durch den Austausch von Ereignissen miteinander kommunizieren und so ein Netzwerk bilden (Event Processing Network – EPN) [63] (siehe Abbildung 7.2).

EPA 1

EPA 3

EPA 2

EPA 4

Abb. 7.2 Verteilung der Regeln auf Ereignisagenten

Jeder Event Processing Agent ist eine eigenständige Ausführungseinheit und besitzt seine eigene Event Processing Engine mit der dazugehörigen Menge von Regeln, der sogenannten Regelbasis. Um eine bessere Performance der Ereignisverarbeitung zu erreichen, können die EPAs auf verschiedene Server physikalisch verteilt werden.6 In einem ersten Ansatz werden die EPAs einfach auf verschiedene Hardwarekomponenten verteilt. Ein Server muss dann nicht mehr das komplette EPN mit allen Regeln ausführen, sondern nur ein Teilnetz. In manchen Fällen reicht eine solche Partitionierung des Netzes aber nicht aus, um den erforderlichen Durchsatz zu erreichen. In solchen Situationen wird ein einzelner EPA repliziert und auf mehrere Hardwarekomponenten verteilt. In diesem Fall befinden sich also identische EPAs mit derselben Regelbasis auf mehreren Servern (siehe Abbildung 7.3). Um diese zusätzliche Hardware ausnutzen zu können, muss der Ereignisstrom entsprechend auf die redundanten EPAs aufgeteilt werden. 6

Kruchten bezeichnet dies als Physical View [61].


183 Server 3

Server 1

EPA

Server 2

Server 1

EPA-Kopie

EPA-Kopie

EPA-Kopie

Abb. 7.3 Replikation von EPAs auf verschiedenen Servern

Bewertung: Ein aus mehreren EPAs bestehendes Event Processing Network erfüllt die genannten Anforderungen. Die Aufteilung der Ereignisverarbeitung auf mehrere Ereignisagenten ist ein Verteilungsmuster, es legt die Zuordnung zwischen Regeln und Ausführungsumgebungen fest. Eine Ausführungsumgebung ist durch die Laufzeitumgebung für die Mustererkennnung (= Event Processing Engine) und den physikalischen Ort (die Verteilung auf Hardwarekomponenten) gekennzeichnet. • Ereignisagenten bieten ein Konzept zur Modularisierung und Strukturierung eines Regelsystems auf logischer Ebene: Die Menge der Ereignisverarbeitungsregeln verteilt sich auf mehrere EPAs.7 Die sich aus einem Netzwerk von leichtgewichtigen EPAs ergebenden Vorteile diskutieren ausführlich die Abschnitte 3.2.2 und 5.6. Insgesamt resultiert eine bessere Verständlichkeit des Systemverhaltens und damit einhergehend eine erhöhte Wartbarkeit. • EPAs ermöglichen die physikalische Verteilung des Regelsystems auf verschiedene Hardwarekomponenten und führen damit zu einer besseren Skalierbarkeit der Ereignisverarbeitung. Auch mehrere identische EPAs lassen sich auf verschiedene Server verteilen, um schnellere Bearbeitungszeiten und eine bessere Performance zu erreichen. Die inhaltliche Abgrenzung der EPAs beim Entwurf eines Event Processing Network erfolgt normalerweise anhand ihrer fachlichen Aufgaben. Dabei sollen die üblichen Kriterien für gute Komponenten in einer Softwarearchitektur gelten: Jeder EPA besitzt eine starke Kohäsion und ist lose mit anderen EPAs gekoppelt.

7.2.3 Verarbeitungs-Pipeline Kontext und Problem: Die Ereignisverarbeitungsschicht aus Abschnitt 7.2.1 erfordert eine übergreifende Struktur von Softwarebausteinen, in die sich die Schicht verfeinern lässt. Im Um7

Kruchten spricht auch von Development View [61].

184

7 Entwurfsmuster

feld von Softwarearchitekturen wird auch von der “logischen Sicht“ (logical view) gesprochen (siehe [61]). Ablauforientierte Systeme sind in der Regel hierarchisch strukturiert: Die abstrakteste Sicht ist die auf Geschäftsprozesse, die wiederum aus einfacheren Diensten zusammengesetzt oder orchestriert werden. Ein ähnlicher generell gültiger Strukturierungsansatz ist auch für EDA-basierte Systeme wünschenswert. Lösung: Die Verarbeitung von Ereignissen erfolgt stufenweise in einer Abfolge von mehreren aufeinanderfolgenden Verarbeitungsschritten (siehe Abbildung 7.4). Die Abfolge von Schritten wird auch als Pipeline bezeichnet. Pipeline Ereignisquellen

Ereignisbehandlung

Event Processing Agents

Abb. 7.4 Pipeline

Das Entwurfsmuster folgt dem wohlbekannten Pipes-and-Filters-Muster nach [15].8 Die Schritte einer Pipeline sind durch die folgenden Eigenschaften gekennzeichnet: • Die einzelnen Schritte sind über den Austausch von Ereignissen miteinander verbunden. Die Ereignisse, die in einem Verarbeitungsschritt erzeugt worden sind, verarbeitet der nachfolgende Schritt weiter. Der erste Schritt der Pipeline verarbeitet die Ereignisse der Ereignisquellen, der letzte sendet Ereignisse an die nachgelagerten Anwendungssysteme zur Ereignisbehandlung. Die Anwendungssysteme sind somit die Senken der Ereignis-Pipeline. • In einem Verarbeitungsschritt werden die Ereignisse ergänzt (content enrichment), aggregiert (aggregation) und zu neuen Ereignissen korrelliert. Der Zuschnitt der einzelnen Schritte orientiert sich dabei an den verschiedenen Abstraktionsstufen des Ereignismodells.9 • Jeder einzelne Verarbeitungsschritt der Pipeline ist durch einen Event Processing Agent oder ein Teilnetz mit mehreren EPAs realisiert.

8

Ein typisches Anwendungsfeld des Pipes-and-Filters-Musters ist der Compiler-Bau mit einer festgelegten Folge von Schritten: lexikalische, syntaktische und semantische Analyse. 9 Im Verkehrskontrollsystem gibt es zum Beispiel Agenten für die Verarbeitung von Sensordaten, Agenten für die Ermittlung von Kenngrößen sowie Agenten zur Identifikation von Problemsituationen.

7.3 Designmuster

185

In der Pipeline transformieren die Verarbeitungsschritte die Ereignisse in mehreren Stufen von einfachen (ggf. bedeutungslosen) zu komplexen (aussagekräftigen) Ereignissen. Bewertung: Das Pipeline-Muster liefert einen Strukturierungsansatz für die Ereignisverarbeitungsschicht. Die dort vorgenommene Transformation von einfachen Randereignissen in abstrakte Geschäftsereignisse kann als Abfolge von Schritten verstanden werden. Jeder Schritt bildet die Ereignisse in eine höhere Abstraktionsebene ab, die schließlich für die operativen Systeme verständlich und nützlich ist. Das PipelineMuster weist die folgenden Vorteile auf: • Die Pipeline repräsentiert eine durch den Ereignisfluss gegebene sequenzielle Sicht auf die ansonsten nebenläufige regelbasierte Verarbeitung innerhalb der einzelnen Schritte und erleichtert dadurch das Verständnis des Gesamtsystems. • Die Pipeline liefert die logische Struktur und damit die Voraussetzung für Ereignisagenten. Die Agenten werden wiederum benötigt, um die Regelbasis aufzuteilen und das System skalierbar zu machen (siehe das Ereignisagenten-Muster in Abschnitt 7.2.2). • Die Schritte der Pipeline sind sehr lose gekoppelt, denn die aufeinanderfolgenden Schritte kennen sich nicht. Es gilt somit Fire-and-Forget [15]: Die Ereignisse eines Schrittes werden an einen Ereigniskanal übergeben, was mit ihnen weiter geschieht, ist nicht bekannt. Grundsätzlich lässt sich die Pipeline auch lediglich als Konzept zur Modularisierung verwenden. Dann werden nach wie vor alle Regeln in einer einzigen zentralen Event Processing Engine ausgeführt. Die genannten Vorteile der Sequenzialisierung und der besseren Skalierbarkeit gelten dann zwar nicht mehr, aber zumindest liefern die Schritte eine logische Struktur der Regeln, die das Verständnis des Gesamtsystems erleichtert und es wartbarer macht. Die Struktur rein sequenzieller Schritte der Ereignisverarbeitung ist im gewissen Sinne eine Idealisierung. Gegebenenfalls sind Rückkopplungen zwischen Schritten erforderlich und sinnvoll, d.h., bestimmte, in einem Schritt produzierte Ereignisse werden an einen vorhergehenden Schritt geschickt. Solche Rückkopplungen stellen aber normalerweise eine Ausnahme dar. Generell erfolgt die Ereignisverarbeitung in Form einer linearen Pipeline. Die Abfolge der Verarbeitungsschritte in einer Pipeline strukturiert die Ereignisverarbeitung auf der obersten Abstraktionsebene.

7.3 Designmuster Die nachfolgend vorgestellten Designmuster beschreiben allgemeingültige Konzepte, die in einer Event-Driven Architecture zum Einsatz kommen. Dabei geht es nicht wie bei den Architekturmustern um die grundlegenden Strukturen, sondern

186

7 Entwurfsmuster

um Leitlinien zur Umsetzung der in jeder EDA zu erledigenden Aufgaben. Die Designmuster präzisieren somit die Verarbeitungsschritte aus dem im vorhergehenden Abschnitt vorgestellten Pipeline-Muster.

7.3.1 Konsistenz von Ereignissen Kontext und Problem: Nicht alle Ereignisse besitzen korrekte und konsistente Daten, wenn sie durch die Quellen generiert werden (siehe auch Abschnitt 4.4). Im Einzelnen können folgende Probleme auftreten: • Einzelne Attribute eines Ereignisobjektes weisen nichtzulässige, unsinnige oder auch fehlende Werte auf. Ursachen sind u.a. technische Probleme der Ereignisquellen, fehlerhafte Benutzereingaben oder inkonsistente Datenbestände. • Für ein real stattgefundenes Vorkommnis werden Ereignisobjekte mehrfach oder aber auch überhaupt nicht erzeugt [59]. Ursachen für überflüssige oder fehlende Ereignisobjekte sind ebenfalls technische Probleme sowie mehrfache oder fehlende Dateneingaben. Lösung: Es werden ein oder mehrere Bereinigungsschritte (cleaning) eingeführt, die alle fehlerhaften Ereignisobjekte in einen konsistenten, das heißt für die problemlose Weiterverarbeitung geeigneten Zustand überführen. Abbildung 7.5 zeigt die wesentliche Struktur der Ereignisbereinigung.

Ereignisverarbeitung (CEP)

Ereignisinstanzen

Ereignisinstanzen


CleaningRegeln

Regel

Regel

Constraint

Constraint

Ereignistyp

Ereignistyp Ereignismodell

Abb. 7.5 Herstellung der Ereigniskonsistenz

Regel

Constraint

Ereignistyp

7.3 Designmuster

187

Constraints Die an die Konsistenz eines bestimmten Ereignistyps gestellten Bedingungen müssen exakt spezifiziert sein. Idealerweise sind die Bedingungen für konsistente Ereignisse in Form von Constraints formal definiert, zum Beispiel mithilfe der Object Constraint Language (OCL) (vgl. Abschnitt 4.4). Normalerweise gelten für jeden Ereignistyp eine Menge von Constraints, die jeweils verschiedene Aspekte, wie Wertebereiche von Attributen oder kausale Abhängigkeiten zwischen Ereignissen, beschreiben. Cleaning-Regeln Jeder Constraint wird auf entsprechende Ereignisverarbeitungsregeln abgebildet. Das im Bedingungsteil der Regel definierte Ereignismuster beschreibt inkonsistente Ereignisobjekte; der Aktionsteil führt eine Behandlung der fehlerhaften Ereignisse durch. Wie bereits in Abschnitt 4.4 erläutert, gibt es verschiedene Möglichkeiten für die Behandlung fehlerhafter Ereignisse: Sie können herausgefiltert, korrigiert oder auch ignoriert werden. Die Art der geeigneten Fehlerbehandlung ist anwendungsabhängig. Position im Ereignisfluss Die Cleaning-Schritte können an verschiedenen Stellen innerhalb des Ereignisflusses durchgeführt werden. Insbesondere bei sensorbasierten Systemen besteht ein besonders hoher Bedarf, weil die von den Sensoren erzeugten Randereignisse aufgrund technischer Probleme häufig verfälscht sind. Dort können die Cleaning-Schritte durch einen dedizierten Event Processing Agent erfolgen, der über einen In-Adapter (vgl. Abschnitt 5.6) die Sensorereignisse empfängt (siehe Abbildung 7.6). Unmittelbar nach dem Lesen der Sensorereignisse führt er einen Cleaning-Schritt durch. Alternativ kann auch jeder einzelne EPA vor der Verarbeitung einen eigenen Cleaning-Schritt durchführen. Bewertung: Ein expliziter Cleaning-Schritt entkoppelt die Bereinigung inkonsistenter Ereignisobjekte von der eigentlichen Ereignisverarbeitung. Die im Ereignismodell definierten Constraints sind die Basis für die Konsistenz der Ereignisse. Die Constraints sind unabhängig von den eigentlichen Verarbeitungsregeln, denn sie beschreiben inhärente Eigenschaften der Ereignisse. Der Cleaning-Schritt gehört nicht zur unmittelbaren Ereignisverarbeitung, denn er erbringt keinen Erkenntnisgewinn, sondern stellt lediglich die für eine sinnvolle Ereignisbearbeitung erforderliche Basis her. Darüber hinaus ist die Ereignisbereinigung im Gegensatz zur Ereignisverarbeitung sehr stabil, sie wird normalerweise nicht oder selten verändert. Im Gegenzug kann die Ereignisverarbeitung von konsistenten Ereignissen ausgehen und muss sich um keine Maßnahmen zur Ereignisbereinigung kümmern. Insgesamt definiert das Muster die Ereignisbereinigung als eigenen Verarbeitungsschritt und entkoppelt sie damit von der eigentlichen Ereignisverarbeitung.

188

7 Entwurfsmuster Sensoren

In-Adapter

In-Adapter

Cleaning

Cleaning

EPA 1

EPA 2

Event Processing Network

Pipeline Verarbeitung EPA 3

Verarbeitung

Verarbeitung

EPA 4

EPA 5

Abb. 7.6 Verteilung der Cleaning-Schritte im Event Processing Network

7.3.2 Reduktion der Ereignismenge Kontext und Problem: EDA-basierte Systeme sind mit einer riesigen Menge von kontinuierlich eintreffenden Ereignissen konfrontiert. Eine der größten Herausforderungen des Complex Event Processing besteht darin, möglichst effizient Ereignismuster in der immens großen Ereigniswolke zu entdecken. Um diese Aufgabe zu erfüllen, muss die nahezu unendlich große Menge der aufgetretenen Ereignisse so weit wie möglich reduziert werden, denn offensichtlich lassen sich kleinere Ereignismengen schneller verarbeiten und erleichtern somit eine Ereignisverarbeitung in Echtzeit. Lösung: Es gibt eine Reihe von Verarbeitungsmustern, die dabei helfen, die Menge der betrachteten Ereignisse zu verkleinern. Diese Muster lassen sich miteinander kombinieren und zu verschiedenen Zeitpunkten einsetzen: Filtern von Ereignissen In einem Filterschritt (filtering) werden die für eine bestimmte Fragestellung bedeutsamen Ereignisse aus dem Ereignisstrom herausgefiltert und an die nachfolgenden Verarbeitungsschritte weitergeleitet (siehe Abbbildung 7.7, vgl. auch Abschnitt 5.4.4). Dabei kann die Selektion der relevanten Ereignisse nach beliebigen Kriterien erfolgen, die sich durch ein Ereignismuster ausdrücken lassen. Typischerweise gehen der Ereignistyp sowie bestimmte Attributwerte in die Auswahl der Ereignisse ein. Das Filtern von Ereignissen führt keinerlei Änderungen an den Ereignissen durch, sondern sorgt lediglich dafür, dass irrelevante Ereignisse bei der weiteren

7.3 Designmuster

189

Verarbeitung nicht mehr berücksichtigt werden müssen. Somit reduziert das Filtern die Menge der zu verarbeitenden Ereignisse.

vollständige Ereignisfolge

Filteragent

relevante Ereignisse

EPA

Abb. 7.7 Filtern von Ereignissen

Die technische Umsetzung des Filterns bedarf einiger Überlegung, denn in den meisten Event Processing Engines, beispielsweise in Esper, ist es nicht möglich, aufgetretene Ereignisse aus dem Ereignisstrom zu löschen. Um dieses Problem zu umgehen, bieten sich zwei praktische Lösungsansätze an: 1. Der Filterschritt kopiert die relevanten Ereignisse in Ereignisobjekte eines neuen Ereignistyps. Die nachgelagerten Verarbeitungsschritte verwenden dann nur noch diesen Typ. Sollen beispielsweise nur Transaction-Ereignisse mit hohem Umsatz verarbeitet werden, so erzeugt der Filternschritt für solche Ereignisse ein entsprechendes BigTransaction-Objekt. Dieses Vorgehen besitzt den Nachteil, dass so eine große Anzahl künstlicher Ereignistypen eingeführt wird, die keine neuen Ereigniskonzepte beschreiben. Sie sind lediglich ein technisches Hilfsmittel und führen dazu, dass die klaren Strukturen des Ereignismodells verloren gehen. 2. Ein spezieller Event Processing Agent fungiert als Filteragent. Dieser selektiert die relevanten Ereignisse und leitet nur diese an andere EPAs weiter. Die irrelevanten Ereignisse werden nicht weitergeschickt und bleiben somit der Außenwelt verborgen. Zusammenhang mit anderen Mustern Das Filtern von Ereignissen ist ein typischer Verarbeitungsschritt innerhalb einer Pipeline (vgl. Abschnitt 7.2.3). Filtern sollte am Anfang der Verarbeitungskette geschehen, um möglichst frühzeitig die Anzahl der Ereignisse zu reduzieren. Das Filter-Muster ist aus technischer Sicht einem Cleaning-Schritt (vgl. Abschnitt 7.3.1) sehr ähnlich. Allerdings geht es beim Cleaning darum, unsinnige Ereignisse zu entfernen oder auch zu korrigieren. Durch Filterschritte entfallen hingegen sinnvolle und konsistente Ereignisse, sie werden lediglich für die weitere Verarbeitung nicht benötigt. Content-based Routing In einem Event Processing Network mit mehreren EPAs ermöglicht Content-based Routing eine Aufteilung des Ereignisstroms auf verschiedene Teilströme. Der Ereigniskontext entscheidet darüber, an welche nachfolgenden EPAs ein aktueller EPA ein Ereignis weiterleitet (vgl. Abschnitt 5.6).

190

7 Entwurfsmuster

An jedem EPA sollten idealerweise nur diejenigen Ereignisse ankommen, die er auch in seinen Regeln verarbeitet. Im Normalfall erfolgt diese Aufteilung auf Basis der Ereignistypen (siehe Abbildung 7.8). In anderen Fällen, beispielsweise bei replizierten EPAs (siehe Abschnitt 7.2.2) werden auch die Inhalte eines Ereignisses berücksichtigt, um die Ziel-EPAs zu bestimmen.

EPA 2 EPA 3

EPA 4 EPA 1

Abb. 7.8 Content-based Routing in einem EPN

Damit verarbeiten die einzelnen EPAs reduzierte Ereignisteilmengen, denn sie empfangen nur solche Ereignisse, für die sie sich auch interessieren. Ein entsprechender Verteilungsmechanismus lässt sich in einer zentralen und einer verteilten Variante implementieren. • Bei der zentralen Lösung gehen sämtliche Ereignisse bei einem zentralen Verteiler-EPA (dispatcher) ein. Der Dispatcher kennt alle weiteren EPAs sowie die von ihnen benötigten Ereignistypen und kann so die Rolle des zentralen Ereignisverteilers spielen. Sind die EPAs auf verschiedenen Rechnern lokalisiert, so kann der Dispatcher auch die Ereignisse mithilfe entsprechender Transportmechanismen verschicken. • Im verteilten Ansatz übernimmt jeder EPA zusätzlich die Aufgaben eines lokalen Dispatchers. Somit weiß jeder einzelne EPA, an welche anderen EPAs er seine Ereignisse schicken muss. In beiden Ansätzen muss es einen Mechanismus geben, mit dessen Hilfe ein EPA mitteilen kann, welche Ereignistypen er benötigt. Zusammenhang mit anderen Mustern Content-based Routing deckt einen Teilaspekt des Ereignisagenten-Musters ab, nämlich die Steuerung des Ereignisflusses zwischen EPAs. Es kann auch als spezielles Filtern verstanden werden, weil die an einen bestimmten EPA zu schickenden Ereignisse zuvor selektiert werden müssen. Reduktionsfenster In kontinuierlichen Ereignisströmen lässt sich durch ein Reduktionsfenster ein Ausschnitt festlegen und so die betrachtete Ereignismenge einschränken. Die bereits vorgestellten Sliding Windows dienen in Event Processing Languages als Sprachkonstrukt zur Definition solcher Fenster (vgl. Abschnitt 5.2). Dabei kann die Größe des Fensters durch ein Zeitintervall (= Zeitfenster) oder durch die Anzahl der betrachteten Ereignisse (= Längenfenster) festgelegt werden. Reduktionsfenster bilden eine Art zeitlicher Filter: Sie transformieren unendliche Ereignisströme in endliche Ereignismengen und ermöglichen damit eine effiziente Ereignisverarbeitung (siehe Abbildung 7.9).

7.3 Designmuster

191 Sliding Time Window


Zeit

Abb. 7.9 Reduktionsfenster

Zusammenhang mit anderen Mustern Reduktionsfenster kommen als durchgängiges Mittel in eigentlich jeder Phase der Verarbeitungs-Pipeline zum Einsatz. Einerseits können sie einfach zur Beschränkung der Ereignisströme dienen. Andererseits werden sie aber auch bei der Definition komplexer zeitlicher Korrelationen verwendet (vgl. Abschnitt 7.3.4). Bewertung: Für eine effiziente Ereignisverarbeitung sollte die Anzahl der zu verarbeitenden Ereignisse reduziert werden. Die drei vorgestellten Muster erfüllen an verschiedenen Stellen innerhalb der Ereignisverarbeitungsschicht diese Aufgabe. Dabei ist für alle Muster kennzeichnend, dass sie keine Ereignisse verändern oder neue komplexe Ereignisse erzeugen. • Das Filtern von Ereignissen absorbiert sämtliche Ereignisse, die für die nachgelagerte Verarbeitung irrelevant sind. Das Filtern sollte möglichst früh in der Verarbeitungs-Pipeline erfolgen, um die betrachteten Ereignismengen zu verkleinern. • Das Content-based Routing dient der Aufgliederung und Steuerung der Ereignissströme in einem Event Processing Network. Genau genommen reduziert es nicht die Ereignismengen, sondern verteilt sie auf verschiedene EPAs. Ein einzelner EPA ist dann allerdings mit weniger Ereignissen konfrontiert. • Schließlich dienen Reduktionsfenster dazu, zeitliche Filter zu setzen und aus kontinuierlichen Ereignisströmen beschränkte Ereignismengen zu extrahieren. Das Sprachkonstrukt der Sliding Windows wird auf der Ebene einzelner Ereignismuster durchgehend in der Ereignisverarbeitung eingesetzt.

7.3.3 Transformation von Ereignissen Kontext und Problem: Ereignisobjekte besitzen nicht immer eine für die weitere Bearbeitung optimierte Form. Dabei können zwei verschiedene Probleme unterschieden werden:

192

7 Entwurfsmuster

1. Ereignisse stammen aus verschiedenen Ereignisquellen und besitzen unterschiedliche proprietäre Formate, die die Event Processing Engines nicht unmittelbar verarbeiten können. Dies gilt auch für Ereignisse, die über ein Netzwerk versendet und deshalb serialisiert werden müssen. 2. Oft sind die in den Ereignissen mitgeführten Daten für die weitere Verarbeitung unvollständig. In den meisten Event Processing Languages lässt sich deshalb in die Ereignismuster ein Zugriff auf die operativen Systeme einbauen, um die erforderlichen Daten zu beschaffen. Ein solches Vorgehen ist aber sehr zeitaufwändig, weil die Daten in vielen Mustern immer wieder per Methodenaufruf beschafft werden. Die Zugriffe auf die operativen Systeme sollten deshalb möglichst selten erfolgen. Lösung: In einem Transformationsschritt werden die Ereignisse in eine geeignete Form überführt. Eine Transformation ist dadurch gekennzeichnet, dass sich die Anzahl der Ereignisse nicht ändert, d.h., für jedes Eingangsereignis wird ein Ausgangsereignis erzeugt. Dabei lassen sich für die beiden genannten Probleme entsprechende Arten von Transformationsschritten unterscheiden: (1) Translation und (2) ContentEnrichment. Translation Ein reiner Übersetzungsschritt10 überführt die Ereignisbeschreibungen in ein anderes (Daten-)Format. Insbesondere fügt ein solcher Schritt keine zusätzliche Information hinzu. Das Zielformat ist das von den Event Processing Engines der EPAs verarbeitbare bzw. in einem Netzwerkprotokoll nutzbare Format.11

Translation

übersetzte Ereignisse

Abb. 7.10 Translationsschritt zur Serialisierung von Ereignissen

Zusammenhang mit anderen Mustern Das Translation-Muster betrachtet einen speziellen Aspekt der EDA-Schichten, nämlich den Übergang zwischen der Monitoringund der Ereignisverarbeitungsschicht. Darüber hinaus wird ein Teilaspekt von Ereignisagenten beleuchtet, nämlich wie sie untereinander Ereignisse austauschen können, wenn sie auf unterschiedlichen Servern lokalisiert sind. Hierzu ist eine Serialisierung der Ereignisobjekte erforderlich, die als besondere Form der Translation verstanden werden kann. 10 11

Vgl. auch Abschnitt 5.3. Beispielsweise XML-Datensätze.

7.3 Designmuster

193

Content-Enrichment In einem Content-Enrichment-Schritt werden die Ereignisobjekte selbst mit allen erforderlichen Informationen angereichert, die sie in den nachgelagerten Verarbeitungsschritten benötigen. Dieser Ansatz ersetzt viele zeitaufwändige Datenzugriffe auf die operativen Systeme durch einen einzigen Zugriff, (siehe Abbildung 7.11).12 Mithilfe von Content-Enrichment werden die Daten also nur einmalig beschafft, in die Ereignisobjekte integriert und stehen somit dauerhaft und ohne weiteren Aufwand den nachfolgenden Verarbeitungsschritten zur Verfügung. Technisch gesehen fügt das Content-Enrichment den Ereignisobjekten neue Attribute hinzu oder ändert deren Werte.

ContentEnrichment operatives System

operatives System

Datenzugriff

Abb. 7.11 Verarbeitungs-Pipeline mit Content-Enrichment

Mit Informationen angereicherte Ereignisse führen zu besser verständlichen Ereignismustern. Die Muster beziehen sich ausschließlich auf Ereignisse und deren Attribute. Sie beinhalten keine Methodenaufrufe, deren genaue Semantik oft nicht klar auszumachen ist. Zusammenhang mit anderen Mustern Das Content-Enrichment kann als ein Verarbeitungsschritt in der Ereignisverarbeitungs-Pipeline aufgefasst werden. Bewertung: Die Transformation überführt die Ereignisobjekte in eine für die weitere Verarbeitung optimierte Form. Dabei sind zwei Teilaspekte zu betrachten, die jeweils ein eigenes Entwurfsmuster adressieren. • Ein Translation-Schritt passt das Datenformat eines Ereignisses den Erfordernissen an. Dazu werden vorliegende Ereignisformate in ein einheitliches Datenformat übersetzt. • Content-Enrichment sorgt dafür, dass Ereignisobjekte in dem Sinne vollständig (self-contained) sind, dass sie alle für die weitere Verarbeitung erforderlichen Informationen enthalten. Dazu werden sie mit strukturellen, historischen oder domänenspezifischen Daten angereichert, um die Anzahl sonst erforderlicher Backend-Zugriffe zu minimieren. 12

Meist ist ein solcher Zugriff relativ teuer, weil er entfernt und ggf. mit Datenbankzugriffen verbunden ist.

194

7 Entwurfsmuster

Eine Translation oder ein Content-Enrichment lässt sich in den meisten Systemen technisch nur durch Erzeugung neuer Ereignisobjekte erreichen.13 Insgesamt wird die Transformation von Ereignissen von der originären Verarbeitung entkoppelt. Es ist zu beachten, dass beide Entwurfsmuster jeweils nur einzelne Ereignisse behandeln, um sie zu übersetzen oder anzureichern. Ereignismuster, die Zusammenhänge zwischen mehreren Ereignissen betrachten und Korrelationen herstellen, werden nicht betrachtet.

7.3.4 Synthese von Ereignissen Kontext und Problem: Der kontinuierliche Strom einfließender Ereignisse soll mittels Complex Event Processing analysiert und “verstanden“ werden. Das Ziel ist also, aus der riesigen Menge der aufgetretenen Einzelereignisse eine Bedeutung zu extrahieren. Dazu müssen einzelne Ereignisse in Zusammenhang gestellt und zu neuen abstrakteren Ereignissen synthetisiert werden. Insbesondere müssen für die folgenden Probleme und Fragestellungen allgemeine Leitlinien und Antworten gefunden werden: • Was sind die allgemeinen Dimensionen der Korrelation, um zusammenhängende Ereignisse zu finden? Es bedarf also Leitlinien, um in Beziehung stehende Ereignisse zu korrelieren. • Wie lassen sich viele detaillierte Einzelereignisse zu einem abstrakteren Ereignis zusammenfassen? Gesucht werden also Muster, die zu einer Verschiebung der Granularität (granularity shift) führen. • Wie kann eine Verschiebung der Semantik (semantical shift) erreicht, also eine Bedeutung aus der Menge der für sich unbedeutenden Einzelereignisse gewonnen werden? Lösung: In einem Syntheseschritt werden zunächst die in der Ereigniswolke enthaltenen Ereignisse gemäß verschiedener Dimensionen korreliert. Anschließend werden die korrelierten Ereignisse zu bedeutungsvolleren Ereignissen zusammengefasst oder synthetisiert. Dabei findet entweder ein Granularitäts-Shift in Form einfacher Aggregationen oder ein Semantik-Shift durch Erzeugen komplexer Ereignisse statt. Dimensionen der Korrelation Eine Menge korrelierter Ereignisse, ein sogenanntes Correlation Set, enthält alle Ereignisse mit einem bestimmten Kontext, d.h. die Menge aller Ereignisobjekte, die bestimmte Bedingungen erfüllen. Correlation Sets werden mithilfe von Ereignismustern beschrieben und führen zu einer Partitionie13

Vgl. die Diskussion zum Filter-Muster.

7.3 Designmuster

195

rung der Ereignismenge. Sie können gemäß fachlicher, zeitlicher und räumlicher Dimensionen gebildet werden (vgl. auch Abschnitt 4.2): • Fachliche Korrelation (domain-specific correlation) Ereignisse lassen sich auf Basis ihrer fachlichen Zusammenhänge strukturieren, d.h., die Korrelation basiert auf domänenspezifischen Kriterien. Ein Ereignismuster bezieht sich in der Regel auf die Ereignisse, die einen bestimmten fachlichen Kontext besitzen. Insbesondere kausale Abhängigkeiten14 von Ereignissen sind eine Form der fachlichen Korrelation. Zur Erkennung von Kreditkartenbetrug werden z.B. alle Transaktionen eines bestimmten Kunden betrachtet. Im Wertpapierhandel bilden alle Kursereignisse, die sich auf eine bestimmte Aktie beziehen, ein Correlation Set (siehe Abbildung 7.12).


sun 13,45 ibm 80,50

SAP 81,23

ibm 84,72 SAP 82,12

sun 14,30

SAP 78,98 ibm 82,21

ibm 91,34

sun 11,45

sun 12,32

SAP 82,34

SAP 90,45

sun 12,84

Abb. 7.12 Fachliche Correlation Sets in einem Ereignisstrom

Fachliche Korrelationen lassen sich mithilfe logischer Operatoren auf den Ereignisattributen beschreiben.15 In den meisten Event Processing Languages gibt es keine spezifischen Sprachkonstrukte zur Definition fachlicher Korrelationen. • Zeitliche Korrelation (temporal correlation) Der Auftrittszeitpunkt ist eine inhärente Eigenschaft jedes Ereignisses. Viele Muster beziehen sich deshalb auf zeitliche Beziehungen zwischen Ereignissen. Die Korrelation erfolgt also auf Basis zeitlicher Eigenschaften. Zum Beispiel wird im Wertpapierhandel eine Situation gesucht, in der der Kurs einer bestimmten Aktie nach wiederholtem Kursabfall wieder ansteigt. Dieses Beispiel berücksichtigt mehrere orthogonale Korrelationskriterien: Hier werden sowohl zeitliche (die letzten Kursereignisse) wie auch fachliche Zusammenhänge (alle Kursereignisse einer bestimmten Aktie) betrachtet. Zeitliche Korrelationen können mithilfe temporaler Operatoren spezifiziert werden. Einerseits legt der Sequenzoperator “→“ zeitliche Reihenfolgen für zeitlich aufeinanderfolgende Ereignisse fest. Andererseits dienen Fenster zur Festlegung von zeitlichen Abständen. Abbildung 7.13 zeigt ein solches Muster. Auch die Aggregation von Ereignissen erfordert in der Regel einen zeitlichen Bezugsrahmen. So ist das Berechnen von Attributsummen oder Durchschnittswerten nur für einen durch ein Fenster festgelegten Zeitraum sinnvoll. 14 15

Vgl. Abschnitt 4.2. Z.B. in der Where-Klausel einer Esper-Regel.

196

7 Entwurfsmuster Sliding Time Window


Zeit

Abb. 7.13 Zeitliche Korrelation von Ereignissen mit temporalen Operatoren und Sliding Windows

• Räumliche Korrelation (spatial correlation) In vielen Systemen spielt auch der Ort, an dem ein Ereignis entstanden ist, eine große Rolle. Räumliche Aspekte (occurrence space) sind besonders bei sensorbasierten Systemen von Bedeutung. Die Ereignisse, die an einem bestimmten Sensor gemessen wurden, werden zusammen betrachtet. Oft lassen sich aus örtlich nahe liegenden Ereignissen wichtige Rückschlüsse ziehen. Zum Beispiel werden im Verkehrskontrollsystem die Daten, die von den Sensoren eines Straßenabschnitts stammen, zu Kennzahlen verdichtet. Unterschiedliche Messwerte an unmittelbar benachbarten Sensoren lassen wiederum auf Probleme schließen (vgl. Abschnitt 3.4). Räumliche Korrelation lässt sich mithilfe spezieller räumlicher Operatoren (spatial operators) definieren. Diese Operatoren können auch als Space Coordinates Windows aufgefasst werden, die analog zu den Sliding Windows räumliche Nähe beschreiben. Abbildung 7.14 zeigt solche “räumlichen Fenster“ an einem Beispiel. Derzeit existieren keine professionellen Event Processing Languages mit speziellen Sprachkonzepten zur Beschreibung räumlicher Zusammenhänge. Die verschiedenen Dimensionen der Korrelation kommen in den meisten Ereignismustern kombiniert zum Einsatz. Sie können auch als Raum-Zeit-Muster (spatio temporal patterns) bezeichnet werden. Zum Beispiel werden alle Ereignisse betrachtet, die an einem bestimmten Ort in einem definierten Zeitraum aufgetreten sind und bestimmten fachlichen Bedingungen genügen. Granularitäts-Shift Ein wichtiger Aspekt des Complex Event Processing ist, eine Verschiebung der Ereignisgranularität zu erreichen. Viele (zu) detaillierte Einzelereignisse sollen zu einem neuen, abstrakteren Ereignis (composite event) zusammengefasst werden. Dazu wird ein Aggregationsschritt durchgeführt, der die Daten der Einzelereignisse zu einem neuen Ereignis zusammenfasst oder aggregiert.16 Die Aggregation von Ereignissen ist durch folgende Eigenschaften gekennzeichnet: • Die Ereignismuster, mit denen die Correlation Sets gebildet werden, sind oft sehr einfach und sie beziehen sich meist auf nur einen Ereignistyp. Typischerweise werden über einen definierten Zeitraum alle Ereignisse eines Typs aus einer 16

Vgl. die Abschnitte 4.2 und 5.3.

7.3 Designmuster

197

y

x

Abb. 7.14 Räumliche Korrelation von Ereignissen mithilfe von Space Coordinates Windows

bestimmten Ereignisquelle oder mit einem bestimmten fachlichen Kontext (beispielsweise alle Ereignisse mit einer speziellen RFID-Tag-ID) aggregiert. • Die Aggregation der Daten der Einzelereignisse erfolgt durch relativ einfache Operationen. Typischerweise werden arithmetische Mengenoperationen auf den Attributen der Ereignisse im Correlation Set durchgeführt, beispielsweise eine Summen- oder Durchschnittsbildung. Abbildung 7.15 zeigt ein Beispiel, das Ereignisse eines bestimmten Typs in einem Sliding Window aggregiert. Die “weißen“ Ereignisse werden zu einem Ereignis aggregiert, das die Summe der Attributwerte bildet. Das Aggregatereignis für die “grauen“ Ereignisse bildet das Produkt der Werte. Im Szenario unseres Verkehrskontrollsystems werden “Verkehrsdatenereignisse“ erzeugt, die die Durchschnittsgeschwindigkeit über alle Sensorereignisse an einem bestimmten Sensor enthalten. Der entsprechende Bezugsraum ist dabei ein bestimmtes Zeitfenster. Die Aggregation von Ereignissen verwendet also keine komplexen Regeln und generiert somit auch keine weitreichenden neuen Erkenntnisse. Vielmehr entsteht eine Verschiebung der Granularität von Ereignissen. Die bisher beobachteten Einzelereignisse werden zusammengefasst und auf einem höheren Abstraktionsniveau betrachtet. Semantik-Shift Die Kernaufgabe des Complex Event Processing ist die Verschiebung der Ereignissemantik. Die Einzelereignisse eines Correlation Set werden dazu auf ein neues komplexes Ereignis (complex event) abgebildet, das der Menge der aufgetretenen Ereignisse eine neue, nichtoffensichtliche semantische Bedeutung

198

7 Entwurfsmuster

Summe

2

4

3

1

1

2

3

6

4

Produkt

aggregierte Ereignisse

einfache Ereignisse Aggregation

Abb. 7.15 Granularitäts-Shift

gibt. Die Synthese von komplexen Ereignissen ist durch folgende Eigenschaften charakterisiert:17 • Die Correlation Sets, die der Erzeugung komplexer Ereignisse zugrunde liegen, basieren auf relativ komplexen Ereignismustern. Meist beschreiben sie Zusammenhänge zwischen Ereignissen unterschiedlicher Ereignistypen und definieren Ereignisbeziehungen mithilfe von zeitlichen Reihenfolgebedingungen.18 Zum Beispiel wird zur Erkennung von Betrugsversuchen eine Folge von Ereignissen gesucht, bei der für dasselbe Konto zunächst das Passwort geändert und dann unmittelbar danach ein großer Geldbetrag abgehoben wird. • Das erzeugte komplexe Ereignis enthält in der Regel nur wenige Daten der im zugrunde liegenden Correlation Set enthaltenen Einzelereignisse. Meist sind bei komplexen Ereignissen nicht die Daten entscheidend, sondern von Bedeutung ist, dass ein komplexes Ereignismuster erfüllt wurde. Abbildung 7.16 gibt ein Beispiel für die Erzeugung eines komplexen Ereignisses auf Basis eines Ereignismusters. Wenn innerhalb eines Sliding Window die Attributwerte der “weißen“ Ereignisse stetig ansteigen und die der “grauen“ Ereignisse sinken, dann wird ein neues komplexes Ereignis erzeugt. Im Beispiel des Wertpapierhandels wird auf Basis eines komplexen Musters ein Kaufsignal-Ereignis für eine bestimmte Aktie erzeugt. Dieses komplexe Ereignis enthält vielleicht nur das Symbol der zu kaufenden Aktie und keine weiteren (aggregierten) Daten aus der Vielzahl von Ereignissen, die es ausgelöst haben. Bei der Erzeugung eines komplexen Ereignisses wird also Expertenwissen auf ein Ereignismuster abgebildet, das aus einer bestimmten Konstellation von Einzelereignissen einen anwendungsspezifischen Sinn ableitet. So lassen sich also neue, über die Beobachtung der Einzelereignisse hinausgehende Erkenntnisse gewinnen und eine Verschiebung der Semantik wird erreicht. Den bisher beobachteten Einzelereignissen kommt eine neue Bedeutung zu. Zusammenhang mit anderen Mustern Die Synthese von Ereignissen ist einer der Schritte in der Verarbeitungs-Pipeline. Dabei können einzelne Schritte der Verarbeitungs-Pipeline vornehmlich für die Verschiebung der Granularität (Aggregation) 17 18

Vgl. auch Abschnitte 4.2 und 5.3. Also unter Verwendung des Sequenzoperators “→“.

7.3 Designmuster

4

1

4

199

2

einfache Ereignisse

2

4

6

0 komplexes Ereignis Muster

Abb. 7.16 Semantik-Shift

und nachfolgende Schritte für die Verschiebung der Semantik (Erzeugung komplexer Ereignisse) zuständig sein. Darüber hinaus ist die Ereignissynthese ein weiteres Mittel zur Reduktion der Ereignisanzahl. Aggregierte und komplexe Ereignisse fassen einfache Ereignisse zu einem neuen Ereignis zusammen und verringern so die Anzahl der in nachfolgenden Verarbeitungsschritten betrachteten Ereignisse. Bewertung: Die Synthese von Ereignissen ist das zentrale Konzept zur Verarbeitung von Ereignisströmen in einer Event-Driven Architecture. Die Synthese fasst Einzelereignisse zusammen und überführt diese in neue Ereignisse auf einer höheren Abstraktionsebene. Als Voraussetzung für die Ereignissynthese muss zunächst die Menge der zusammenzufassenden Ereignisse in Form von Correlation Sets festgelegt werden, die auf Basis fachlicher, zeitlicher oder räumlicher Zusammenhänge gebildet werden. Meist werden die drei Dimensionen kombiniert in den Ereignismustern eingesetzt. Die Menge der korrellierten Ereignisse wird dann zu einem neuen Ereignis zusammengefasst. Dabei werden zwei Typen unterschieden: • Aggregierte Ereignisse beruhen auf relativ einfachen Ereignismustern und bieten in der Regel keinen großen Erkenntnisgewinn, sondern fassen Ereignisdaten zusammen. Sie führen damit zu einer Verschiebung der Granularität hin zu abstrakteren, grobgranulareren Ereignissen. • Komplexe Ereignisse werden durch hochkomplexe Muster beschrieben. Ihre Bedeutung erhalten sie dadurch, dass das entsprechende Ereignismuster eingetreten ist. Sie verleihen einer bestimmten Konstellation im Ereignisstrom damit eine Bedeutung und führen somit zu einer Verschiebung der Semantik. Die Abgrenzung von aggregierten und komplexen Ereignissen ist nicht immer ganz einfach. In manchen Situationen lässt sich diskutieren, ob ein erzeugtes Ereignis bereits “komplex“ ist oder nur Daten aggregiert. In jedem Fall macht erst die Synthese von Ereignissen die Mächtigkeit des Complex Event Processing aus. Nur die Zusammenfassung von Einzelereignissen ermöglicht es, sich von der “one-event-at-a-time EDA“ zu lösen (vgl. Abschnitt 3.1

200

7 Entwurfsmuster

und [99]). Die Synthese von Ereignissen gestattet es, Einzelereignisse im Zusammenhang zu sehen, die Bedeutung kontinuierlicher Ereignisströme zu verstehen und somit angemessen und in Echtzeit auf neue Ereignisse zu reagieren.

Kapitel 8

Referenzarchitekturen

Zusammenfassung Referenzarchitekturen dienen als Vorlage für die konkrete Umsetzung einer Softwarearchitektur in einem bestimmten Kontext oder Anwendungsfeld. In diesem Kapitel wird eine allgemeine Referenzarchitektur für EventDriven Architecture abgeleitet, die die wesentlichen Softwarebausteine und die Konstruktionsprinzipien von EDA-basierten Systemen in ihrer Gesamtheit darstellt. Die Referenzarchitektur integriert die im vorherigen Kapitel vorgestellten EDA-Entwurfsmuster zu einem Gesamtsystem. Dieses Kapitel stellt zunächst die Grundstrukturen für eine allgemeine Referenzarchitektur mit den wichtigsten EDAKomponenten vor, und zeigt darüber hinaus, wie diese auf ein verteiltes System abgebildet werden können. Anschließend wird diese allgemeine Referenzarchitektur für zwei Anwendungsszenarien, EDA-basierte Sensornetzwerke sowie EDAbasierte Analysesysteme, konkretisiert und verfeinert.

8.1 Referenzarchitekturen für Event-Driven Architecture Die im vorangegangenen Kapitel vorgestellten Entwurfsmuster geben Leitlinien vor, die bei der Entwicklung einer Event-Driven Architecture sehr hilfreich sind. Allerdings betrachten Entwurfsmuster die dabei auftretenden Probleme und Fragestellungen voneinander isoliert. Der Entwickler eines EDA-basierten Systems muss also die vorgestellten Entwurfsmuster zu einer Softwarearchitektur des Gesamtsystems integrieren. Softwarearchitekturen Inzwischen ist der Begriff der Softwarearchitektur etabliert und es hat sich ein einheitliches Verständnis herausgebildet, was eine Softwarearchitektur auszeichnet [10, 29, 100].


201

202

8 Referenzarchitekturen

Softwarearchitektur Eine Softwarearchitektur beschreibt die übergeordnete Struktur eines Softwaresystems und deren globale Kontrollstrukturen. Sie beschreibt die wesentlichen Softwarebausteine in Form von Komponenten und legt fest, wie diese interagieren und kooperieren. Auf eine Softwarearchitektur gibt es verschiedene Sichten [61]. Dabei lassen sich eine statische Struktursicht (logical view) und eine dynamische Verhaltenssicht (process view) unterscheiden. Darüber hinaus gibt es eine Abbildungssicht auf die Softwareartefakte (development view)1 sowie auf die Ausführungseinheiten (physical view)2. Eine Softwarearchitektur wird für unterschiedliche Zielgruppen mit einem auf sie angepassten Detaillierungsgrad beschrieben. Dabei entstehen verschiedene Dokumente. Ein Architektursteckbrief verschafft einen Überblick über die wesentlichen Strukturen und Softwarebausteine, eine detaillierte Architekturdokumentation beschreibt alle Komponenten und Abläufe im Detail. Darüber hinaus ist ein Entwicklerhandbuch hilfreich, das kochbuchartig darstellt, wie im Rahmen der Architektur ein Softwaresystem entwickelt wird. Referenzarchitekturen Für ein bestimmtes Anwendungsszenario muss eine konkrete Softwarearchitektur in einem eigens dafür aufgesetzten Projekt entwickelt werden. Um diese Aufgabe zu erleichtern, sind sogenannten Referenzarchitekturen wichtig, die bei der Entwicklung einer konkreten Architektur als Vorlage dienen [91]. Referenzarchitektur Eine Referenzarchitektur (reference architecture) ist eine generische oder abstrakte Softwarearchitektur, die für eine Klasse von Softwaresystemen eingesetzt werden kann. Eine solche Klasse von Softwaresystemen ist durch ähnliche Anforderungen und Einsatzgebiete gekennzeichnet. Oft wird auch von Produktlinien gesprochen (siehe z.B. [88]). Referenzarchitekturen versuchen die wesentlichen Ideen (essentials) von verwandten Softwarearchitekturen zu extrahieren. Die konkrete Softwarearchitektur für ein spezielles System lässt sich aus der Referenzarchitektur ableiten, indem diese verfeinert und an die konkreten Anforderungen angepasst wird. In gewissem Sinne beschreibt eine Referenzarchitektur eine idealisierte oder archetypische Softwarearchitektur, die als Vorbild dient und für einen bestimmten Einsatzfall konkretisiert werden muss. Eine Referenzarchitektur kann als ein Muster für eine konkrete Architektur betrachtet werden. 1

Abbildung der Komponenten auf Pakete oder Module. Abbildung der Komponenten auf Systemsoftware (Datenbanksysteme, Applikationsserver) und Hardwarekomponenten. 2

8.2 Allgemeine Referenzarchitektur

203

In den folgenden Abschnitten wird eine Referenzarchitektur für eine EventDriven Architecture erarbeitet. Zunächst stellt dazu der nächste Abschnitt eine allgemeine domänenunabhängige Referenzarchitektur vor. Anschließend zeigen die beiden letzten Abschnitte, wie sich die allgemeine Referenzarchitektur auf spezifische Anwendungsszenarien anpassen lässt. Bisher gibt es nur sehr wenige Arbeiten, in denen solche Referenzarchitekturen für Event-Driven Architecture diskutiert werden [27]. Zu dieser Thematik sind noch einige weitere Ergebnisse erforderlich, damit sich EDA zukünftig auf breiter Front in der Praxis durchsetzt.

8.2 Allgemeine Referenzarchitektur Struktursicht – EDA-Schichten und -Komponenten Die Grundstruktur verschiedener EDA-basierter Systeme ist sehr ähnlich und unterscheidet sich nicht wesentlich bei Anwendungen aus unterschiedlichen Domänen. Dieser Abschnitt führt eine allgemeine Referenzarchitektur ein, die alle grundlegenden Entwurfsmuster aus Kapitel 7 zusammenbringt, die anwendungsunabhängig eingesetzt werden können.

Monitoring technischer Zugriff

Translation

Cleaning Ereigniskonsistenz

In-Adapter


Filterung

ContentEnrichment

Ereignisreduktion

Ereignistransformation

GranularitätsShift

SemantikShift

Ereignissynthese

Ereignisbehandlung Strukturelle Daten

Historische Daten


Services

Ereignisfluss

Abb. 8.1 Allgemeine Referenzarchitektur für EDA

Visualisierung

204


Abbildung 8.1 zeigt die statische Struktur der Referenzarchitektur mit ihren verschiedenen Komponenten. Die globale Struktur der Architektur ist durch das EDASchichten-Muster3 mit den entsprechenden Schichten “Monitoring“, “Ereignisverarbeitung" und “Ereignisbehandlung" festgelegt. Monitoring Die Monitoring-Schicht realisiert den technischen Zugriff auf die verschiedenen Ereignisquellen sowie die Vorbehandlung der Ereignisse. Im Einzelnen umfasst dies die folgenden Aufgaben (siehe Abbildung 8.2):

Monitoring technischer Zugriff

Translation

In-Adapter

Cleaning Ereigniskonsistenz

Abb. 8.2 Monitoring-Schicht in der Referenzarchitektur

• In-Adapter: Der In-Adapter implementiert den technischen Zugriff (access) auf die Ereignisquellen.4 Dazu liest er mittels entsprechender Techniken die von den Ereignisquellen erzeugten Ereignisdaten. In einem anschließenden TranslationSchritt5 werden die proprietären Ereignisdaten der Ereignisquellen in Ereignisobjekte übersetzt, d.h. in ein Datenformat, das die in den nachgelagerten Schritten verwendeten Event Processing Engines verstehen können. • Ereigniskonsistenz: Die vom In-Adapter erzeugten Ereignisobjekte werden nun einem gesonderten Cleaning-Schritt6 unterzogen. Fehlerhafte oder doppelte Ereignisse werden in diesem Schritt aussortiert bzw. korrigiert. Ereignisverarbeitung In die Ereignisverarbeitungsschicht gelangen ausschließlich konsistente Ereignisse, deren regelbasierte Verarbeitung in dieser Schicht stattfindet. Dabei kommt das Pipeline-Entwurfsmuster7 mit drei allgemeinen Verarbeitungsschritten zum Einsatz (siehe Abbildung 8.3). 1. Ereignisreduktion: Zunächst versucht der erste Schritt der Verarbeitungskette, die Anzahl der Ereignisse möglichst frühzeitig zu reduzieren. Dies geschieht mit einem Filter-Schritt8 , der alle für die weitere Verarbeitung unbedeutenden Ereignisse logisch aus dem Verarbeitungsstrom entfernt. 2. Ereignistransformation: Die somit herausgefilterten relevanten Ereignisobjekte reichert der nächste Schritt mit den für die nachfolgenden Verarbeitungsschritte 3 4 5 6 7 8

Siehe Abschnitt 7.2. Siehe Abschnitt 6.2. Siehe das Transformationsmuster in Abschnitt 7.3.3. Siehe Konsistenz von Ereignissen in Abschnitt 7.3.1. Siehe Abschnitt 7.2.3. Vgl. Ereignisreduktion in Abschnitt 7.3.2.



Filterung

ContentEnrichment

Ereignisreduktion

Ereignistransformation

GranularitätsShift

SemantikShift

Ereignissynthese

Abb. 8.3 Ereignisverarbeitungsschicht in der Referenzarchitektur

benötigten Informationen an (Content-Enrichment9). Dazu werden strukturelle Daten aus den operativen Systemen gelesen und in die Ereignisobjekte eingebracht. Das Content-Enrichment reduziert so die Anzahl der Zugriffe auf die Backend-Systeme. Insbesondere die Attribute technischer Ereignisse sind oft unvollständig. Mit ihnen lassen sich gut lesbare Regeln kaum formulieren, sie müssen auf anwendungsspezifische Konzepte, wie Orte, Waren, Aufträge usw., abgebildet werden. 3. Ereignissynthese: Der letzte Schritt innerhalb der Verarbeitungskette ist auch gleichzeitig der entscheidende: In ihm werden die gefilterten und mit Daten angereicherten Einzelereignisse zu neuen und abstrakteren Ereignissen zusammengefasst10 . Dieser Schritt ist mitunter komplex und besteht ggf. selbst aus einer eigenen Verarbeitungs-Pipeline. Welche Schritte diese Pipeline genau durchführt, ist anwendungsspezifisch und lässt sich in der allgemeinen Referenzarchitektur nur relativ allgemein beschreiben: • Granularitäts-Shift In Aggregationsschritten11 werden mithilfe einfacher, oft numerischer Operationen Einzelereignisse zu neuen Ereignissen zusammengefasst. Die Aggregation berechnet beispielsweise Summen oder Durchschnittswerte und erreicht so einen Granularitäts-Shift der betrachteten Ereignisse. • Semantik-Shift Nachfolgend bilden komplexe Regeln aus Ereignisobjekten, die zueinander in komplexen zeitlichen, räumlichen oder fachlichen Beziehungen stehen, Correlation Sets. Die Einzelereignisse von Correlation Sets werden auf ein neues komplexes Ereignis abgebildet, das der Menge der aufgetretenen Ereignisse eine neue semantische Bedeutung verleiht. Es entsteht ein Semantik-Shift, da die Regeln aus den vorliegenden Einzelereignissen einen übergreifenden Sinn ableiten. Ein komplexes Ereignis kann zu unmittelbaren Reaktionen in den operativen Systemen führen. Die im Rahmen der Ereignissynthese ablaufende Verarbeitungs-Pipeline muss für das jeweilige Anwendungsszenario angepasst und konkretisiert werden. Ex-

9

Vgl. Ereignistransformationen in Abschnitt 7.3.3. Vgl. Abschnitt 7.3.4 – Ereignissynthese. 11 Siehe ebenfalls Abschnitt 7.3.4. 10

206


emplarisch stellen die beiden folgenden Abschnitte solche Konkretisierungen vor. Abschließend bleibt anzumerken, dass die Verarbeitungs-Pipeline der Ereignisverarbeitungsschicht gegebenenfalls auch anders strukturiert werden kann. So können zum Beispiel auch zusätzliche Filter- und Aggregationsschritte in die Ereignissynthese-Phase aufgenommen werden. Ereignisbehandlung In der Ereignisbehandlungsschicht werden die komplexen Ereignisse behandelt. Darüber hinaus hält sie die für die Ereignisverarbeitung erforderlichen Daten vor. Abbildung 8.4 zeigt die grundlegende Struktur dieser Schicht.

Ereignisbehandlung Strukturelle Daten

Historische Daten


Services

Visualisierung

Abb. 8.4 Ereignisbehandlungsschicht in der Referenzarchitektur

• Zum einen stellt die Ereignisverarbeitungsschicht strukturelle und historische Daten zur Verfügung. Diese Daten werden zum Beispiel benötigt, um technische IDs der Randereignisse in fachliche Konzepte abzubilden, um quantitative Werte in qualitative Maße zu überführen oder auch weitere fachliche Zusammenhänge – wie die Topologie von Sensornetzwerken – in die Regeln der Ereignisverarbeitung einzubringen. Die Notwendigkeit dieser Daten resultiert aus der Erkenntnis, dass nicht alles Wissen der Anwendungsdomäne in den Ereignissen enthalten ist, sondern auch außerhalb, nämlich in den operativen Systemen vorgehalten wird. • Die operativen Systeme sind in Abbildung 8.4 in drei funktionalen Blöcken dargestellt, die deren Grundverantwortlichkeiten charakterisieren. In erster Linie stoßen Ereignisse entsprechende Dienste (Services) der operativen Systeme an. Darüber hinaus dienen auch die operativen Systeme als Ereignisquellen. Sie erzeugen Geschäftsereignisse, die dann in die Ereignisverarbeitungsschicht zurückfließen. Schließlich werden Ereignisse in den operativen Systemen visualisiert. Abbildungssicht – Verteilungsaspekte Die nachfolgende Abbildung 8.5 zeigt, wie sich die EDA-Komponenten der Referenzarchitektur auf ein verteiltes System von physikalischen Serverkomponenten abbilden lassen. Dazu werden die logischen Komponenten aus Abbildung 8.1 auf ein Event Processing Network (EPN) mit entsprechenden Event Processing Agents (EPAs) übertragen. Wie die Abbildung auf ein verteiltes System genau geschieht, hängt von einigen Faktoren ab, zum Beispiel von der Verteilung der Ereignisquellen, der vorhande-


207

nen Hardware und den gegebenen Mengengerüsten für erzeugte Ereignisse. Deshalb zeigt Abbildung 8.5 auch nur eine von vielen möglichen Abbildungen.12 Dabei sind einige typische Eigenschaften erkennbar.

Ereignis-Monitor 1 Zugriff

Ereignis-Monitor 2 Zugriff

Cleaning EPA

Translation In-Adapter In-Adapter

Translation

Ereignis-Monitor n Zugriff

Cleaning EPA

Cleaning EPA

Translation

In-Adapter In-Adapter

In-Adapter In-Adapter

Ereigniskanäle

Korrelationsserver

Transformationsserver

Korrelationsserver

Transformationsserver

Filterung

ContentEnrichment

Contentbased Routing

GranularitätsShift

SemantikShift

EPA

EPA

Ereigniskanäle Informationssystem Historische Daten

Strukturelle Daten

Operative Systeme

Application Server

Abb. 8.5 Verteilte Architektur für EDA

• Mehrere logische Komponenten können auf einen einzelnen Ereignisagenten verteilt werden13, wenn deren Aufgaben stark zusammenhängen. Dadurch reduziert sich die Anzahl der Ereignisagenten, ohne deren Kohärenz zu schwächen. Zum Beispiel nimmt ein einziger Ereignisagent die Aufgaben “Filterung“, “Content-Enrichment“ und “Content-Based Routing“ wahr. • Umgekehrt lässt sich auch eine einzelne logische Aufgabe auf mehrere EPAs verteilen. Dann muss der Ereignisstrom entsprechend auf diese EPAs aufgeteilt werden. Befinden sich die EPAs auf verschiedenen Servern, so führt dies zu einer Erhöhung des Durchsatzes. Insgesamt verbessert sich somit die Skalierbarkeit 12

Eine solch hochgradige Verteilung lohnt sich nur bei komplexen Anwendungen, wenn die Ereignisverarbeitung nicht performant genug ist. Bei einfachen Szenarien ist eine geringere physikalische Verteilung sinnvoller. 13 Siehe das Ereignisagenten-Muster in Abschnitt 7.2.2.

208


der CEP-Komponente. Beispielsweise ist in Abbildung 8.5 der Cleaning-Schritt auf mehrere EPAs verteilt. In unserem Beispiel sind die Ereignisquellen physikalisch verteilt und es gibt für eine Gruppe von Ereignisquellen jeweils einen eigenen dedizierten Server, den Ereignis-Monitor. Jeder Monitor übernimmt die Aufgaben eines In-Adapters, also den technischen Zugriff auf die Quellen, die Transformation in Ereignisobjekte und die Ereignisbereinigung. Exemplarisch sind diese Aufgaben im Beispiel auf drei Serverkomponenten verteilt. Darüber hinaus gibt es eine Menge von Transformations- und Korrelationsservern. Die Transformationsserver sind für die Verarbeitung von Einzelereignissen zuständig. Sie enthalten die Filterschritte zur Ereignisreduktion und die ContentEnrichment-Schritte der Ereignistransformation aus der Referenzarchitektur. Eine ganz besondere Aufgabe, speziell für verteilte Systeme, nimmt das Content-based Routing ein, das nicht in der allgemeinen Referenzarchitektur vorhanden ist. Es kommt insbesondere in verteilten EPNs zum Tragen und legt dort den Kontrollfluss fest. Jedes Ereignis wird in Abhängigkeit von seinem Kontext an den entsprechenden EPA weitergeleitet (vgl. Abschnitt 7.3.2). Das Content-based Routing ist eine vornehmlich technische Aufgabe. Darüber hinaus sind ggf. weitere Translationsschritte erforderlich, um Ereignisobjekte für den Transport über das Netzwerk zu serialisieren (vgl. Abschnitt 7.3.3, insbesondere Abbildung 7.10). Abbildung 8.5 zeigt die operativen Systeme und davon getrennt die Informationssysteme, die die strukturellen und historischen Daten vorhalten. Der Austausch von Ereignissen geschieht über Ereigniskanäle.

8.3 EDA für Sensornetzwerke In der allgemeinen Referenzarchitektur in Abschnitt 8.2 sind die Schritte des Complex Event Processing nur sehr allgemein beschrieben, weil sie stark von der jeweiligen Domäne abhängen. Als generelle Verarbeitungsschritte werden Granularitäts-Shift → Semantik-Shift unterschieden. Dieser Abschnitt diskutiert, wie sich diese Verarbeitungs-Pipeline für ein bestimmtes Anwendungsszenario konkretisieren lässt. Als Anwendungsszenario dient die Entwicklung einer EDA-Anwendung für Sensornetzwerke, wie sie z.B. für Sensornetzwerke in Verkehrsleitsystemen (siehe Fallstudie in Abschnitt 3.4) oder in RFID-Systemen (Abschnitt 2.5.2) zum Einsatz kommt. Dabei ist vorausgesetzt, dass – gemäß der Referenzarchitektur – die Einzelereignisse bereits bereinigt, gefiltert und mit fachlichen Inhalten angereichert sind. Die Abbildung 8.6 zeigt die verfeinerten Schritte einer EDA-Anwendung für Sensornetzwerke (vgl. auch [23]). • Granularitäts-Shift Der erste Schritt der Verarbeitung fasst die Sensordaten in geeigneter Weise zusammen, denn einzelne Sensorereignisse sind zu feingranular. Dabei werden die

8.3 EDA für Sensornetzwerke

räumliche Aggregation der Sensordaten

zeitliche Aggregation der Sensordaten

Granularitäts-Shift

209

Identifikation des Zustands

Ursachenanalyse

Diagnose / Aktionsplanung

Semantik-Shift

Abb. 8.6 Ereignisverarbeitungs-Pipeline für EDA-basierte Sensornetzwerke

Sensordaten einerseits räumlich zusammengefasst, um die Situation in verschiedenen örtlichen Bereichen zu einem bestimmten Zeitpunkt zu beschreiben. Andererseits betrachtet die zeitliche Aggregation die Sensordaten über einen definierten Zeitraum an einem bestimmten Ort. Gegebenenfalls werden auch beide Dimensionen der Korrelation kombiniert und Raum-Zeit-Aggregationen (time spatial correlation) betrachtet (vgl. Abschnitt 7.3.4). • Semantik-Shift Der folgende Schritt ermittelt aus den aggregierten Ereignissen einen generellen Bedeutungszusammenhang. Dies geschieht in den folgenden Teilschritten: 1. Mithilfe von Regeln, die Expertenwissen abbilden, wird zunächst der Zustand des Sensornetzwerkes identifiziert. Der Zustand charakterisiert auf einem höheren Abstraktionsniveau eine bestimmte, im Sensornetzwerk eingetretene Situation, zum Beispiel das Auftreten eines in einem Verkehrsleitsystem erkannten Verkehrsproblems. 2. In einem nachgelagerten Analyseschritt werden Gründe und Ursachen für die erkannte Situation bestimmt. Zum Beispiel kann ein erkannter Stau durch ein erhöhtes Verkehrsaufkommen in der Hauptverkehrszeit oder auch durch einen Unfall bedingt sein. Die Ursachenanalyse ist notwendig, um geeignete Reaktionen auf eine Situation einleiten zu können. 3. Auf Basis des identifizierten Zustands und der erkannten Ursachen können in einem Aktionsplanungsschritt geeignete Maßnahmen angestoßen werden, die die erkannten Ursachen beseitigen oder mildern und so das System in einen verbesserten Zustand überführen. Wie die Aktionsplanung konkret aussieht, ist stark von der Domäne abhängig. Resultiert beispielsweise ein Stau ursächlich aus einem Unfall, so kann eine entsprechende Umleitung die Situation verbessern. Insgesamt enthält der in Abbildung 8.6 gezeigte Architekturausschnitt detailliertere Vorgaben für die Umsetzung einer CEP-Komponente in Sensornetzwerken. Selbstverständlich sind für einen bestimmten Anwendungsfall noch weitere Verfeinerungen und Anpassungen notwendig, aus denen dann Ereignisverarbeitungsregeln abgeleitet werden können.14 14 In Abschnitt 5.8.2 werden einige konkrete Regeln zur Erkennung von Verkehrsproblemen vorgestellt.

210


8.4 EDA für Analysesysteme Alternativ stellt dieser Abschnitt die Übertragung der Referenzarchitektur auf ein weiteres Anwendungsszenario vor. Die Abbildung 8.7 zeigt die VerarbeitungsPipeline für ein Analyse- oder auch Business-Activity-Monitoring-System (BAM). Dabei sind wiederum die für einen Granularitäts- und Semantik-Shift erforderlichen Schritte aus der Referenzarchitektur spezifisch für dieses Anwendungsgebiet verfeinert.

Bildung fachlicher Correlation Sets

zeitliche Aggregation

Granularitäts-Shift

Bestimmung von Geschäftsindikatoren

Abgleich mit Geschäftsregeln

Diagnose / Entscheidungsfindung

Semantik-Shift

Abb. 8.7 Ereignisverarbeitungs-Pipeline für EDA-basierte Analysesysteme

• Granularitäts-Shift Auch in Analysesystemen ist es notwendig, zunächst einzelne Ereignisse zusammenzufassen. Die zusammengehörigen Ereignisse werden durch fachliche Correlation Sets bestimmt. Im Wertpapierhandel bilden zum Beispiel alle Kurse eines bestimmten Wertpapiers oder Aktien eines bestimmten Typs ein Correlation Set. Die Correlation Sets partitionieren den Ereignisstrom. In einem nachfolgenden Schritt werden die Ereignisse eines Correlation Set zeitlich aggregiert, um die Ereignisgranularität entsprechend anzuheben. So werden im Aktienhandel beispielsweise die 200-Tage-Durchschnittswerte für jedes Wertpapier berechnet. Insgesamt stellt dieser Schritt das Datenmaterial bereit, das tiefgreifende Analysen ermöglicht. • Semantik-Shift Der nachfolgende Schritt analysiert die aggregierten Ereignisse mithilfe von Expertenwissen. Dabei sind verschiedene Teilschritte durchzuführen: 1. Zunächst lassen sich aus dem Strom der aggregierten Ereignisse ausgewählte Geschäftsindikatoren ableiten. Diese Indikatoren signalisieren auf Basis komplexer Zusammenhänge eine bestimmte Situation. Im Wertpapierhandel sind beispielsweise Trends und Kursziele für einzelne Aktien oder Aktienindizes wichtige Indikatoren. 2. Dann können die aggregierten Ereignisse mit entsprechenden Geschäftsregeln abgeglichen werden. Beispielsweise können Kaufsignal-Ereignisse erzeugt werden, wenn der Kurs einer Aktie ihre 200-Tage-Linie durchbricht. Auch diese Regeln bilden in hohem Maße Expertenwissen ab und werden laufend angepasst und optimiert.

8.4 EDA für Analysesysteme

211

3. Schließlich führt der abschließende Diagnoseschritt eine Entscheidung aufgrund der analysierten Situation herbei. Im Beispielszenario des Wertpapierhandels gilt es zu entscheiden, wie mit den eintreffenden Kauf- und Verkaufssignalen umgegangen wird. Ob der Ankauf von Wertpapieren tatsächlich erfolgen soll, hängt gegebenenfalls vom aktuellen Portfolio des Wertpapierhändlers ab. Darüber hinaus muss vielleicht der Kauf über den Verkauf anderer Papiere finanziert werden – es muss also ein passendes Verkaufssignal gefunden (oder generiert) werden. Auch für diese detaillierte Architektur gilt das bereits im vorigen Abschnitt Gesagte. Die in Abbildung 8.7 dargestellten Verarbeitungsschritte müssen für jedes konkrete Anwendungsszenario noch präzisiert werden.

Kapitel 9

Vorgehen bei der Entwicklung von EDA-Anwendungen

Zusammenfassung Keine professionelle Softwareentwicklung ohne systematisches Vorgehen! Diese Aussage gilt selbstverständlich auch für die Entwicklung von ereignisgesteuerten Unternehmensanwendungen. Allerdings passen die klassischen Softwareentwicklungsprozesse nicht auf die Entwicklung von dynamischen und adaptiven EDA-Anwendungen. Nach einer kurzen Motivation von Entwicklungsprozessen in der Softwareentwicklung werden in diesem Kapitel die spezifischen Prozessschritte und Aufgaben für die Entwicklung von ereignisgesteuerten Anwendungen herausgearbeitet. Diese Schritte ergeben eingebettet in die beiden Prozessphasen Anforderungsanalyse und Test ein iteratives Vorgehensmodell für die Entwicklung von EDA-Anwendungen. Grundvoraussetzung für die erfolgreiche Entwicklung ist eine intensive Zusammenarbeit von Fach- und IT-Experten.

9.1 Einführung Softwareentwicklungsprojekte in der Wirtschaft oder im öffentlichen Bereich sind äußerst komplexe Vorhaben. Das Kapitel 7 mit Entwurfsmustern und das Kapitel 8 mit Referenzarchitekturen behandeln wichtige Konzepte für den Entwurf und die Entwicklung von professionellen EDA-Anwendungen. Muster und Referenzarchitekturen repräsentieren wertvolles Erfahrungswissen, um ein ereignisgesteuertes System richtig zu bauen oder in anderen Worten, um die Systemkomplexität zu beherrschen. Neben der Systemkomplexität liegt eine weitere erhebliche Schwierigkeit von ITProjekten in der Gestaltung der Projektdurchführung, die sogenannte Prozesskomplexität. Hierbei geht es um die Frage, wie die Projektdurchführung gestaltet werden soll, um das Projekt zum Erfolg zu führen. Zur Beherrschung der Prozesskomplexität gibt es im Software Engineering unterschiedliche Softwareentwicklungsprozesse bzw. Vorgehensmodelle. Ein Vorgehensmodell strukturiert den Entwicklungsprozess, indem es eine systematische Vorgehensweise vorgibt. Eine Verbesserung der Prozessqualität führt zu einer R. Bruns, J. Dunkel, Event-Driven Architecture, Xpert.press, DOI 10.1007/978-3-642-02439-9_9, © Springer-Verlag Berlin Heidelberg 2010

213

214

• • • •

9 Vorgehen bei der Entwicklung von EDA-Anwendungen

Steigerung der Produktqualität, Steigerung der Kosten- und Zeiteffizienz, Reduzierung der Prozessrisiken und damit insgesamt zu einer Erhöhung der Erfolgswahrscheinlichkeit.

Für die Entwicklung von Unternehmensanwendungen auf Basis einer EventDriven Architecture existieren bislang noch relativ wenig Praxiserfahrungen und folglich auch wenige konkrete Vorschläge für erprobte Vorgehensweisen. Erste Vorschläge finden sich beispielsweise in [28] in Kapitel 6, in [36] und [69]. In den nachfolgenden Abschnitten werden grundlegende Schritte und ein iteratives Vorgehensmodell für die Entwicklung von EDA-Anwendungen vorgestellt.

9.2 Prozessschritte für EDA Die besonderen Charakteristika der Ereignisverarbeitung müssen sich im Softwareentwicklungsprozess widerspiegeln: Ereignisse und Ereignisregeln stehen im Mittelpunkt der Anwendungsentwicklung. Die Realisierung einer EDA-Anwendung erfolgt anhand der nachfolgend beschriebenen Prozessschritte, die in Abbildung 9.1 dargestellt sind:1

Ereignisquellen

Ereignismodell

Muster/ Regeln


Physikal. Verteilung

Behandlung

Abb. 9.1 Prozessschritte der EDA-Entwicklung

1. Schritt: Ereignisquellen Ausgangspunkt für die Entwicklung einer ereignisgesteuerten Anwendung ist die Bestimmung der Ereignisquellen und der von der Quellen erzeugten Typen von Ereignissen. Diese Ereignistypen repräsentieren einfache Ereignisse (simple event types). Ein Ereignisobjekt als Instanz eines Typs beschreibt ein bestimmtes Vorkommnis im Kontext des betrachteten Anwendungsproblems.2 2. Schritt: Ereignismodell Ausgehend von den einfachen Ereignissen der Quellen definiert der nächste Schritt die temporalen, räumlichen, kausalen und sonstigen Beziehungen, die zwischen den Ereignistypen bestehen. Aus den Beziehungen lassen sich ggf. 1

Die Prozessschritte korrespondieren natürlich mit der in Kapitel 8 eingeführten Referenzarchitektur, denn diese legt die Ergebnisse für die Entwicklung einer EDA-Anwendung fest. 2 Falls noch kein passender In-Adapter (bzw. eine Fassade) für die Transformation eines externen Ereignisformats in die interne Repräsentation der Verarbeitungsschicht existiert, muss hierfür ein neuer Adapter implementiert werden (vgl. Abschnitt 6.2).

9.2 Prozessschritte für EDA

3.

4.

5.

6.

3

215

komplexe Ereignistypen (complex event types) ableiten. Die komplexen Ereignistypen modellieren einen Sachverhalt aus der Anwendungsdomäne auf einer höheren Abstraktionsebene, der eine spezifische Zustandskonstellation abbildet. Neben den Beziehungen werden auch mögliche Beschränkungen für Ereignistypen in Form von Constraints spezifiziert. Das Resultat ist eine Hierarchie von Ereignistypen auf unterschiedlichen Abstraktionsebenen mit ihren Beziehungen und Constraints: das in Kapitel 4 eingeführte Ereignismodell. Schritt: Ereignismuster und -regeln Ausgehend von den identifizierten Beziehungen und Abhängigkeiten zwischen den Ereignissen im Ereignismodell werden relevante Ereignismuster modelliert, nach denen die eingehenden Ereignisströme untersucht werden sollen. Es wird festgelegt, ob und wenn ja, welche Aktion aufgrund eines Musters ausgelöst werden soll. Mittels der Regelsprache (event processing language) der eingesetzten Event Processing Engine werden die Ereignismuster und -regeln mit den Aktionen formal spezifiziert (vgl. Kapitel 5). Schritt: Event Processing Network3 Die definierten Ereignisregeln werden in fachlich kohärente Gruppen strukturiert, die jeweils gemeinsam einen Event Processing Agent bzw. eine CEPKomponente ergeben. Unter Berücksichtigung der in Kapitel 7 vorgestellten Entwurfsmuster erfolgt der Entwurf der logischen Struktur des Event Processing Network. Entscheidend für den Netzwerkentwurf ist die fachliche Zerlegung des Anwendungsproblems in kleinere Teilprobleme, die stufenweise oder nebenläufig gelöst werden können. Die Struktursicht der Referenzarchitektur in Abschnitt 8.2 dient hierbei als Entwurfsvorlage und lässt sich Schritt für Schritt verfeinern. Schritt: Physikalische Verteilung Die einzelnen Komponenten eines Event Processing Network lassen sich bei Bedarf auch physikalisch verteilen. Die Anforderungen für die Verteilung müssen herausgearbeitet werden und es gilt, ein spezifisches Verteilungsmodell mit den beteiligten Hardware- und Softwarekomponenten zu entwerfen. Typische Anforderungen mit Bezug zur physikalischen Verteilung sind (dezentrale) Struktur der Ereignisquellen, Mengengerüste, Performance-Bedingungen oder Skalierbarkeit. Die Abbildungssicht der Referenzarchitektur in Abschnitt 8.2 zeigt die Möglichkeiten der Verteilung auf und dient als Vorlage. Schritt: Ereignisbehandlung Die eigentliche Behandlung der Ereignisse erfolgt in den nachgelagerten Anwendungssystemen (siehe Abbildung 3.6 bzw. Kapitel 6). Die beim Auftreten eines

Es ist durchaus auch möglich, die Reihenfolge zwischen den Prozessschritten 3 (Muster/Regeln) und 4 (EPN) zu vertauschen. In diesem Fall wird zunächst die logische Struktur der Ereignisverarbeitung mit EDA-Schichten, Ereignisagenten und fachlichen Verarbeitungsschritten entworfen und anschließend werden die dafür notwendigen Ereignismuster und -regeln spezifiziert.

216


Ereignismusters auszuführenden Aktionen müssen in den Anwendungssystemen implementiert und von der Ereignisverarbeitung angestoßen werden.4 Wie in Abbildung 9.1 durch die rückgerichteten Pfeile angedeutet ist, kann keine streng sequenzielle Abfolge der einzelnen Prozessschritte angenommen werden. So können sich beispielsweise durch die Realisierung der Ereignisbehandlung neue Typen von Ereignissen ergeben oder der Entwurf des Event Processing Network kann zu neuen oder zur Änderung von bestehenden Ereignisregeln führen. Bei der Entwicklung einer EDA-Anwendung steht die Modellierung der Fachlichkeit im Vordergrund, technische Fragestellungen sind zwar ebenfalls wichtig, aber zunächst nachrangig. Das Ereignismodell mit den Beziehungen und Abhängigkeiten, die Ereignismuster/-regeln und der Entwurf des Event Processing Network erfordern ein tief gehendes Verständnis der Fachlichkeit als unabdingbare Voraussetzung. Die Entwicklung einer leistungsfähigen EDA-Anwendung kann nur gelingen, wenn Fach- und IT-Experten intensiv und permanent zusammenarbeiten.

9.3 Vorgehensmodell für EDA Der klassische Softwareentwicklungsprozess gliedert sich typischerweise in die Phasen Analyse, Entwurf, Realisierung sowie Test mit unterstützender Qualitätssicherung. In der konventionellen Softwareentwicklung kommen diese Phasen in unterschiedlichen Modellen zum Einsatz. Dieser klassische Prozess passt nicht auf die Entwicklung von dynamischen und adaptiven ereignisgesteuerten Anwendungen. Bei der Entwicklung von EDA-Anwendungen – mit den im vorhergehenden Abschnitt 9.2 vorgeschlagenen Schritten – gehen die Phasen Analyse, Entwurf und Realisierung fließend ineinander über. Die Analyse der Fachlichkeit erfolgt durch die Modellierung der Ereignistypen und der Ereignismuster bzw. -regeln, die unmittelbar durch einen Regelinterpreter ausgeführt werden können. Eine explizite Implementierung entfällt somit durch die Modellierung.5 Lediglich bei den Adaptern und der Ereignisbehandlung in den nachgelagerten Anwendungssystemen kann eine explizite Implementierung notwendig sein. 4 Falls noch kein passender Out-Adapter in der Ereignisverarbeitungsschicht oder noch keine CEPSchnittstelle für das anzubindende operative Anwendungssystem verfügbar ist, muss ein neuer Adapter bzw. eine neue CEP-Schnittstelle implementiert werden (vgl. Abschnitt 6.2). 5 Abhängig von der Deklarativität der eingesetzten Regelsprache kann der Regelinterpreter das durch die Regeln modellierte Fachwissen direkt ausführen. An den Beispielregeln von Esper in Kapitel 5 wird allerdings deutlich, dass manche Regelsprachen mehr oder weniger ausgeprägte prozedurale Konstrukte beinhalten und somit doch eine explizite Implementierung des Fachwissens erfordern.

9.3 Vorgehensmodell für EDA

217

Für die Entwicklung einer EDA-Anwendung verbleiben somit noch drei Prozessphasen, die Abbildung 9.2 zeigt: (1) Anforderungsanalyse, (2) EDA-Entwicklung und (3) Test.

Ereignisquellen

Ereignismodell

Muster/ Regeln


Physikal. Verteilung

Behandlung

Schritte

Anforderungsanalyse

EDAEntwicklung

Test

Phasen

Abb. 9.2 Prozessphasen der EDA-Entwicklung

1. Phase: Anforderungsanalyse Analog zur konventionellen Softwareentwicklung steht auch bei einer EDA-Entwicklung am Anfang des Prozesses die systematische Beschreibung der Ziele und Anforderungen (requirements), die mit dem System realisiert werden sollen. • Funktionale Anforderungen Aus fachlicher Sicht ist es bei einer ereignisgesteuerten Anwendung besonders wichtig, die Situationen (bzw. Konstellationen von Geschäftsereignissen) zu identifizieren, die in den Ereignisströmen erkannt werden sollen. Weiterhin sollte herausgearbeitet werden, welche Informationen geschäftsrelevant sind und aus den Ereignisströmen extrahiert werden sollen. • Nichtfunktionale Anforderungen Die wesentlichen nichtfunktionalen Anforderungen bei einem EDA-System beziehen sich auf die Bestimmung (a) des erwarteten Durchsatzes an Ereignissen, d.h. wie viele Ereignisse pro Zeiteinheit müssen verarbeitet werden, und (b) der zulässigen Latenzzeit, also des zeitlichen Antwortverhaltens bei der Auswertung der Ereignisse. Darüber hinaus ist es natürlich auch sehr wichtig, ein solides Grundverständnis der Anwendungsdomäne, der wesentlichen Geschäftsprozesse und der tangierten Unternehmensanwendungen zu erarbeiten, die den Kontext für die EDA-Anwendung bilden. 2. Phase: EDA-Entwicklung Die eigentliche Entwicklung der EDA-Anwendung erfolgt durch die Bearbeitung der in Abschnitt 9.2 vorgestellten Prozessschritte.

218


3. Phase: Test Die Erreichung der angestrebten Ziele und Anforderungen der EDA-Anwendung muss durch systematisches Testen überprüft werden. Aufgrund der flexiblen Änderbarkeit und der damit einhergehenden hohen Änderungsrate von EDA-Anwendungen kommen hierfür nur automatisierte Testverfahren in Frage. Die dezentrale Struktur einer EDA-Anwendung aufgrund des zugrunde liegenden Event Processing Network erfordert einerseits das separate Testen der Regelbasis jedes einzelnen Event Processing Agent und andererseits den Gesamttest des Verhaltens des EPN insgesamt. Zur Überprüfung der nichtfunktionalen Anforderungen sind Last- und Performance-Tests notwendig. Aufgrund der Vielzahl an Ereigniskonstellationen können neben Testfällen auch Simulationsmodelle der Ereignisströme einen wichtigen Beitrag leisten. Eine weitere Möglichkeit ist das Aufzeichnen und erneute Abspielen (capture-and-replay) von historischen Datenströmen. Über die besonderen Anforderungen an das Testen von EDA-Anwendungen existieren bislang kaum Erfahrungsberichte. Iteratives Vorgehensmodell Durch die hohe Komplexität von Softwareentwicklungsprojekten hat es sich als vorteilhaft herausgestellt, Softwaresysteme in aufeinander aufbauenden inkrementellen Stufen zu erstellen. Pro Stufe werden die Projektphasen aus Abbildung 9.2 iteriert durchgeführt und am Ende einer solchen Iteration steht jeweils eine lauffähige Systemversion. Die Realisierung der nächsten Iteration berücksichtigt die Erfahrungen mit der laufenden Version, dies führt zu einem besseren Verständnis der Fachlichkeit und zur Minimierung der Projektrisiken. Diese Art von Vorgehensmodellen wird als iterative oder inkrementelle Vorgehensmodelle bezeichnet. Das bekannteste iterative Vorgehensmodell ist der Unified Process [56]. Bei der Entwicklung einer EDA-Anwendung hängt der Projekterfolg entscheidend von der Qualität der Modellierung der Fachlichkeit ab. Bei unternehmensrelevanten Problemstellungen ist in der Regel die Fachlichkeit zu komplex für eine fehlerfreie und problemadäquate Gesamtmodellierung. Folglich bietet sich auch bei der Entwicklung von ereignisgesteuerten Anwendungen ein iteratives Vorgehensmodell an, wie es in Abbildung 9.3 skizziert ist.

Anforderungen

EDAEntwicklung

Test

Anforderungen

EDAEntwicklung

Qualitätssicherung

Qualitätssicherung

Iteration 1

Iteration 2

Anforderungen

Test

Abb. 9.3 Iteratives Vorgehensmodell für EDA-Anwendungen

EDAEntwicklung

Qualitätssicherung

...

Iteration n

9.3 Vorgehensmodell für EDA

219

Wie in der konventionellen Softwareentwicklung muss auch bei einer ereignisgesteuerten Entwicklung eine Qualitätssicherung die Prozessphasen begleiten. Das Vorgehensmodell in Abbildung 9.3 umfasst nur die Aufgaben, die direkt die Entwicklung der EDA-Anwendung betreffen. Nicht betrachtet in diesem Vorgehensmodell sind vor- und nachgelagerte Prozessphasen: zum Beispiel eine Vorstudie zur prinzipiellen Eignung von EDA für das Anwendungsgebiet, der Aufbau der technischen EDA-Infrastruktur6 oder die Integration der EDA-Lösung in das produktive Systemumfeld.

6

Auf die Phasen Vorstudie und EDA-Infrastruktur geht Abschnitt 10.3 ein.

Teil IV

Stand, Zusammenfassung und Ausblick

Teil IV – Stand, Zusammenfassung und Ausblick ist der letzte Teil dieses Buches. Nachdem die ersten drei Teile die inhaltlichen Konzepte der Ereignisorientierung behandelt haben, widmet sich dieser Teil dem aktuellen Stand und der weiteren Entwicklung der Ereignisorientierung. Kapitel 10 – Stand, Zusammenfassung und Ausblick beleuchtet den erreichten Stand der Entwicklung von Event-Driven Architecture, fasst die wichtigsten Inhalte kurz zusammen und gibt einen Ausblick auf den möglichen Weg von EDA in die Praxis.

Kapitel 10

Stand, Zusammenfassung und Ausblick

Zusammenfassung Das letzte Kapitel des Buches ist erreicht – geschafft, puuh! Nachdem die grundlegenden Ideen, die wesentlichen Konzepte, die technische Umsetzung und das fachliche Anwendungspotenzial von Event-Driven Architecture im Allgemeinen und Complex Event Processing im Besonderen in den vorangegangenen Kapiteln ausführlich herausgearbeitet wurden, möchten wir zum Abschluss des Buches den erreichten Stand der Entwicklung beleuchten und versuchen, einen Ausblick auf die mögliche zukünftige Einführung einer EDA in Unternehmen zu geben. Eingerahmt zwischen Entwicklungsstand und Ausblick enthält dieses Kapitel noch eine wirklich kurze Zusammenfassung der wichtigsten Inhalte des Buches.

10.1 Aktueller Entwicklungsstand Event-Driven Architecture in Verbindung mit Complex Event Processing ist ein relativ junges Fachgebiet, dessen Entwicklung längst noch nicht abgeschlossen ist. Die wichtigsten Konzepte sind so weit vorhanden, eine Fachterminologie bildet sich heraus und vielversprechende Werkzeuge stehen zur Verfügung, so dass schon heute die Ereignisverarbeitung konventionelle IT-Systeme ablösen oder zumindest ergänzen kann. Jedoch behindern noch einige wesentliche Faktoren die praktische Anwendung in wirtschaftlichen, industriellen, öffentlichen oder technischen Anwendungsdomänen: • Fehlende Standards Das größte Hindernis für die Verbreitung und den wirtschaftlichen Einsatz der Ereignisverarbeitung ist das Fehlen von allgemein akzeptierten Standards. Insbesondere für die folgenden, wichtigen EDA-Komponenten existieren noch keine technischen Standards: – Event Processing Languages (EPL) zur Beschreibung von Ereignistypen, Ereignismustern und -regeln, R. Bruns, J. Dunkel, Event-Driven Architecture, Xpert.press, DOI 10.1007/978-3-642-02439-9_10, © Springer-Verlag Berlin Heidelberg 2010

223

224

10 Stand, Zusammenfassung und Ausblick

– Definition von Ereignismodellen oder vordefinierte Referenzereignismodelle für bestimmte Anwendungsgebiete, – Schnittstellen (application programming interface, API) zur Interaktion der Event Processing Engines mit deren Umwelt. Sowohl die am Markt verfügbaren kommerziellen CEP-Plattformen als auch die bereitstehenden Open-Source-Event-Processing-Engines verwenden proprietäre EPLs und APIs, die einen späteren Wechsel der Plattform zu einem Vorhaben mit großem Kosten- und Zeitaufwand werden lassen und somit zu einer starken Abhängigkeit zum Plattformhersteller führen. Zurzeit sind jedoch erste Standardisierungsbestrebungen auf den Weg gebracht, die zwar nicht unmittelbar auf EDA ausgerichtet sind, aber zumindest eine Standardisierung für Regelsprachen vorantreiben. Zu nennen sind hier unter anderem die Standardisierungsarbeiten für die Java Rule Engine API [58], das Regelaustauschformat Rule Interchange Format (RIF) [113] und die Regelsprache RuleML [94]. Erste einzelne Arbeiten adressieren Standardisierungsbestrebungen konkret für CEP bzw. ESP [57]. • Keine etablierte Entwicklungsmethodik Momentan existiert noch keine ausgereifte Methodik für die Entwicklung von ereignisgesteuerten Anwendungssystemen. Insbesondere Richtlinien, Entwurfsmuster, Best-Practice-Beispiele, wiederverwendbare Komponenten oder Vorgehensmodelle für EDA existieren zurzeit noch gar nicht oder lediglich in rudimentärer Form. In Teil III dieses Buches greifen wir dieses Defizit auf und stellen erste Vorschläge für Entwurfsmuster, Referenzarchitekturen und eine systematische Vorgehensweise vor. Diese Vorschläge entstammen einerseits aus der Literatur, andererseits aus unseren eigenen Erfahrungen, die wir bei der Entwicklung von unterschiedlichen EDA-Anwendungen gewonnen haben. Sie müssen jedoch noch durch möglichst viele weitere Anwendungsprojekte verifiziert, verfeinert und weiterentwickelt werden. • Wenig Erfahrungswissen Insgesamt betrachtet mangelt es noch an konkreten Erfahrungen mit ernstzunehmenden EDA-Anwendungen in industriellem Maßstab, die sich im produktiven Einsatz bewähren. Die Entwicklung komplexer CEP-Netzwerke mit vielen Ereignisregeln ist nicht nur für die meisten Wirtschaftsunternehmen absolutes Neuland, sondern auch für die Mehrzahl der IT-Dienstleister [28]. Hier muss belastbares Erfahrungswissen erst noch aufgebaut werden. Allerdings wächst die Anzahl der berichteten betrieblichen Einsatzgebiete immer mehr an und damit auch der Erfahrungsschatz. • Werkzeugunterstützung In den letzten Jahren hat eine ganze Reihe von Herstellern Werkzeuge zur Entwicklung von EDA- bzw. CEP-Anwendungen auf den Markt gebracht. Waren es am Anfang vor allem Firmen aus dem universitären Umfeld, so sind nun verstärkt auch namhafte IT-Unternehmen mit eigenen CEP-Lösungen in den Markt

10.2 Zusammenfassung

225

eingestiegen. Darüber hinaus steht durch den Anbieter EsperTech [34] auch eine ernstzunehmende Open-Source-CEP-Plattform zur Verfügung. Allerdings ist die Werkzeugunterstützung noch nicht annähernd so weit gediehen, wie bei konventionellen Softwarearchitekturen. Aufgrund der fehlenden Standards sind die verfügbaren Plattformen in der Regel gut in die eigene Produktsuite des Herstellers integriert, dies gilt aber häufig nicht für die Integration mit Fremdprodukten. Generell lässt sich sagen, dass gleich mehrere der verfügbaren Produkte für den Unternehmenseinsatz in anspruchsvollen Einsatzgebieten geeignet sind. Wie bei innovativen Technologien üblich, reichen überzeugende Ideen und stimmige Konzepte allein nicht für den erfolgreichen Einsatz zur Lösung von wirtschaftlichen Anwendungsproblemen. Für den praktischen Einsatz im Unternehmen muss eine Technologie einen gewissen Reifegrad erreicht haben, es müssen Erfahrungen über Einsatzbarkeit und Grenzen der Technologie vorliegen und eine etablierte Entwicklungsmethodik, unterstützt durch professionelle, integrierte Werkzeuge, muss die Softwareentwicklung begleiten. Bei EDA sind noch einige der obigen Punkte offen, aber insgesamt ist die Entwicklung des Fachgebiets so weit fortgeschritten, dass Unternehmen erste Anwendungen mit Ereignisverarbeitung angehen können.

10.2 Zusammenfassung Bevor das Ende des Buches erreicht ist, soll in diesem Abschnitt das Wichtigste noch einmal wirklich kurz zusammengefasst werden. Event-Driven Architecture (EDA) als Architekturstil und Complex Event Processing (CEP) als Softwaretechnologie zur dynamischen Ereignisverarbeitung stellen Ereignisse in das Zentrum der Softwareentwicklung und ermöglichen so ausdrucksmächtige Unternehmensanwendungen, die ein realitätsnahes Abbild der Wirklichkeit liefern. EDA liegt ein ereignisbasiertes Kommunikationsmuster zugrunde. Es nutzt Ereignisnachrichten als Kommunikationsmedium, Publish/Subscribe-Interaktion im Push-Modus und asynchrone Interaktion zwischen Komponenten. Dieses Kommunikationsmuster führt zu hochgradig entkoppelten Anwendungssystemen. CEP fügt hierzu die Verarbeitung von komplexen Ereignissen durch ein Netzwerk von interagierenden, leichtgewichtigen CEP-Komponenten sowie die Modellierung der Fachlogik durch deklarative Ereignismuster und -regeln hinzu. CEP ist ausgelegt auf die Verarbeitung von extrem großen Mengen von Ereignissen aus unterschiedlichen Quellen. Ereignisse und ihre Beziehungen in Form von Ereignismustern werden in Echtzeit überwacht und bewertet, um hieraus zeitnah operative Entscheidungen abzuleiten. Complex Event Processing ist integraler Bestandteil und somit Kernelement einer “vollständig ereignisgesteuerten“ Event-Driven Architecture!

226


EDA mit CEP als Softwarearchitektur bildet die Grundlage für die Entwicklung von offenen und dynamischen Unternehmensanwendungen, die sich durch die in der folgenden Tabelle 10.1 zusammengefassten Vorteile auszeichnen (siehe insbesondere die Abschnitte 2.3.3 und 3.3): Tabelle 10.1 Zusammenstellung der fachlichen und technischen Vorteile einer EDA Vorteile aus Geschäftssicht

Vorteile aus Technologiesicht

Fachliche Agilität durch Anpassungsfähigkeit der Geschäftsprozesse

Technische Agilität durch Anpassungsfähigkeit der Systembestandteile

Aktualität unternehmerischer Entscheidungen Robustheit bei Änderungen oder Fehlverdurch Echtzeitfähigkeit halten Schnelle Reaktionsfähigkeit durch Gegen- Wartbarkeit und Erweiterbarkeit der Unterwartsperspektive und geringe Latenzzeit nehmensanwendungen Effizienz in der Abarbeitung der fachlichen Skalierbarkeit der Ereignisverarbeitung durch Geschäftsprozesse Verteilung Transparenz unternehmerischer Entscheidungen durch Situationsverständnis

Event-Driven Architecture ist die Grundlage für leistungsfähige Unternehmensanwendungen, die einerseits zu einer Optimierung bestehender Geschäftsprozesse führen und andererseits aber auch ganz neue Geschäftsabläufe ermöglichen, die bislang mit konventionellen Ansätzen so nicht realisierbar waren. Die Ereignisorientierung als Architekturstil bildet einen wichtigen Schritt auf dem langen Weg, die bestehende konzeptionelle Lücke zwischen den Geschäftsinteressen eines Unternehmens und den IT-Systemen, die die Unternehmensanwendungen bereitstellen, zu verkleinern. Deshalb auch der Titel dieses Buches: Event-Driven Architecture – Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse –

10.3 Ausblick: Einführung von EDA in die Praxis Die Geschäftsprozesse von Unternehmen sind auch heute schon ereignisgesteuert, da sie permanent auf eine Vielzahl von inneren und äußeren Ereignissen reagieren. Das Verhalten der Wettbewerber wird beobachtet und bei Bedarf auf sich abzeichnende Entwicklungen reagiert, bei einer verspäteten Warenlieferung werden die betroffenen Kunden rechtzeitig vorab informiert oder bei sich anbahnenden Wetterproblemen die Mitarbeiter in dem betroffenen Gebiet gewarnt.

10.3 Ausblick: Einführung von EDA in die Praxis

227

Ereignissteuerung als gelebte Praxis Ereignissteuerung in Unternehmen ist heute selbstverständliche, gelebte alltägliche Praxis und ein natürlicher Bestandteil der Arbeitsweise in Unternehmen. Allerdings erfolgt die Ereignissteuerung in der Regel durch die Interpretation und Reaktion von Menschen auf die Ereignisse – Event-Driven Architecture kann hierbei einen deutlichen Effizienz- und Qualitätsgewinn bewirken. Durch EDA wird die natürliche Arbeitsweise von Unternehmen auf die Ebene der IT-Architektur der Unternehmensanwendungen abgebildet. Weiterhin sind bereits viele der notwendigen technischen Kernkomponenten für den Aufbau einer EDA in den meisten Unternehmen vorhanden: nachrichtenorientierte Middleware-Produkte wie eine Message-oriented Middleware oder ein Enterprise Service Bus, Systemkomponenten, die kontinuierlich Ereignisse erzeugen und somit die Ereignisquellen bilden, sowie Datenbanken mit Kontextwissen. In vielen Unternehmen befinden sich sogar bereits regelbasierte Systeme im Einsatz. Durch die Einführung von Service-orientierten Architekturen (SOA) werden die Unternehmensanwendungen entkoppelt und modular, was die Umsetzung einer EDA wesentlich erleichtert. Die in den meisten Unternehmen noch fehlenden CEP-Plattformen stehen inzwischen ebenfalls in ausreichender Anzahl und Qualität zur Verfügung, so dass Unternehmen mit der Einführung einer EDA beginnen können. Vorgehen zur Einführung einer EDA im Unternehmen Aufgrund der in Abschnitt 10.1 aufgezeigten Hindernisse im Hinblick auf Standardisierung, Methodik und Erfahrungswissen im Bereich EDA bietet sich eine graduelle Vorgehensweise zur Einführung von EDA in einem Unternehmen an. Ein zweckmäßiges Vorgehen zur Einführung einer Event-Driven Architecture skizziert Abbildung 10.1 (angelehnt an das Vorgehen zur Einführung der ServiceOrientierung in [32], Seite 7). Pilotierung

Anwendungsprojekte

Etablierung

Aufbau Infrastruktur Projekte Pilot Vorstudie EDA-Einführung

Abb. 10.1 Vorgehen für die Einführung der Ereignisorientierung

Der erste Schritt in einem EDA-Vorhaben ist eine Vorstudie. Die Vorstudie dient zur Identifikation der potenziellen Einsatzgebiete von EDA im Unternehmen und

228


deren Priorisierung anhand der Kriterien (a) fachlicher Nutzen, (b) Machbarkeit und (c) Aufwand. Aus den identifizierten Einsatzgebieten wird das Anwendungsgebiet für das anschließende Pilotprojekt ausgewählt. Gegebenenfalls können in der Vorstudie auch bereits erste technische und organisatorische Vorbereitungen auf den Weg gebracht werden, beispielsweise die wichtige Auswahl der Softwareplattform mit der einzusetzenden Event Processing Engine. In einem Pilotprojekt wird EDA erstmals im Unternehmen in einem realen Anwendungskontext angewendet. Wichtig für die Akzeptanz von EDA ist hierbei, dass es sich um ein signifikantes Einsatzgebiet handelt, damit der fachliche Nutzen von EDA eindeutig nachgewiesen werden kann.1 Bei der Auswahl des Anwendungsgebietes ist zu beachten, dass der erwartete Aufwand für den Piloten nicht zu groß ist, damit die Erkenntnisse aus dem Pilotprojekt in absehbarer Zeit vorliegen. Am erfolgreichen Ende des Pilotprojekts steht eine produktive EDA-Anwendung mit einem sichtbaren fachlichen Mehrwert! Weiterhin belegt der Pilot die Machbarkeit von EDA-Vorhaben und bildet den Ausgangspunkt für den Aufbau der technischen und organisatorischen Infrastruktur für den weiteren Einsatz von EDA im Unternehmen. Vorausgesetzt der Pilot ist erfolgreich, folgen anschließend erste Anwendungsprojekte durch Ausweitung des Anwendungsgebietes des Piloten oder durch neue Einsatzgebiete. Parallel zu den Anwendungsprojekten erfolgt die Integration von EDA-Vorhaben in den Standard-Softwareentwicklungsprozess des Unternehmens. Hierzu muss die Entwicklungsmethodik des Unternehmens unter Berücksichtigung der Spezifika von EDA weiterentwickelt werden. Der Übergang der Ereignisorientierung in den Kanon der etablierten Softwareentwicklungskonzepte erfolgt fließend. Business Activity Monitoring als Pilotanwendung In [18] wird Business Activity Monitoring (BAM) als aussichtsreichstes Anwendungsgebiet identifiziert, um der Ereignisorientierung zum Durchbruch zu verhelfen. Eine BAM-Anwendung bietet sich folglich auch als Anwendungsgebiet für das Pilotprojekt an. Hierbei kann es sich um eine neue oder aber auch um die signifikante Verbesserung einer bestehenden BAM-Anwendung handeln, z.B. durch das Erkennen von sich anbahnenden oder eingetretenen Problemsituationen mit aktiver Information der Benutzer. Der fachliche Stellenwert von BAM hat in den vergangenen Jahren stark zugenommen, da Benutzer hierbei geschäftsrelevante Informationen in Form von Unternehmensindikatoren in annähernd Echtzeit erhalten. BAM-Projekte lassen sich auch hinsichtlich des Umfangs sehr gut einschränken, so dass relativ schnell aussagekräftige Ergebnisse erreicht werden können. Die besondere Eignung von EDA für BAM-Probleme wird in Abschnitt 2.5.1 diskutiert.

1

Das Pilotprojekt darf nicht mit der Entwicklung eines Prototyps verwechselt werden. Im Gegensatz zu einem Prototyp verfolgt ein Pilotprojekt einen eindeutigen fachlichen Nutzen, und zwar mit überschaubarem Aufwand (angestrebt wird ein sogenannter “Quick Win“).

10.3 Ausblick: Einführung von EDA in die Praxis

229

Ereignisorientierung als Chance Die Einführung von Event-Driven Architecture in einem Unternehmen geht weit über die rein informationstechnischen Aspekte einer neuen Technologie hinaus. Die Umsetzung einer Event-Driven Architecture erfordert ein Umdenken in der Softwareentwicklung: 1. Der Gegenstand der Modellierung ist ein anderer, nämlich Ereignisse und Ereignisregeln. 2. Die Entwicklungsphasen fließen ineinander, die Modellierung ersetzt Analyse, Entwurf und Realisierung. 3. Eine neue Art der Zusammenarbeit zwischen Fachbereich und IT-Abteilung ist notwendig. Die Ereignisverarbeitung in Form von Event-Driven Architecture eröffnet Unternehmen aussichtsreiche Chancen auf zwei unterschiedlichen Ebenen, nämlich sowohl 1. betriebliche Geschäftsprozesse und technische Anwendungssysteme besser aufeinander abzustimmen als auch 2. Fachbereiche und IT-Abteilungen näher zusammenzuführen.

Das übergeordnete Ziel für die Einführung einer Event-Driven Architecture als Architekturstil für Unternehmensanwendungen besteht darin, die Agilität der Geschäftsprozesse, die Reaktionsfähigkeit und die Echtzeitfähigkeit des Unternehmens zu erhöhen. Weil die potenziellen Einsatzgebiete von EDA im Unternehmenskontext immer mehr an Bedeutung gewinnen und darüber hinaus eine Reihe führender Softwarehersteller das Thema aufgegriffen haben und professionelle EDA-Plattformen anbieten, ist zu erwarten, dass sich EDA und CEP auf Dauer als integraler Bestandteil von zukunftssicheren Unternehmensarchitekturen etablieren werden. Sobald eine sehr große Masse untereinander in Beziehung stehender Ereignisse (in Echtzeit) verarbeitet werden muss, bietet Event-Driven Architecture den Architekturansatz mit den zurzeit aussichtsreichsten Zukunftsperspektiven. Dieses Buch soll einen Beitrag dazu leisten, den Bekanntheitsgrad von Ereignisorientierung als Architekturstil zu steigern, das Verständnis und die Entwicklung von Event-Driven Architecture und Complex Event Processing zu fördern und damit insgesamt die Voraussetzungen zu verbessern, dass die Ereignisorientierung zur Lösung von signifikanten Problemstellungen in möglichst vielen Anwendungsgebieten in Wirtschaftsunternehmen und öffentlichen Institutionen zur Anwendung kommt.

Literaturverzeichnis

1. Adi, A., Etzion, O.: Amit – the situation manager. The VLDB Journal, 13(2), pp. 177–203 (2004) 2. Aleri: Aleri CEP. (2009) http://www.aleri.com/products/aleri-cep. Abgerufen 8. Dezember 2009 3. Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., Angel, S.: A Pattern Language: Towns, Buildings, Construction. Oxford University Press, New York (1978) 4. Allen, J.: Maintaining Knowledge about Temporal Intervals. Communications of the ACM, 26(11), pp. 832–843 (1983) 5. Alonso, G., Casati, F. Kuno, H., Machiraju, V.: Web Services: Concepts, Architectures and Applications. Springer-Verlag, Berlin, Heidelberg (2003) 6. Alur, D., Crupi, J., Malks, D.: Core J2EE Patterns – Best Practices and Design Strategies. Prentice Hall, Upper Saddle River, NJ (2001) 7. Arasu, A., Babu, S., Widom, J.: The CQL continuous query language: semantic foundations and query execution. The VLDB Journal, 15(2), pp. 121–142 (2006) 8. Babcock, B., Babu, S., Datar, M., Motwani, R., Widom, J.: Models and issues in data stream systems. In: Proceedings of the ACM Symposium on Principles of Database Systems, pp. 1–15 (2002) 9. Babu, S., Widom, J.: Continuous Queries over Data Streams. SIGMOD Record, 30(3), pp. 109–120 (2002) 10. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice. Addison-Wesley (2003) 11. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American, 284(5), pp. 34–43 (2001) 12. Berstel, B.: Extending the RETE Algorithm for Event Management. In: Ninth International Symposium on Temporal Representation and Reasoning (TIME’02), pp. 49–51 (2002) 13. Breier, B.: Event Handlers in Business Process Choreographer – Functionality and scenarios. (2006) http://www.ibm.com/developerworks/library/ws-eventhandler/. Abgerufen 8. Dezember 2009 14. Bui, H.-L.: Survey and Comparison of Event Query Languages Using Practical Examples. Diplomarbeit, LMU München (2009) http://www.pms.ifi.lmu.de/publikationen/diplomarbeiten/HaiLam.Bui/DA_HaiLam.Bui.pdf. Abgerufen 8. Dezember 2009 15. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-Orientierte Software-Architektur. Addison-Wesley (1998) 16. Chandy, K.M., Lurie, J., Alexander, R.: Event-Driven Architecture: Event Web Building Block. (2005) http://www.developer.com/design/article.php/10925_3490671. Abgerufen 8. Dezember 2009

R. Bruns, J. Dunkel, Event-Driven Architecture, Xpert.press, DOI 10.1007/978-3-642-02439-9, © Springer-Verlag Berlin Heidelberg 2010

231

232


17. Chandy, K.M., Schulte, W.R.: What is Event Driven Architecture (EDA) and Why Does it Matter? (2007) http://complexevents.com/wp-content/uploads/2007/07/EDA%20article%20long%20Chandy%20and%20Schulte%2015%20July%202007%20final.pdf. Abgerufen 9. Dezember 2009 18. Chandy, K.M., Schulte, W.R.: The Role of Event Processing in Modern Business. (2007) http://www.ebizq.net/topics/cep/features/8303.html. Abgerufen 9. Dezember 2009 19. Conrad, S., Hasselbring, W., Koschel, A., Tritsch, R.: Enterprise Application Integration: Grundlagen – Konzepte – Entwurfsmuster – Praxisbeispiele. Spektrum Akademischer Verlag (2005) 20. Coral8, Inc.: Coral8 Technology Overview. Version 4.8 (2007) www.coral8.com/system/files/assets/pdf/Coral8TechnologyOverview.pdf. Abgerufen 8. Dezember 2009 21. Coral8, Inc.: Coral8: Powering Continuous Intelligence for ‘Live‘ Analytical Applications. White Paper (2008) http://www.coral8.com. Abgerufen 8. Dezember 2009 22. Coral8, Inc.: Complex Event Processing: Ten Design Patterns. White Paper (2008) http://www.coral8.com/system/files/assets/pdf/Coral8DesignPatterns.pdf. Abgerufen 8. Dezember 2009 23. Dunkel, J.: On Complex Event Processing for Sensor Networks. In: Proceedings of the IEEE 9th International Symposium on Autonomous Decentralized Systems (ISADS), Athens (Greece), pp. 249–255, IEEE Computer Society (2009) 24. Dunkel, J., Fernández, A., Ortiz, R., Ossowski, S.: Injecting Semantics into Event-Driven Architectures. In: Proceedings of the 11th International Conference on Enterprise Information Systems (ICEIS), Milano (Italy), pp. 70–75 (2009) 25. Dunkel, J., Bruns, R.: Reference Architecture for Event-Driven RFID Applications. In: Proceedings of the Second International Workshop on RFID Technology (IWRT 2008), Barcelona (Spain), pp. 129–135 (2008) 26. Dunkel, J., Fernández, A., Ortiz, R., Ossowski, S.: Event-Driven Architecture for Decision Support in Traffic Management Systems. In: Proceedings of the IEEE 11th International Conference on Intelligent Transportation Systems, Beijing (China), pp. 7–13, IEEE Computer Society (2008) 27. Dunkel, J., Bruns, R., Pawlowski, O.: Complex Event Processing in Sensor-based Decision Support Systems. Erscheint in: Nag, B. (ed.) Intelligent Systems in Operations: Models, Methods, and Applications, IGI Global (2010) 28. Dunkel, J., Eberhart, A., Fischer, S., Kleiner, C., Koschel, A.: Systemarchitekturen für verteilte Anwendungen. Carl Hanser Verlag, München (2008) 29. Dunkel, J., Holitschke, A.: Softwarearchitektur für die Praxis. Springer-Verlag, Berlin, Heidelberg (2003) 30. Eckert, M.: Complex Event Processing with XChangeEQ: Language Design, Formal Semantics, and Incremental Evaluation for Querying Events. Dissertation, Fakultät für Mathematik, Informatik und Statistik der LMU München (2008) 31. Eckert, M., Bry, F.: Complex Event Processing. Informatik Spektrum, 32(2), pp. 163–167 (2009) 32. Engels, G., Hess, A., Humm, B., Juwig, O., Lohmann, M., Richter, J.-P., Voß, M., Willkomm, J.: Quasar Enterprise. dpunkt.verlag, Heidelberg (2008) 33. Ermert, L.: Comparing Jess and Esper for Event Stream Processing. Bachelorarbeit, Fakultät IV – Abteilung Informatik, Fachhochschule Hannover (2009) 34. ESPERTECH: Event Stream Intelligence: Esper & NEsper. (2009) http://esper.codehaus.org. Abgerufen 8. Dezember 2009 35. ESPERTECH: Esper Reference Documentation, Version 3.1.0. (2009) http://esper.codehaus.org/esper-3.1.0/doc_20091026/reference/en/pdf/esper_reference.pdf. Abgerufen 8. Dezember 2009 36. ESPERTECH: Tutorial. (2009) http://esper.codehaus.org/tutorials/tutorial/tutorial.html. Abgerufen 8. Dezember 2009


233

37. Estrin, D., Girod. L., Pottie, G., Srivastava, M.: Instrumenting the World with Wireless Sensor Networks. In: International Conference on Acoustics, Speech, and Signal Processing (ICASSP 2001), Salt Lake City (USA), pp. 2033–2036, IEEE Computer Society (2001) 38. Etzion, O.: Towards an Event-Driven Architecture: An Infrastructure for Event Processing Position Paper. In: Adi, A. et al. (eds.): Proceedings of the First International Conference Rules and Rule Markup Languages for the Semantic Web, RuleML 2005, LNCS 3791, pp. 1–7, Springer-Verlag, Berlin, Heidelberg (2005) 39. Fowler, M.: Analysis Patterns: Reusable Object Models. Addison-Wesley (2000) 40. Fowler, M.: Patterns of Enterprise Application Architecture. Addison-Wesley (2002) 41. Fowler, M., Woolf, B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley (2003) 42. Friedman-Hill, E.: Jess in Action: Java Rule-Based Systems. Manning (2003) 43. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns. Addison-Wesley (1995) 44. Gartner Group: Introducing the Zero-Latency Enterprise. Research Note COM-04-37770, June (1998) 45. Greiner, T., Düster, W., Pouatcha, F., von Ammon, R., Brandl, H.-M., Guschakowski. D.: Business activity monitoring of norisbank taking the example of the application easyCredit and the future adoption of Complex Event Processing (CEP). In: Proceedings of the International Symposium on Principles and Practice of Programming in Java, Mannheim (Deutschland), pp. 237-242, ACM (2006) 46. Gualteri, M., Rymer, J.R.: Complex Event Processing (CEP) Platforms, Q3 2009, The Forrester Wave. (2009) http://www.forrester.com/rb/Research/wave%26trade%3B_complex_event_processing_cep_platformsfi%2C_q3/q/id/48084/t/2. Abgerufen 9. Dezember 2009. 47. Gyllstrom, D., Wu, E., Chae, H.-J., Diao, Y., Stahlberg, P., Anderson, G.: SASE: Complex Event Processing over Streams. In: Proceedings of the Third Biennal Conference on Innovative Systems Research (CIDR), pp. 407–411 (2007) http://www.cidrdb.org/cidr2007/. Abgerufen 10. Dezember 2009 48. Hellmann, B.: Model-Driven Software Development für Event-Driven Architectures. Masterarbeit, Fakultät IV – Abteilung Informatik, Fachhochschule Hannover (2009) 49. Hohpe, G.: Developing Software in a Service-Oriented World. In: Vossen, G. et al. (eds.) Datenbanksysteme in Business, Technologie und Web (BTW), Karlsruhe (Deutschland), pp. 476–484, LNI 65 GI (2005) 50. Hohpe, G.: Architect’s dream or developer’s nightmare? Folien des eingeladenen Vortrags auf der International Conference on Distributed Event-Based Systems, DEBS 2007, Toronto (Canada) (2007) 51. Hohpe, G., Woolf, B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley (2003) 52. IBM: InfoShere Streams. (2009) http://www-01.ibm.com/software/data/infosphere/streams/. Abgerufen 8. Dezember 2009 53. ILOG: JRules. (2009) http://www.ilog.com/products/jrules/. Abgerufen 28. August 2009 54. JBoss: Drools – Business Logic integration Platform. (2009) http://jboss.org/drools/. Abgerufen 9. Dezember 2009 55. JBoss: Drools Fusion – Community Documentation. (2009) http://www.jboss.org/drools/drools-fusion.html/. Abgerufen 9. Dezember 2009 56. Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Software Development Process. AddisonWesley (1999) 57. Jain, N., Mishra, S., Srinivasan, A., Gehrke, J., Widom, J., Balakrishnan, H., Cetintemel, U., Cherniack, M., Tibbetts, R., Zdonik, S.: Towards a Streaming SQL Standard. In: Proceedings of the International Conference on Very Large Database (VLDB 08), Auckland (NZ), pp. 1379–1390, ACM (2008) 58. Java Community Process: Java Specification Request JSR 94: Java Rules Engine API. (2009) http://jcp.org/en/jsr/detail?id=94. Abgerufen 9. Dezember 2009

234


59. Jeffery, S., Alonso, G., Franklin, M., Hong, W., Widom, J.: A Pipelined Framework for Online Cleaning of Sensor Data Streams. In: Proceedings of the 22nd International Conference on Data Engineering, Atlanta (USA), pp. 140–142, IEEE Computer Society (2006) 60. Jess. The Rule Engine for the Java Platform. (2008) http://www.jessrules.com. Abgerufen 9. Dezember 2009 61. Kruchten, P.: Architectural Blueprints – The „4+1“-View Model of Software Architecture. IEEE Software, 12(6), pp. 42–50 (1995) 62. Lamport, L.: Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7), pp. 558–565 (1978) 63. Luckham, D.: The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley, Boston (2002) 64. Luckham, D.: BAM And CEP: A Marriage Of Necessity Or: Why BAM Must Use CEP. (2004) http://www.ebizq.net/topics/cep/features/5102.html. Abgerufen 9. Dezember 2009 65. Luckham, D.: A View of the Current State of Event Processing. Vortragsfolien auf dem First Workshop on Event Processing, Yorktown Heights, NY, USA (2006) http://complexevents.com/wp-content/uploads/2006/03/dluckham-workshop-03-2006.pdf. Abgerufen 2. August 2009 66. Luckham, D.: A Short History of Complex Event Processing – Part 1: Beginnings. (2008) http://complexevents.com/wp-content/uploads/2008/02/1-a-short-history-of-cep-part-1.pdf. Abgerufen 9. Dezember 2009 67. Luckham, D.: A Short History of Complex Event Processing – Part 2: the rise of CEP. (2008) http://complexevents.com/wp-content/uploads/2008/07/2-final-a-short-history-of-cep-part2.pdf. Abgerufen 9. Dezember 2009 68. Luckham, D., Schulte, R. (eds.): Event Processing Glossary - Version 1.1. Event Processing Technical Society (2008) http://www.ep-ts.com. Abgerufen 9. Dezember 2009 69. Lundberg, A.: Leverage Complex Event Processing to Improve Operational Performance. Buisness Intelligence Journal, 11(1), pp. 55–65 (2006) 70. Maatjes, N.C.: Automated transformations from ECA rules to Jess. Master Thesis, University of Twente (2007) http://essay.utwente.nl/559/. Abgerufen 10. Dezember 2009 71. McCoy, D.W.: Business Activity Monitoring: Calm Before the Storm. Gartner Research, ID Number: LE-15-9727 (2002) http://www3.gartner.com/resources/105500/105562/105562.pdf. Abgerufen 9. Dezember 2009 72. McKay, L.: Forrester gives a Welcoming Wave to Complex Event Processing. (2009) http://www.destinationcrm.com/Articles/CRM-News/Daily-News/Forrester-Gives-a-Welcoming-Wave-to-Complex-Event-Processing-55492.aspx. Abgerufen 9. Dezember 2009 73. Michelson, B.M.: Event-Driven Architecture Overview. Patricia Seybold Group (2006) http://www.psgroup.com/. 74. Mirabi, S.: Ereignisgesteuerte Architektur für die Entwicklung Java EE-basierter Business Intelligence Lösungen für Sprachapplikationen. Masterarbeit, Fakultät IV – Abteilung Informatik, Fachhochschule Hannover (2007) 75. Mühl, G., Fiege, L., Pietzuch, P.R.: Distributed Event-Based Systems. Springer-Verlag, Berlin, Heidelberg (2006) 76. Natis, Y.V., Schulte, R.W.: Advanced SOA for Advanced Enterprise Projects. Gartner Research, Note Number: G00141940 (2006) 77. Nguyen, T., Schiefer, J., Tjoa, A.: Sense and Response Service Architecture (SARESA) – An Approach towards a Real-time Business Intelligence Solution and its use for Fraud Detection Application. In: Proceedings of the 8th International Workshop on Data Warehousing and OLAP, pp. 77–86 (2005) 78. Nilsson, N.J.: Principles of Artificial Intelligence. Springer-Verlag, Berlin, Heidelberg, New York (1982)


235

79. OASIS: Web Services Business Process Execution Language Version 2.0. (2007) http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf. Abgerufen 9. Dezember 2009 80. Object Management Group: Object Constraint Language (OCL), OMG Available Specification Version 2.0. (2006) http://www.omg.org/spec/OCL/2.0/PDF/. Abgerufen 9. Dezember 2009 81. Object Management Group: Unified Modeling Language (UML). (2009) http://www.uml.org. Abgerufen 9. Dezember 2009 82. Object Management Group: Business Process Modeling Notation, V1.1. (2008) http://www.bpmn.org/. Abgerufen 9. Dezember 2009 83. Oracle: Oracle Event-Driven Architecture Suite 11g. (2009) http://www.oracle.com/technologies/soa/eda/eda-suite.html. Abgerufen 9. Dezember 2009 84. Ossowski, S., Hernández, J., Iglesias, C., Fernández, A.: Engineering agents systems for decision support. In: Tolksdorf, P., Zambonelli, F. (eds.) Engineering Societies in an Agent World III, LNAI, pp. 234–274, Springer-Verlag, Berlin, Heidelberg (2002) 85. Paton, N., Díaz, O.: Active Database Systems. ACM Computing Surveys, 31(1), pp. 63–103 (1999) 86. Pawlowski, O., Dunkel, J., Bruns, R., Ossowski, S.: Applying Event Stream Processing on Traffic Problem Detection. In: Seabra Lopes, L. et al. (eds.) Proceedings of the 14th Portuguese Conference on Artificial Intelligence (EPIA’2009), Aveiro (Portugual), pp. 27–38, Springer-Verlag, Berlin, Heidelberg (2009) 87. Petrasch, R., Meimberg,O.: Model Driven Architecture - Eine praxisorientierte Einführung in die MDA. dpunkt.verlag (2006) 88. Pohl, K., Böckle, G., van der Linden, F.: Software Product Line Engineering. Foundations, Principles, and Techniques. Springer-Verlag, Berlin, Heidelberg (2005) 89. Progress Software Corporation: Apama Event Processing Platform. (2009) http://web.progress.com/apama/complex-event-processing.html. Abgerufen 9. Dezember 2009 90. Puppe, F.: Einführung in Expertensysteme. Springer-Verlag, Berlin, Heidelberg (1988) 91. Reussner, R., Hasselbring, W. (eds.): Handbuch der Software-Architektur. dpunkt.verlag, Heidelberg (2008) 92. Rieger, I., Bruns, R.: SOA-Governance und -Rollen: Sichern des Mehrwerts einer serviceorientierten Architektur. OBJEKTspektrum, 2007 (1), pp. 20–24 (2007) 93. Rizvi, S., Jeffery, S.R., Krishnamurthy, S., Franklin, M.J., Burkhart, N., et al.: Events on the edge. In: Proceedings of the 2005 ACM SIGMOD International Conference on Management of Data, pp. 885–887 (2005) 94. The Rule Markup Initiative: RuleML. Technischer Bericht (2009) http://ruleml.org/. Abgerufen 9. Dezember 2009 95. Schiefer, J., Rozsnyai, S., Saurer, G.: Event-Driven Rules for Sensing and Responding to Business Situations. In: Proceedings of the Inaugural International Conference on Distributed Event-Based Systems (DEBS), Toronto (Canada), pp. 198–205, ACM (2007) 96. Schmidt, D., Stal, M., Rohnert, H., Buschmann, F.: Pattern-oriented Software Architecture. Volume 2: Patterns for Concurrent and Net-worked Objects, Wiley (2000) 97. Schmidt, K.-U., Stühmer, R., Stojanovic, L.: Blending Complex Event Processing with the RETE Algorithm. In: iCEP2008: First International Workshop on Complex Event Processing for the Future Internet – colocated with the Future Internet Symposium, Vienna (Austria) (2008) http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-412/. Abgerufen 13. Dezember 2009 98. Schulte, R.W.: The Growing Role of Events in Enterprise Applications. Gartner Research, AV-20-3900 (2003) http://www.gartner.com/DisplayDocument?doc_cd=116129. Abgerufen 29. Mai 2009 99. Schulte, R.W., Chandy, K.M.: Understanding Event-Driven Architecture. (2007) http://www.ebizq.net/topics/cep/features/8274.html. Abgerufen 9. Dezember 2009

236


100. Software Engineering Institute (SEI) at Carnegie Mellon University: Software Architecture. (2009) http://www.sei.cmu.edu/architecture/start/community.cfm. Abgerufen 9. Dezember 2009 101. Sen, S., Stojanovic, N., Lin, R.: A Graphical Editor For Complex Event Pattern Generation. In: Proceedings of the Third ACM International Conference on Distributed Event-Based Systems (DEBS), Nashville, TN, USA (2009) 102. Sharon, G., Etzion, O.: Event-processing network model and implementation. IBM Systems Journal, 47(2), pp. 321–334 (2008) 103. Stahl, T., Völter, M.: Model-Driven Software Development. Wiley (2006) 104. StreamBase Systems, Inc.: StreamBase Documentation. (2009) http://streambase.com/developers-docs-pdfindex.htm. Abgerufen 9. Dezember 2009 105. Suntinger, M., Obweger, H., Schiefer, J., Gröller, E.: The Event Tunnel: Exploring EventDriven Business Processes. IEEE Computer Graphics and Applications, 28(5), pp. 46–55 (2008) 106. Taylor, H., Yochem, A., Phillips, L., Martinez, F.: Event-Driven Architecture – How SOA Enables the Real-Time Enterprise. Addison-Wesley, Boston (2009) 107. TIBCO Software Inc.: Event-Driven SOA: A Better Way to SOA. (2006) http://www.tibco.com/multimedia/wp-event-driven-soa_tcm8-803.pdf. Abgerufen 9. Dezember 2009 108. TIBCO Software Inc.: Complex Event Processing Software. (2006) http://www.tibco.com/software/complex-event-processing/default.jsp. Abgerufen 9. Dezember 2009 109. UC4: Complex Event Processing. (2009) http://senactive.uc4.com/fileadmin/senactive/en/processing.html. Abgerufen 9. Dezember 2009 110. W3C: OWL Web Ontology Language Guide, W3C Recommendation. (2004) http://www.w3.org/TR/owl-guide/. Abgerufen 9. Dezember 2009 111. W3C: RDF Primer, W3C Recommendation. (2004) http://www.w3.org/TR/rdf-primer/. Abgerufen 9. Dezember 2009 112. W3C: RDF Vocabulary Description Language 1.0: RDF Schema, W3C Recommendation. (2004) http://www.w3.org/TR/rdf-schema/. Abgerufen 9. Dezember 2009 113. W3C: RIF (Rule Interchange Format) Overview, W3C Working Draft. (2009) http://www.w3.org/TR/rif-overview/. Abgerufen 9. Dezember 2009 114. Walzer, K., Breddin, T., Groch, M.: Relative temporal constraints in the RETE algorithm for complex event detection. In: Proceedings of the Second International Conference on Distributed Event-Based Systems (DEBS), pp. 147–155, ACM (2008) 115. Wang, F., Liu, P.: Temporal management of RFID data. In: Böhm, K. et al. (eds.) Proceedings of the 31st Conference on Very Large Data Bases (VLDB), pp. 1128–1139, ACM (2005) 116. Wu, E., Diao, Y., Rizvi, S.: High-performance complex event processing over streams. In: Chaudhuri, S. et al. (eds.) Proceedings of the ACM SIGMOD International Conference on Management of Data, Chicago, Illinois, USA, pp. 407–418 (2006) 117. Zimmer, D., Unland, R.: On the Semantics of Complex Events in Active Database Management Systems. In: Proceedings of the 15th International Conference on Data Engineering (ICDE’99), pp. 392–399 (1999) 118. Zimmermann, J., Beneken, G.: Verteilte Komponenten und Datenbankanbindung. AddisonWesley, München (2000)

Sachverzeichnis

Abbildungssicht, 206 abonnieren, 54 Abstraktion, 86 Abstraktionsebene, 20 Action, siehe Aktion Adapter, 63 In-, 63, 69 Out-, 63, 70 Adapterklassen, 160 Aggregation, 92, 119 Aggregationsfunktionen, 114 Agilität, 17 Air Traffic Management, 41 Aktienmarktticker, 57 Aktion, 116 Aktionskontext, 116 Aktionsplanung, 173 Aktive Datenbanken, 10 Aktualität, 32, 51, 73 Algorithmic Trading, siehe Wertpapierhandel Aliasnamen, 111 Analytik, 44 Anforderungen funktionale, 217 nichtfunktionale, 217 Anforderungsanalyse, 217 Ankunftszeitpunkt, 90 Architekturdokumentation, 202 Architekturmuster, 178 Architektursteckbrief, 202 Asynchrone Interaktion, 53 Asynchronität, 53 Auftrittszeit, 90 Auftrittszeitpunkt, 87 Ausführungsumgebung, 183 Ausgangskanal, 162 Ausnahmebehandlung, 18

Backend-System, 63 Batch-Window, 115 Betrugserkennung, 45 Beziehungen Abstraktion, 93 Aggregation, 92 kausale, 21, 91 Korrelation, 91 temporale, 91 transitive, 96 ursächliche, 91 zeitliche, 91 Beziehungstyp, 93 BPEL, 35 BPEL Process Engine, 164 BPMN, 165 Business Activity Monitoring, 40, 169, 228 Business Intelligence, 25, 41 CEP, siehe Complex Event Processing CEP-Anwendung, 69 CEP-Komponente, 66 leichtgewichtig, 69 schwergewichtig, 72 CEP-Netzwerk, siehe Event Processing Network CEP-Plattform, 146 CEP-Schnittstelle, 162 Cleaning-Regel, 187 Complex Event Processing, 57 Eigenschaften, 58 Entwicklungsstand, 223 Historie, 9 Qualitätsmerkmale, 72 Standards, 223 Werkzeugunterstützung, 224 Constraints, 97

237

238 Content Enrichment, siehe Kontextwissen Content-based Routing, 144 Continuous Query Languages, 146 Correlation Set, 194 CQL, siehe Continuous Query Languages Dashboard, 167 Datenverarbeitungsmodell dynamisch, 29 statisch, 24 Datenvolumina, 39 Decision Support System, 149 Delegation, 167 Designmuster, 178 Diskrete Ereignissimulation, 9 Dispatcher, 190 Dispatcher-Klasse, 145 Domäne, 34 Drill-down, 40 Drools Fusion, 148 Durchschnittsgeschwindigkeit, 77 ECA-Regel, 10 Echtzeitfähigkeit, 32, 58 EDA, siehe Event-Driven Architecture EDA-Entwicklung, 217 EDA-Referenzarchitektur, 204 EDA-Schichten, 61 Eingangskanal, 162 Enterprise Application, siehe Unternehmensanwendungen Enterprise Application Integration, 36, 45 Enterprise Integration Backbone, 163 Enterprise Service Bus, 163 Entkopplung, 31, 54 Entscheidungsunterstützungssystem, siehe Decision Support System Entstehungszeit, 59 Entwicklerhandbuch, 202 Entwicklungsmethodik, 224 Entwurfsmuster, 177 Architekturmuster, 178 Cleaning, 187 Content-based Routing, 189 Content-Enrichment, 193 Designmuster, 178 EDA-Schichten, 180 Ereignisagenten, 182 Filtern, 188 Granularitäts-Shift, 196 Korrelationsdimensionen, 194 Längenfenster, 190 Pipeline, 184 Reduktionsfenster, 190

Sachverzeichnis Semantik-Shift, 197 Translation, 192 Verarbeitungs-Pipeline, 184 Verarbeitungsmuster, 178 Zeitfenster, 190 EPA, siehe Event Processing Agent EPN, siehe Event Processing Network Ereignis, 48 Gültigkeitsdauer, 113 abgeleitetes, 91 Anwendungs-, 86 atomar, 93 Beziehungen, 91 Datenformate, 89 einfaches, 20 Geschäfts-, 48, 171 komplexes, 20, 92 Löschen, 118 Prozess-, 87 System-, 48 technisches, 48 Visualisierung, 167 Zeitverhalten, 88 Ereignis-Constraints, 97 Ereignisabstraktion, 20 Ereignisalgebra, 109 Aggregationsfunktionen, 114 Aliasnamen, 111 boolesche Operatoren, 110 Instanzauswahl, 112 Instanzkonsumierung, 112 Kontextbedingungen, 111 Negationsoperator, 110 Sequenzoperator, 110 Simultanoperator, 110 Sliding Windows, 113 Ereignisbehandlung, 63, 159 Ereignisdaten, 87 Kontextdaten, 87 Metadaten, 87 Zeitaspekte, 88 Ereignisfolge, 109 Ereignisgesteuert, 6, 49 Ereignishierarchie, 94 Ereignisinstanz, 89, 109 Ereigniskanal, 162 Ereigniskontext, 87 Ereignismodell, 66, 95 Ereignismuster, 19, 59, 109 Ereignisobjekt, 89 Ereignisorientierung, 5 Ereignisquelle, 31, 51, 61 Ereignisregel, 67, 107 Aktionsteil, 60

Sachverzeichnis Bedingungsteil, 60 Ereignissenke, 31, 51 Ereignissteuerung, siehe Ereignisgesteuert Ereignisstrom, 62, 89 Ereignisstruktur, 95 Ereignistransformation, 117 Ereignistyp, 88 abstrakter, 94 konkreter, 94 Ereignisverarbeitung, 62 deklarativ, 31 explizite, 31 implizite, 27 Ereignisverarbeitungssprache, siehe Event Processing Language Ereigniswolke, 15 ESP, siehe Event Stream Processing Esper, 125 Aggregationsfunktionen, 134 Aliasnamen, 130 Batch-Window, 133 Boolesche Operatoren, 130 Event Processing Agent, 141 From-Klausel, 128 Gruppierungsfunktion, 135 Insert-Klausel, 137 Join-Operation, 130 Kontextbedingungen, 130 Längenfenster, 132 Pattern, 130 Pattern Guards, 133 Select-Klausel, 128 Sequenzoperator, 130 Sliding Window, 132 Subscriber-Klasse, 129 Where-Klausel, 128 Zeitfenster, 133 Esper Query Language, 126 Event Handling, siehe Ereignisbehandlung Event Object, siehe Ereignisobjekt Event Pattern, siehe Ereignismuster Event Processing, siehe Ereignisverarbeitung Event Processing Agent, 66 Event Processing Engine, 68, 139 Event Processing Language, 146 Event Processing Network, 69 dynamisch, 69 Netzstruktur, 69 Physikalische Verteilung, 143 statisch, 69 Event Processing Rule, siehe Ereignisregel Event Processing Technical Society, 11, 48 Event Sink, siehe Ereignissenke Event Source, siehe Ereignisquelle

239 Event Stream, siehe Ereignisstrom Event Stream Processing, 57 Event-Driven, siehe Ereignisgesteuert Event-Driven Architecture, 28, 50 Anwendungsgebiete, 39 Eigenschaften, 51 Entwicklungsstand, 223 Grundzyklus, 49 Historie, 9 Kommunikationsmuster, 53 logische Schichten, 61 Prozessphasen, 217 Prozessschritte, 214 Qualitätsmerkmale, 72 Standards, 223 Testen, 75 Verarbeitungsmodell, 51 Vorgehen zur Einführung, 227 Vorgehensmodell, 218 Event-Handler, 166 Factory-Methode, 127 Fassade, 161 Fehlersuche, 74 FIFO-Strategie, 113 Filtering, siehe Filterung Filtern, 118 Filterung, 118 Fire-and-Forget, 185 Fraud Detection, siehe Betrugserkennung Gegenwartsperspektive, 28 Geschäftsdomäne, 34 Geschäftsereignis, 171 Geschäftsprozess, 14 ablauforientiert, 25 ereignisgesteuert, 14, 30 Geschäftsregel, 172 Global Event Cloud, siehe Ereigniswolke Granularitäts-Shift, 196 Gruppierungsfunktion, 135 Handelssysteme, 45 Hard-Constraint, 99 IEEE-Standard 1471-2000, 50 In-Adapter, 63 In-Memory-Ansatz, 58 Induktionsschleifen, 80 Information Hiding, siehe Kapselung Informationspanel, 173 Integrationsarchitektur, 159 Integrationsinfrastruktur, 31 Interoperabilität, 31

240 Intrusion Detection, 45 Invariante, 98 IT-Blindheit, 169 Iteration, 218 Java Rule Engine API, 224 Jess, 147 Kapselung, 159 Kausalität, 59 Klassendiagramme, 96 Kohäsion, 71 Kommunikationsmuster, 53 Komplexität fachliche, 15 technische, 15 Kontextbedingungen, 111 Kontextwissen, 59, 120 Kontroll- und Überwachungssysteme, 41 Kontrollsignalsensoren, 80 Kopplung, 52 Korrelation, 91 zeitliche, 102 Längenfenster, 113 Laborlogistik, 43 Lasttest, 218 Latenzzeit, 39 Logistik, 5 Massendaten, 73 Mediator, 51 Message-oriented Middleware, 163 Messaging Pattern, 179 Metadaten, 87 Modellgetriebene Softwareentwicklung, 149 Modellierung, 216 MOM, siehe Message-oriented Middleware Monitoring, 40 Monitoring-Schicht, 180 multimodales Verkehrssystem, 77 Mustererkennung, 59, 68 Nesper, 125 Netzwerkmanagement, 9 Nutzdaten, 67 Obertyp, 94 Object Constraint Language (OCL), 98 Ontologie, 96 Orchestrierung, 35 Out-Adapter, 63 OWL, 96 Pattern, siehe Entwurfsmuster

Sachverzeichnis Pattern Guards, 134 Pattern Matching, siehe Mustererkennung Performance-Test, 218 Phishing, 121 Pilotprojekt, 228 Pipeline, 184 Pipes-and-Filters-Muster, 184 Plug-Ability, 52 Polnische Notation, 147 Proaktives Verhalten, 17 Produktlinie, 202 Produktqualität, 214 Prozesskomplexität, 213 Prozessphasen, 217 Prozessqualität, 213 Prozessrisiken, 214 Prozessschritte, 214 Pseudosprache, 108 Publish/Subscribe, 53 Pull-Mechanismus, 171 Pull-Modus, 54 Push-Mechanismus, 171 Push-Modus, 54 Qualitätssicherung, 219 Randereignisse, 85 RAPIDE-EPL, 67 RDF, 96 RDF-S, 96 Reaktionsfähigkeit, 32 Reduktionsfenster, 190 Redundanz, 74 Referenzarchitektur, 202 Abbildungssicht, 206 Struktursicht, 204 Referenzereignismodelle, 224 Regel, siehe Ereignisregel regelbasierte Systeme, 10 Regelinterpreter, 68 Regelspaghetti, 75 Regelsprachen, 147 Reifegrad, 225 Request/Reply, 27 RETE-Algorithmus, 148 RFID, 43 Risikomanagement, 17 Robustheit, 74 Rule Interchange Format, 224 RuleML, 224 Schichtenarchitektur, 180 Schnittstellenklassen, 160 Scorecard, 167

Sachverzeichnis Semantic Web, 96 Semantik-Shift, 197 Sense & Respond Behaviour, 49 Sensoren, 41 Sensornetzwerke, 41, 79 Separation of Concerns, 162 Service, 35 Service Level Agreement, 41 Service-orientierte Architektur, 34 Service-Portfolio, 35 Sichten, 86 Simulation, 218 Singleton, 141 Singleton-Pattern, 127 Skalierbarkeit, 39, 74 Sliding Window, 113 SOA advanced, 38 ereignisgestuert, 38 event-driven, 38 SOA-Governance, 36 SOAP, 36 Soft-Constraint, 99 Softwarearchitektur, 50, 202 konventionelle, 23 Softwareentwicklungsprozess, siehe Vorgehensmodell Softwarequalität, 72 Splitting, 119 Sprachtypen, 146 Struktursicht, 204 Synchrone Interaktion, 53 Synchronität, 53 Synthese, 121 Telekommunikation, 45 temporales Schließen, 10 Testen, 218 Tracing, 168

241 Track-and-Trace, 44 Tracking, 168 Traffic Management, siehe Verkehrskontrolle und -steuerung Transformation, 117 Translation, 117 Transparenz, 17 UML, 96 Unified Process, 218 Unternehmensanwendungen, 63 Unternehmensindikatoren, 40 Unternehmensnetzwerk, 5 Untertyp, 94 Verarbeitungsmuster, 178 Vergangenheitsperspektive, 24 Verkehrsdichte, 77 Verkehrsinfrastruktur, 77 Verkehrskontrolle und -steuerung, 76 Verkehrsleitstand, 172 Verkehrsstärke, 77 Verkehrweg, 77 Verteilungsmuster, 183 Visualisierung, 167 Vorgehensmodell, 213 iterativ, 218 Vorstudie, 227 Wartbarkeit, 74 Web Services, 36 WENN-DANN-Regel, 60 Wertpapierhandel, 45 WSDL, 36 Zeitfenster, 113 Zeitstempel, 87 Zeitverhalten, 88

Event-Driven Architecture: Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse (Xpert.press)

Event-Driven Architecture: Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse (Xpert.press) (German Edition)

FR-1 Firebal

User Interface-orientierte Softwarearchitektur GERMAN

Eine Falle fr die Medon

Architecture

Algorithmic Architecture Architecture Design

Шляпочные грибы СССР. Род Cortiniarius Fr

Род Pluteus Fr. в Самарской области

Die Pimernells auf fr hlicher Seefahrt

Archigram: Architecture without Architecture

Folding Architecture

Immaterial Architecture

Beyond Architecture

Animal architecture

Understanding Architecture

Allegorical Architecture

Surface Architecture

Surface architecture

Gothic Architecture

FPGA Architecture

Terminal Architecture

Architecture Depends

Architecture - Dictionary of Architecture and Building Technology

EISA System Architecture (PC System Architecture)

Occupying Architecture

Container Architecture

Animal architecture

Thinking Architecture

Event-Driven Architecture: Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse (Xpert.press)