Eventbasierte Systeme

Ein eventbasiertes System verwendet events um z.B. das Prinzip von Publish and Subsc-ribe zu implementieren. Dieses Prinzip besagt, dass ein Sender (engl.: Producer) und ein Empfänger (engl.: Consumer) Nachrichten mittels events übermitteln. Sender und Emp-fänger sind dabei voneinander entkoppelt. Das bedeutet, der EmpEmp-fänger registriert (engl.:

subscribe) sich für den Empfang von bestimmten gewünschten Nachrichten bei einem Event Notification Service (auch Publish/Subscribe Middleware oder kurz Pub/Sub ge-nannt). Dieser Event Notification Service dient als Vermittler zwischen Sender und Emp-fänger und verteilt (engl.: publish) eine gesendete Nachricht an die EmpEmp-fänger, die sich für diesen bestimmten Nachrichtentyp registriert haben. [Mühl06, S. 11 - 14; Chan09, S.

108 - 109]

Eine Möglichkeit der Implementierung des Publish and Subscribe-Prinzips bietet der Java Message Service (JMS), siehe [Haas02] oder der CORBA Notification Service, siehe [Tark05]. In Abbildung 25 ist die Architektur eines Publish and Subscribe-Systems gra-phisch dargestellt.

Event

Event-basierte Interaktion

Pub/Sub Interface Produzent

Benachrichtigung

Benachrichtigung Konsument

Benachrichtigungsservice Benachrichtigungsservice

Nachricht Kommunikation

Abbildung 25: Architektur eines Publish and Subscribe-Systems in Anlehnung an [Mühl06, S. 12]

In Abbildung 25 ist zu erkennen, dass sich sowohl verschiedene Producer als auch ver-schiedene Consumer bei einem Notification Service registrieren, die wiederum über mes-sages bzw. events miteinander kommunizieren. Für die Registrierung stellen die Notifica-tion Services spezielle Pub/Sub Interfaces zur Verfügung.

Eine andere Form der eventbasierten Systeme bildet Complex Event Processing in Form von CEP engines. CEP engine ist ein Begriff, der durch Hersteller aus dem CEP-Umfeld geprägt wurde. In einem White Paper der IBM Corp. ist der Begriff CEP engine bei-spielsweise folgendermaßen beschrieben, siehe [Nech06]:

During runtime, events of different format and from multiple sources are fed in. The CEP engine analyzes them based on current rules and conditions.

Upon detection of the predefined patterns, alerts are sent out as messages and actions are triggered. These messages are also fed back into the en-gine and treated as incoming events, enabling nested patterns.

Bei Coral8 Inc., einem amerikanischem CEP-Hersteller lautet die Definition von CEP engine folgendermaßen, siehe [Tsim06]:

A CEP engine is a platform for building and running applications, used to process and analyze large numbers of real-time events.

Diese Definition wurde von Coral8 Inc. später konkretisiert, siehe [Cora07]:

A software product used to create and deploy applications that process large volumes of incoming messages or events, analyze those messages or events in various ways, and respond to conditions of interest in real-time.

Der Unterschied von Complex Event Processing-Technologie zu Publish and Subscribe-Systemen ist, dass CEP in der Lage ist, unterschiedliche Eventtypen gleichzeitig zu ver-arbeiten. Bei Publish and Subscribe dagegen werden die events unabhängig von anderen events verarbeitet. [Chan07]

In [Luck02, S. 329 - 351] wird eine CEP engine auch als CEP infrastructure bezeichnet.

Sie ist die technische Umgebung, in welcher der Mustererkennungsprozess ausgeführt wird. Die CEP engine besitzt Schnittstellen zu den Quellsystemen einer Organisation mit-tels Adapter. In Abbildung 26 sind die Komponenten eines Adapter abgebildet.

CEP Infrastruktur

Geordnete Ausgabe

IT Layer Sniffer

„Horcht“ nach einer bestimmten Gruppe von Events Event Adapter

Event Formatter Causal Map

Abbildung 26: Aufbau eines Adapter in Anlehnung an [Luck02, S. 337]

Innerhalb des Adapter werden durch den Sniffer diejenigen events, die für die Musterer-kennung nicht relevant sind, aus dem Eventstrom herausgefiltert. Das Filtern von events basiert auf den Eventtypen und deren Attributen [Tsim06]. Der Event Formatter ist für das Umwandeln (engl.: Mapping) der events aus dem Format des Quellsystems in ein Format, das die CEP engine interpretieren bzw. analysieren kann, zuständig. Mittels einer Causal

Funktion der Causal Map ist optional, d.h. nicht jeder Adapter beinhaltet diese Funktionali-tät. [Luck02, S. 336 - 338]

