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

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¨urgen Dunkel

Event-Driven Architecture Softwarearchitektur f¨ur ereignisgesteuerte Gesch¨aftsprozesse

123

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

Prof. Dr. J¨urgen 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¨utzt. Die dadurch begr¨undeten Rechte, insbesondere die der ¨ Ubersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielf¨altigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielf¨altigung 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¨assig. Sie ist grunds¨atzlich verg¨utungspflichtig. 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¨aren und daher von jedermann benutzt werden d¨urften. Einbandentwurf: KuenkelLopka GmbH Gedruckt auf s¨aurefreiem 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

1 Einführung und Motivation

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

1 Einführung und Motivation

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

1 Einführung und Motivation

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

2 Ereignisse in Unternehmensanwendungen

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

2 Ereignisse in Unternehmensanwendungen

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

2.1 Bedeutung von Ereignissen

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 Ereignisse in Unternehmensanwendungen

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-

2.1 Bedeutung von Ereignissen

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

tiefere Abstraktionsebene

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

2 Ereignisse in Unternehmensanwendungen

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

tiefere Abstraktionsebene

?

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

2 Ereignisse in Unternehmensanwendungen

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?“

2.2 Grenzen von konventionellen Softwarearchitekturen

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

2 Ereignisse in Unternehmensanwendungen

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.

2.2 Grenzen von konventionellen Softwarearchitekturen

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 Ereignisse in Unternehmensanwendungen

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

2 Ereignisse in Unternehmensanwendungen

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.

2.3 Ereignisorientierung als Architekturstil

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

2 Ereignisse in Unternehmensanwendungen

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.

2.3 Ereignisorientierung als Architekturstil

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)

Ereignisverarbeitung

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

34

2 Ereignisse in Unternehmensanwendungen

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

2 Ereignisse in Unternehmensanwendungen

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.

Technologie-inhärent

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 Ereignisse in Unternehmensanwendungen

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 Ereignisse in Unternehmensanwendungen

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.

2.5 Anwendungsgebiete für EDA

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

2 Ereignisse in Unternehmensanwendungen

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

2.5 Anwendungsgebiete für EDA

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

2 Ereignisse in Unternehmensanwendungen

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.

2.5 Anwendungsgebiete für EDA

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).

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

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

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

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

3.1 EDA – Grundkonzepte

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

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

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.

3.1 EDA – Grundkonzepte

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

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

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].

3.1 EDA – Grundkonzepte

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

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

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

Technologie-inhärent

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-

3.1 EDA – Grundkonzepte

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

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

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

3.1 EDA – Grundkonzepte

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

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

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.

3.1 EDA – Grundkonzepte

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

Ereignisverarbeitung

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

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

Ereignisquellen

Ereignisverarbeitung

Ereignisbehandlung

Complex Event Processing

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

3.1 EDA – Grundkonzepte

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

•

•

• •

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

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 Event-Driven Architecture und Complex Event Processing im Überblick

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.

3.2 CEP – Grundkonzepte

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

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

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-

3.2 CEP – Grundkonzepte

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-

3.2 CEP – Grundkonzepte

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.

Event Processing Engine

Zentraler Event Processing Agent Regeln

Ereignismodell

schwergewichtig leichtgewichtig Engine

Modell

Engine

Regeln

Modell

Regeln

Event Processing Agent

Event Processing Agent

Engine

Modell

Regeln

Event Processing Agent

Abb. 3.9 Schwergewichtige versus leichtgewichtige CEP-Komponenten

72

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

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

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

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

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

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

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

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.

3.4 Fallstudie: Verkehrskontrolle und -steuerung

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

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

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-

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

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-

Complex Event Processing

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

Event Processing Engine

Ereignisregeln

Regel

Regel

Regel

Ereignistyp

Ereignistyp Constraint

Ereignistyp Constraint

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.

4.5 Fallstudie: Verkehrskontrolle und -steuerung

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.

4.5 Fallstudie: Verkehrskontrolle und -steuerung

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

Ereignisverarbeitung

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.

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

105

106

5 Ereignisverarbeitung

Complex Event Processing

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

5 Ereignisverarbeitung

• 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

5 Ereignisverarbeitung

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.

5.2 Konzepte zur Beschreibung von Ereignismustern

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

5 Ereignisverarbeitung

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.

