CEP - Complex Event Processing

CEP Complex Event Processing Dr. Martin Bartonitz Product Manager SAPERION AG Vorsitzender des Aufsichtsrates: Dieter Matheis | Vorstand: Rudolf Gessinger (Vorstandsvorsitzender), Andreas Kunze | Amtsgericht Berlin-Charlottenburg HRB Nr. 78848 | CEP - Complex Event Processing Der Begriff Complex Event Processing ist seit Anfang 2005 auf den Markt gekommen und ist besonders durch die Promotion des Marktanalysten Gartner Group im Jahr 2006 auf starkes Interesse gestoßen. Als Vater der dahinter liegenden Ideen gilt Professor David Luckham - aktuell Research Professor of Electri- cal Engineering (Emeritus) at Stanford University. Die Gartner Group propagiert mit "SOA 2.0" (oder auch "Advanced SOA") eine Service Orientierte Architektur, die speziell auf Ereignisse (Events) in Echtzeit re- agiert. In diesem Zusammenhang wir auch von einer Event Driven Architecture (EDA) gesprochen. Sie soll nicht nur einzelne Events wie beispielsweise einen Auftragseingang erkennen sondern ganze Ereig- nisströme erfassen und verarbeiten können. Als ein kritisches Beispiel für die Auswertung von Ereignissen und einem angemessenen Reagieren darauf führt Lars Toomre ein Szenario aus dem Militärischen an. Man stelle sich das Informationschaos eines Commanders vor, wenn sich zwei gegnerische Panzerbatallione in einer Schlacht plötzlich gegenüber stehen. Wie transformiert der Commander Daten (der Freund/Find-Detektor piept!) in Informationen (da gibt es einige “bad guys” unter uns!), die hoffentlich mit ein paar anderen Information zum Wissen über das richtige Vorgehen gelangen lassen (der Beste Platz, den Feind anzugreifen, ist gleich dort drüben!)? Die hereinkommenden Daten haben keine gut definierte Struktur und werden zweifellos in allen Arten bzw. Formaten fließen. Überträgt man das Szenario auf die Finanzwelt, wird aus der Frage „Wo ist der Feind und in welcher Konzentration“ ein „“Was ist der Wert von kalkulierten Parametern wie der Volume-Weighted Average Price (VWAP, siehe http://en.wikipedia.org/wiki/VWAP ). Als so genannte Killerapplikationen mit star- kem Ereignis-Charakter gelten neben dem Echtzeithandel in der Finanzbranche, die Verwaltung von RFIDNetzen oder auch die Betrugserkennung. So ließen sich Kreditkartenbetrüger anhand typischer Transaktionsmuster mit Hilfe von CEP-Tools leichter aufspüren als mit den traditionellen Business Intel- ligence Tools. Insofern sei Complex Event Processing auch als natürliche Erweiterung von BI zu verste- hen. Complex Event Processing (“CEP”) ist eine aufkommende Technologie zum Generieren, Monitoren, Mes- sen, Steuern und Pflegen von Enterprise Information Systems, die die folgenden anderen Bereiche tan- giert: + Business Activity Monitoring (-> BAM) + Business Process Management (-> BPM) + Enterprise Application Integration (-> EAI) + Event-Driven Architecture (-> EDA) + Network and business level Security + Real-Time-Einhaltung von Gesetzen und Regularien, Regeln, Vereinbarungen and Verfahren (Compli- ance). Ziele von CEP Das Ziel von CEP ist es, die Unmengen an rudimentären Ereignisdaten, die zwischen den verschiedenen Schichten einer Enterprise IT-Infrastruktur fließen, so zu erschließen und zu transformieren, dass Ihr Einfluss auf high-level Unternehmensziele und Geschäftprozesse frühzeitig erkannt werden können. So- mit ist erst ein frühzeitiges, proaktives, korrigierendes Einschreiten in sich anbahnende, kritische Situa- tionen möglich, um so Schaden vom Unternehmen abwenden zu können. CEP verarbeitet Ereignisse, die durch Technologien wie Radio-Frequency Identification (RFID) erzeugt werden, oder Datenströme des Preisreportsysteme des Finanzmarktes oder z.B. Log-Ausgaben von Kom- munikationssystemen. CEP umfasst Techniken für das Erkennen komplexer Muster innerhalb einer gro- ßen Menge von Ereignissen, für das Transformieren von Ereignisströmen (event processing), für die Ana- lyse von Ereigniskorrelation und -abstraktion, zur Bildung von Ereignishierarchien. Beziehungen zwischen Ereignissen sind über Abhängigkeiten, Zugehörigkeiten zu Systemen sowie zeitlicher Nähe feststellbar. 21.02.2008 Seite 2 von 10 Die lange Zeit bis zur Lösung eines Problems oder dem Erkennen von neuen Möglichkeiten ohne den Ein- satz von CEP führt derzeit immer zu unnötig hohen Kosten. Die folgende Grafik zeigt den Zusammenhang zwischen proaktivem Handeln und den Kosten für die Korrektur von Fehlern bzw. zur Vermeidung von Fehlern. Abbildung 1: Schnellere Reaktion durch Einsatz von CEP-Systemen CEP als Basis von BAM-Systemen Complex Event Processing sorgt wie beschrieben für die Auswertung der diversen Ereignissen in Daten- strömen sämtlicher IT-Systeme eines Unternehmens von Infrastrukturnahen Technologien wie das Netz- werk oder die eingesetzten Rechner und Speichersysteme bis hin zu den einzelnen Anwendungen für die Bearbeitung von Geschäftsfällen. Damit die Verantwortlichen in den einzelnen Geschäftsbereichen, sei es die IT, der Linienmanager eines Fachbereichs oder die Geschäftsleitung selbst, sich über die jeweili- gen Systemzustände informieren können, werden so genannten Dashboards zur Verfügung gestellt. Diese Dashboards sind in der Lage, die Systemzustände inklusive ihrer zeitlichen Entwicklung grafisch darzu- stellen. In diesem Zusammenhang wird von einem so genannten Business Activity Monitoring (BAM) ge- sprochen. Die Gartner Group hat eine generische BAM-System-Architektur entwickelt, die sich in 3 Ebenen eintei- len lässt, und in der die Verarbeitung von Ereignissen gut dargestellt ist: + Event Absorption + Event Processing and Filtering + Event Delivery, Display and Action 21.02.2008 Seite 3 von 10 Die in der folgenden Grafik dargestellte Architektur stellt eine Basisstruktur eines BAM Systems dar, welche in der Praxis in unter-schiedlichen Ausprägungen angewendet wird. Vertiefende Informationen stehen <BAM> zur Verfügung. Abbildung 2: BAM Architektur, abgeleitet von Gartner Die unterste Ebene der BAM Architektur, der Event Absorption Layer, hat die Aufgabe, alle im Unter- nehmen auftretenden Ereignisse (sowohl geschäftliche als auch technische) zu erfassen. Dabei werden zwei unterschiedliche Ansätze angewandt Im Event Processing und Filtering Layer, dem wichtigsten eines BAM-Systems, werden die relevanten Ereignisse verarbeitet und analysiert. Wichtigster Bestandteil der Event Processing and Filtering Schicht ist die Rule Engine. Diese übernimmt die Auswertung von Ereignissen, basierend auf definierbaren Re- geln, um Abweichungen vom Normalverhalten aufzuspüren. Wird eine der festgelegten Regeln verletzt, wird ein Alert generiert und an den darüberliegenden Event Delivery und Display Layer übergeben. In der Schicht Event Delivery und Display Layer müssen die zuvor generierten Alerts in Echtzeit in einer verständlichen Art und Weise an die verantwortlichen Personen kommuniziert werden. Die folgende Grafik zeigt ein Dashboard zum Monitoren der Reisegepäckverarbeitung an einem Flugha- fen. Beispiel eines BAM Dashboards 21.02.2008 Seite 4 von 10 Relevante Standards Die Divergenz bei den einzelnen Ereignisformaten (in Log Dateien von Applikationen, Datenbanksyste- men, Überwachungswerkzeugen) hat zur Notwendigkeit geführt, einen eigenen Standard für das Format eines Ereignisses zu entwickeln. Vorreiter bei der Entwicklung war IBM mit ihrem Standard Common Base Event (CBE). Im Jahr 2005 wurde CBE als Teil des WSDM MUWS (Web Service Distributed Management: Management Using Web Ser- vices) Standards der OASIS (Organization for the Advancement of Structured Information, www.oasis- open.org) in der Version 1.0 ratifiziert. Wie auch CBE basiert WSDM auf einem XML Schema, das die Struktur und den Aufbau der Events vorgibt. Das WSDM Event Format bietet einen standardisierten Rahmen für das Verarbeiten, Korrelieren und In- terpretieren von Ereignissen von unterschiedlichen Plattformen und Herstellern. Im WSDM Event Format Container werden die Ereignisse in drei Kategorien eingeteilt: Event Source: Die Event Quelle, die den Auslöser des Events identifiziert. Die Event Source ist ein Pflichteintrag Event Reporter: Das System oder die Applikation, welche ein Event meldet. Der Event Reporter kann gleichzeitig auch die Event Source sein. In diesem Fall entfällt der Event Reporter Eintrag. Wenn nicht, muss der Event Reporter angegeben werden. Eventspezifische Daten: Diese sind von Ereignis zu Ereignis verschieden und sind notwendig, um die Be- deutung des Events zu verstehen. Ein WSDM Event Container kann wie folgt aussehen: <muws1:ManagementEvent ... muws1:ReportTime=”xs:dateTime”?> <muws1:EventId>xs:anyURI</muws1:EventId> <muws1:SourceComponent ...> <muws1:ResourceId>xs:anyURI</muws1:ResourceId> ? <muws1:ComponentAddress>{any}</muws1:ComponentAddress> * {any}* </muws1:SourceComponent> <muws1:ReporterComponent ...> <muws1:ResourceID>xs:anyURI</muws1:ResourceId> ? <muws1:ComponentAddress>{any}</muws1:ComponentAddress> * {any}* </muws1:ReporterComponent> ? {any}* </muws1:ManagementEvent> Das WSDM Event Format setzt sich aus folgenden Elementen zusammen: muws1:ManagementEvent: Das Basiselement des WSDM Event Containers. muws1:ManagementEvent/@muws1:ReportTime: Der Zeitpunkt an dem das Ereignis gemeldet wurde. Der Wert muss in der maximal möglichen Präzision angeben werden, die auch von der ereigniserzeugenden Applikation oder Plattform unterstützt wird. muws1:ManagementEvent/muws1:EventId: Dieses Element dient als primärer Identifikator für das Ereignis. Dieser muss im umgesetzten Szenario eindeutig sein. Das Element kann als Primary Key des Ereignisses genutzt werden und muss vom Typ Uni- form Resource Identifier (URI) sein.