Die CEP infrastructure oder CEP engine besitzt eine Vielzahl von Adapter zu den jeweili-gen Quellsystemen der events z.B. zu einer Publish/Subscribe Middleware [Luck02, S.

338]. Abbildung 27 zeigt eine vereinfachte Architektur einer CEP infrastructure.

Quellsystem 1 Local

Abbildung 27: Exemplarischer Aufbau einer CEP-Umgebung in Anlehnung an [Luck02, S. 336]

In dieser Architektur werden die einzelnen events aus den verschiedenen Quellsystemen über die Adapter in der CEP engine gesammelt und dort von den einzelnen Analysewerk-zeugen wie Pattern Detector oder Activity Animation verarbeitet. Die CEP infrastructure bildet in diesem Zusammenhang die Basis, von der aus Business Activity Monitoring (BAM) betrieben werden kann, siehe dazu [Luck04a].

Eine CEP infrastructure, die auf EPN’s gestützt ist, ist in Abbildung 28 abgebildet.

Quellen

Abbildung 28: CEP infrastructure mit EPN in Anlehnung an [Luck02, S. 339]

Die Quellsysteme sind in dieser CEP infrastructure ebenfalls mittels Adapter angebunden.

Die ankommenden events werden in Echtzeit von den EPN’s verarbeitet, die wiederum einen Bestandteil der CEP engine bilden. Die CEP engine besitzt zusätzlich Schnittstellen für graphische Auswertungswerkzeuge. Eine weitere wichtige Eigenschaft von CEP engi-nes ist die Echtzeitfähigkeit. Das bedeutet, dass die events zum Zeitpunkt ihres Auftretens analysiert werden, gleichzeitig der Mustererkennungsprozess ausgeführt wird und an-schließend bei Bedarf mit entsprechenden, vordefinierten Aktionen reagiert werden kann.

Die genauen Zahlen an events, die von den Lösungen der einzelnen Hersteller pro Se-kunde verarbeitet werden können, sind im Abschnitt 4.4 genannt.

In einem Blog-Eintrag hat T. Puzak die Eigenschaften beschrieben, die eine CEP engine erfüllen muss, um optimal in einem Unternehmen eingesetzt werden zu können, siehe [Thec08]. In diesem Zusammenhang wird davon ausgegangen, dass die Grundfunktionali-täten wie Echtzeitfähigkeit und event aggregation zu complex events erfüllt werden und sind daher nicht aufgeführt:

• Der Erkennungsmechanismus muss in der Lage sein, event patterns zu identifizie-ren, bei denen die einzelnen events innerhalb einer bestimmten definierten Zeitpe-riode (auch längere ZeitpeZeitpe-rioden) auftreten oder nicht auftreten.

• Der Erkennungsmechanismus muss in der Lage sein, events nach der Reihenfol-ge ihres Auftretens unterscheiden zu können um MehrfacherkennunReihenfol-gen zu ver-meiden.

• Die CEP engine muss in der Lage sein, die complex events bzw. die auszulösen-den Aktionen in der bestimmten definierten Reihenfolge auszuführen.

• Die CEP engine muss in der Lage sein, die complex events bzw. die auszulösen-den Aktionen zu einem bestimmten definierten Zeitpunkt ausführen zu können.

• Die CEP engine muss in der Lage sein, bestimmte events beim Start oder Stopp der Anwendung auszulösen.

• Die CEP engine muss in der Lage sein, auftretende events nicht nur mit gleichen events zu complex events zu korrelieren, sondern auch mit anderen events, die beispielsweise durch SQL-Abfragen aus Datenbanken gewonnen werden.

• Die CEP engine muss in der Lage sein, auftretende events bei Bedarf abzuspei-chern und somit für spätere Auswertungen verfügbar zu machen.

• Die CEP engine muss in der Lage sein, mit externen Datenbanken interagieren zu können und somit Adapter für die gängigen Lösungen der bekannten Datenbank-hersteller (z.B. Oracle Corp.) zur Verfügung zu stellen.

• Die CEP engine muss Entwicklungsmöglichkeiten bzw. eine Entwicklungsumge-bung bereitstellen.

Für diese Arbeit ist vor allem die Fähigkeit einer CEP engine, auftretende events mit events aus SQL-Abfragen korrelieren zu können, sehr wichtig. Die Begründung hierfür ist, dass die Transaktionsevents mit bestimmten Daten aus Bestandssystemen erweitert wer-den müssen um die Durchführung der weiteren Untersuchungen mittels des in dieser Ar-beit beschriebenen Ansatzes gewährleisten zu können (siehe Abschnitt 6.1).