5.2 Konzepte zur Beschreibung von Ereignismustern

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

5 Ereignisverarbeitung

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

5.3 Aktionen in Ereignisregeln

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

5 Ereignisverarbeitung

(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.

5.3 Aktionen in Ereignisregeln

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

5 Ereignisverarbeitung

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:

5.3 Aktionen in Ereignisregeln

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

5 Ereignisverarbeitung

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.

5.3 Aktionen in Ereignisregeln

123

Complex Event Processing

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

5 Ereignisverarbeitung

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 <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 = 0)

5.4 Ereignisregeln mit Esper Die in den beiden vorhergehenden Abschnitten eingeführte Regelsprache zur Ereignisverarbeitung ist bewusst einfach gehalten, um die grundlegenden Konzepte des Complex Event Processing herauszuarbeiten. Dieser Abschnitt zeigt nun, wie eine CEP-Anwendung mit einer konkreten Realisierungsplattform implementiert werden kann. Als Beispielplattform dient die Open-Source-CEP-Engine Esper [34]. Die EsperPlattform stellt eine leistungsfähige und weit verbreitete Event Processing Engine mit einer spezifischen Regelsprache (event processing language) zur Ereignisverarbeitung bereit. Esper steht als Java-Implementierung oder auch unter dem Namen Nesper für .NET zur Verfügung.15 Natürlich kann im Rahmen dieses Buches lediglich auf die Grundzüge von Esper eingegangen werden, weitere Details sind in der ausführlichen Esper-Dokumentation zu finden [35]. Für das Verständnis dieses Abschnitts sind Grundkenntnisse in der Programmiersprache Java hilfreich. Leser, die sich nicht für die Implementierungsdetails eines konkreten Werkzeuges interessieren, können diesen Abschnitt auch problemlos überspringen.

14

Das Beispiel zeigt nur eine Möglichkeit zur Umsetzung des Constraints. Wenn es das Verarbeitungsmodell einer CEP-Engine erlaubt, dann könnten alternativ auch nur bei den fehlerhaften StockEvent-Ereignissen die Attributwerte auf 0 gesetzt werden, während die konsistenten Ereignisse unverändert bleiben. In vielen Verarbeitungsmodellen ist jedoch die nachträgliche Änderung von aufgetretenen Ereignissen nicht erlaubt. 15 Die Installation von Esper gestaltet sich sehr einfach, es müssen lediglich mehrere jar-Dateien in die Entwicklungsumgebung eingebunden werden.

126

5 Ereignisverarbeitung

Beispielszenario Wertpapierhandel Zur Veranschaulichung von Esper verwendet dieser Abschnitt als Beispielszenario das in Abbildung 5.13 dargestellte einfache Ereignismodell aus dem Umfeld des Wertpapierhandels. Generelle Attribute sind im abstrakten Ereignistyp AbstractEvent modelliert: Jede Ereignisinstanz besitzt eine eindeutige ID eventID und einen Zeitstempel time. Abgeleitet von AbstractEvent sind folgende Ereignistypen: StockEvent zeigt die aktuelle Kursänderung bzw. den Kurswert eines Wertpapiers an und ist durch das Wertpapiersymbol und den entsprechenden Wert des aktuellen Kurses gekennzeichnet. AbstractEvent eventID time

MovingAverage Event symbol average

StockEvent symbol price

BuySignalEvent symbol price

NewsEvent symbol description

Abb. 5.13 Einfaches Ereignismodell für die Esper-Beispiele

MovingAverageEvent ist der Typ für ein aggregiertes Ereignis, das für eine einzelne Aktie den Durchschnittskurswert über die letzten 200 Tage berechnet, die sogenannte 200-Tage-Linie. Schließlich steht BuySignalEvent für das Kaufsignal für eine bestimme Aktie, und NewsEvent beschreibt die Ankunft einer Börseninformation zu einem Wertpapier. Einordnung von Esper Als Event Processing Language (EPL) bietet Esper eine SQL-ähnliche Abfragesprache für Ereignisströme an, die Esper Query Language (EQL). In EQL definierte Abfragen werden, nachdem sie einmal angestoßen worden sind, kontinuierlich auf einem eingehenden Ereignisstrom ausgeführt. Damit gehört Esper zur Klasse der Continuous Query Languages (CQL) [7] – wie auch die meisten kommerziellen Systeme, z.B. Coral8