Krešimir Vidačković, Thomas Renner, Sascha Rex. Marktübersicht

Transkript

1 FRAUNHOFER-INSTITUT FÜR arbeitswirtschaft und organisation iao Krešimir Vidačković, Thomas Renner, Sascha Rex Marktübersicht Real-Time Monitoring Software Event Processing Tools im Überblick

2 Krešimir Vidačković Thomas Renner Sascha Rex Event Processing Tools im Überblick

3 Autoren Krešimir Vidačković, Thomas Renner, Sascha Rex Kontaktadresse Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO Nobelstraße Stuttgart Telefon Telefax URL Hinweis auf das Forschungsprojekt ic-rfid Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Wirtschaft und Technologie (BMWi) unter dem Förderkennzeichen 01MT06006 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. ISBN: Druck und Weiterverarbeitung IRB Mediendienstleistungen Fraunhofer-Informationszentrum Raum und Bau IRB, Stuttgart Für den Druck des Buches wurde chlor- und säurefreies Papier verwendet. Verlag und Druck Fraunhofer Verlag, Fraunhofer-Informationszentrum Raum und Bau IRB Postfach , Stuttgart Nobelstraße 12, Stuttgart Telefon Telefax URL by FRAUNHOFER IAO, 2010 Alle Rechte vorbehalten Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Verwertung, die über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zustimmung des Verlags unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Speicherung in elektronischen Systemen. Die Wiedergabe von Warenbezeichnungen und Handelsnamen in diesem Buch berechtigt nicht zu der Annahme, dass solche Bezeichnungen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürften. Soweit in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z.b. DIN, VDI) Bezug genommen oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr für Richtigkeit, Vollständigkeit oder Aktualität übernehmen. 2 Fraunhofer IAO

4 Inhalt Abbildungen 4 1 Einführung Grundlagen Komponenten von Event Processing Tools 13 2 Marktübersicht Vorgehensweise bei der Erstellung der Marktübersicht Kriterienraster Produktbeschreibungen Sybase Aleri Streaming Platform / CEP Progress Apama TIBCO BusinessEvents & Spotfire rulecore CEP Server Truviso Continuous Analytics UC4 Decision & UC4 Insight JBoss Drools Fusion Oracle EDA Suite EsperTech Esper Event Zero Event Processing Network StreamBase Event Processing Platform Open ESB Intelligent Event Processor (IEP) Vitria M3O Analytic Server & M3O Operations Book Realtime Monitoring RTM Analyzer Informatica Rulepoint Starview Smart Enterprise Platform Microsoft StreamInsight Axway Synchrony Sentinel West Global Vantify IBM WebSphere Business Events SL RTView Tabellarische Übersicht 72 3 Fazit 76 Abkürzungen 78 Referenzen 80 Fraunhofer IAO 3

5 Abbildungen Abbildung 1: Logische Strukturierungsschichten beim Event Processing 10 Abbildung 2: Modellierung mit dem Sybase Aleri Studio 22 Abbildung 3: Entwicklung mit dem Progress Apama Studio 24 Abbildung 4: Modellierung mit dem Progress Apama Builder 25 Abbildung 5: Exemplarisches TIBCO Spotfire 27 Abbildung 6: Modellierung mit UC4 Decision 34 Abbildung 7: Beispielhafte Event Tunnel-Darstellung mit UC4 Insight 35 Abbildung 8: Entwicklung mit JBoss Drools 37 Abbildung 9: Modellierung mit der Oracle EDA Suite 39 Abbildung 10: Exemplarisches Oracle BAM 40 Abbildung 11: Beispielhaftes EsperHQ 42 Abbildung 12: Event Zero Administrations- und Entwicklungstool 45 Abbildung 13: Beispielhaftes Event Zero 46 Abbildung 14: Modellierung mit dem StreamBase Studio 48 Abbildung 15: Elemente für die Entwicklung mit Open ESB IEP 50 Abbildung 16: Modellierung mit dem Vitria M3O Query Modeler 52 Abbildung 17: Beispielhafte Vitria M3O Operations Book s 53 Abbildung 18: Entwicklung mit dem RTM Analyzer 55 Abbildung 19: Exemplarisches RTM Analyzer 56 Abbildung 20: Beispielhafter Informatica Rulepoint Alert Manager 58 Abbildung 21: Modellierung mit Starview 60 Abbildung 22: Entwicklung mit Microsoft StreamInsight 62 Abbildung 23: Exemplarische West Global Vantify s 66 Abbildung 24: Entwicklung mit IBM WebSphere Business Events 68 Abbildung 25: Beispielhafte Diagramme in IBM WebSphere Business Space 69 Abbildung 26: Modellierung mit dem SL RTView Builder 71 4 Fraunhofer IAO

6 1 Einführung Die klassische Analyse von Unternehmensdaten erfolgt in der Regel rückwirkend. In der Vergangenheit aufgelaufene Daten werden zum Beispiel aus einem Data Warehouse selektiert und auf die gewünschten Fragestellungen hin untersucht. Anhand der Ergebnisse können dann entsprechende Konsequenzen gezogen werden (vgl. [1]). Aufgrund seiner Vergangenheitsbezogenheit ist dieses Vorgehen oft unbefriedigend, da eine zeitnahe Reaktion auf aktuelle Begebenheiten meistens unmöglich ist. In vielen Anwendungsfällen ist es allerdings erforderlich, zeitkritische Daten in Echtzeit zu verarbeiten, um so auf Ereignisse im Unternehmen und in der Umwelt rasch reagieren zu können. Beispiele hierfür sind Aktienhandel, Betrugserkennung, zeitkritische Überwachungssysteme oder Sensornetzwerke mit RFID (vgl. [2]). Die Echtzeitverarbeitung von relevanten Ereignissen, das so genannte Event Processing 1, wird zwar schon seit hrzehnten praktiziert, allerdings wurden hierfür häufig selbst entwickelte Skripte eingesetzt, denen es an Flexibilität und Standardisierung mangelte (vgl. [1] und [2]). Demgegenüber zielt das in den letzten hren entstandene und stetig wachsende Fachgebiet des Complex Event Processing (vgl. insbesondere [3]) auf eine kontinuierliche und unmittelbare Verarbeitung einer Vielzahl an Ereignissen ab, die methodisch und technologisch sowie durch den Einsatz dedizierter Softwaretools unterstützt wird, so dass die notwendige Systematik im Einsatz möglich wird (vgl. [4]). Im Zuge der Digitalisierung und Vernetzung in der heutigen Zeit sowie einer einhergehenden Explosion von in Echtzeit zu verarbeitenden Datenmengen spielen solche Softwaresysteme eine immer wichtigere Rolle (vgl. [5]). Dies unterstreicht nicht zuletzt die Gründung der Event Processing Technical Society (EPTS) 2 zu Beginn des hres 2008, der die meisten Anbieter von Event Processing Tools sowie Einzelpersonen aus dem Forschungsumfeld angehören und die sich für ein gemeinsames Verständnis, die Entwicklung von Standards und für den Wissenstransfer in diesem Fachgebiet einsetzt (vgl. [6]). Mehrere ausgereifte Produkte sind bereits auf dem Markt verfügbar, welche für das Real-Time Monitoring in verschiedenen Anwendungen geeignet sind. In [7] wird diesen Event Processing Tools mit einem Verweis auf Analystenberichte ein 1 Im Text werden die in der Fachliteratur gebräuchlichen englischen Begriffe verwendet 2 Weitere Informationen zur Event Processing Technical Society (EPTS) unter Fraunhofer IAO 5

7 1 Einführung schnelles Wachstum und noch immer nur ein Bruchteil der potentiellen Nutzung im Markt attestiert. Die vorliegende Marktübersicht liefert einen Einblick in die Funktionalitäten dieser Produkte. Die Marktübersicht entstand im Rahmen des vom Bundesministerium für Wirtschaft und Technologie (BMWi) geförderten Verbundprojekts ic-rfid (intelligentes Catering mittels Radio Frequency IDentification), dessen Forschungsgegenstand die Integration und Echtzeitsteuerung einer unternehmensübergreifenden Prozesskette am Beispiel Luftfahrtcatering mit Hilfe der RFID-Technologie umfasste. Ein wesentlicher Bestandteil des Projekts war die Konzeption und Realisierung eines Real-Time Monitoring s, welches den Prozessfluss von mit RFID-Tags ausgerüsteten Flugzeugtrolleys visualisiert und bei Vorliegen von Engpässen automatisierte Benachrichtigungen unmittelbar in Echtzeit auslöst. Die folgenden Abschnitte dieses Kapitels behandeln die Grundlagen von Ereignis-gesteuerten Architekturen (Event-Driven Architectures, EDA) und Event Processing sowie die wesentlichen Komponenten von Event Processing Tools, um das Verständnis für die zugrundeliegende Thematik zu vertiefen. Im zweiten Kapitel wird zunächst die Methodik bei der Erstellung der Marktübersicht erläutert und das verwendete Kriterienraster definiert. Dieses wird anschließend herangezogen, um die derzeit auf dem Markt befindlichen Produkte einzeln und im Detail zu beschreiben. Als Abschluss folgt eine Zusammenfassung dieser Produkte und ihrer Funktionalitäten in tabellarischer Form. Das letzte Kapitel enthält schließlich ein Fazit mit einer Darstellung der wesentlichen Erkenntnisse der vorliegenden Marktübersicht. 1.1 Grundlagen Ein Softwaresystem mit einer Ereignis-gesteuerten Architektur (Event-Driven Architecture, EDA) unterliegt einem Softwarearchitekturmuster mit lose gekoppelten Komponenten, die lediglich mit Hilfe von Ereignissen (Events) in einer einfachgerichteten Weise miteinander kommunizieren, ohne dabei Wissen über das Gesamtsystem zu besitzen (vgl. [5]). Ein Event bezeichnet hierbei alles, was geschieht oder von dem erwartet wird, dass es geschieht. Für eine automatisierte Verarbeitung muss ein Event in Form eines Eventobjekts vorliegen, durch welches es in elektronischer Form repräsentiert wird. Beispiele hierfür sind ein Bestellungseingang, eine Aktienwertänderung oder der Eingang eines Lesevorgangs eines RFID-Sensors (vgl. [8]). 6 Fraunhofer IAO

8 1 Einführung Neben dem Eventobjekt, das konzeptionell lediglich eine Benachrichtigung darstellt und keine direkte Anfrage oder Anweisung, besitzt eine EDA noch folgende Elemente (vgl. [6], [7] und [8]): Eventquelle (Event Source, auch Event Emitter oder Event Producer) 3 : Eine Komponente, die aufgrund von erkannten Informationen Eventobjekte erzeugt und diese an einen angebundenen Eventkanal überreicht, wird als Eventquelle bezeichnet. Diese kennt den Empfänger des Eventobjekts, die so genannte Eventsenke, nicht, weiß sogar nicht einmal, ob überhaupt eine existiert, und wenn doch, wie diese das Eventobjekt nutzt oder weiterverarbeitet. Damit wird eine äußerst lose Kopplung des Systems realisiert. Eine bedeutende Eigenschaft ist zudem das aktive Auslösen eines Events durch die Eventquelle unmittelbar zu dem Zeitpunkt seines Auftretens, ohne dass dies von einer anderen Komponente angefragt wurde. Eventkanal (Event Channel, auch Event Connection, Event Pathway oder Event Topic): Das Medium, über welches Events von Eventquellen zu Eventsenken verteilt werden, wird Eventkanal genannt. Dieser kann verschiedene Eventtypen übertragen und auch mehrere Eventquellen und Eventsenken verbinden, so dass einer oder mehrere Eventströme über einen Eventkanal verlaufen können. Zudem ist es möglich, dass ein Event von einer Eventquelle gleichzeitig an mehrere Eventsenken verteilt wird. Das Wissen über die korrekte Verteilung der Events liegt ausschließlich im Eventkanal. Eventsenke (Event Sink, auch Event Consumer): Eine Eventsenke ist eine Komponente, die Events über den Eventkanal empfängt und aufgrund seiner Fachlogik über die Weiterverarbeitung dieser Events entscheidet. Eine besondere Eigenschaft liegt dabei darin, dass beim Empfang des Events durch die Eventsenke dieses auch unmittelbar weiterverarbeitet und beispielsweise die sofortige Ausführung einer Operation ausgelöst wird. Somit sind Reaktionen in Echtzeit möglich. Ein Softwaresystem, das einer EDA unterliegt, kann mehrere Eventquellen, Eventkanäle und Eventsenken besitzen. Zudem kann eine Systemkomponente auch gleichzeitig die Rolle einer Eventquelle und einer Eventsenke einnehmen. Dies trifft insbesondere auf die später erläuterten Event Processing-Komponente zu. Durch die lose Kopplung innerhalb einer EDA können neue Event- 3 Im englischen Sprachgebrauch werden verschiedene Synonyme benutzt. Bei den englischen Begriffen beziehen wir uns in erster Linie auf das herausgegebene Glossar der EPTS (vgl. [8]) und deren jeweils erste Nennungen. Fraunhofer IAO 7

9 1 Einführung quellen und Eventsenken hinzugefügt werden, ohne dass hierfür das Gesamtsystem angepasst werden muss. Zusammenfassend besitzt eine EDA konzeptionell folgende Eigenschaften (vgl. [5] und [6]): Informationen werden durch das Versenden von Eventobjekten berichtet. Dies geschieht immer zu den Zeitpunkten, an denen das entsprechende Event auch eingetreten ist. Die Kommunikation erfolgt nach dem Push-Prinzip. Im Gegensatz zum Pull-Prinzip, bei dem der Empfänger der Nachricht diese zunächst beim Sender anfragt, geht hier die Initiative von der Eventquelle selbst aus. Reaktionen auf Events erfolgen unmittelbar und in Echtzeit, sobald das entsprechende Event eingetroffen ist. Die Kommunikation verläuft asynchron und in einfachgerichteter Weise. Wenn die Eventquelle ein Eventobjekt gesendet hat, fährt es mit den weiteren Operationen fort, ohne das Event weiterzuverfolgen oder auf eine Antwort der Eventsenke zu warten. Der Austausch von Eventobjekten erfolgt nach dem Publish/Subscribe- Prinzip. Typischerweise publiziert (Publish) eine Eventquelle Events an einen Eventkanal (Middleware). Beliebige Eventsenken können einen bestimmten Eventtyp abonnieren (Subscribe) und werden bei Eintreffen eines Events von der Middleware benachrichtigt, um dieses abzuholen. Ein Eventobjekt beinhaltet lediglich Informationen über das eingetretene Event und enthält somit keine Anweisungen oder Operationen, die bei der Eventsenke ausgeführt werden sollen. Letztere entscheidet selbst, welche Aktion als Reaktion auf das Eintreffen des Events ausgeführt werden soll. Diese Eigenschaften entsprechen der reinen Form der EDA, wobei in der Praxis auch Mischformen möglich sind, beispielsweise wenn das Eventobjekt bereits explizite Anweisungen für die Eventsenke enthält oder direkt an eine bestimmte Eventsenke adressiert ist. Viel wichtiger ist allerdings die Tatsache, dass durch den Einsatz Event-basierter Systeme verschiedene Geschäftsprobleme lösbar sind, deren Anforderungen in einer komplexen Fachlogik, großen Datenvolumina, geringen Latenzzeiten, hoher Skalierbarkeit und erforderlicher Agilität bzw. einfacher Änderbarkeit der Anwendung bestehen (vgl. [6]). Dies wird mit Hilfe einer leistungsstarken Technologie realisiert, die sich durch die Echtzeitverarbeitung einer Vielzahl von Events und deren Beziehungen un- 8 Fraunhofer IAO

10 1 Einführung tereinander auszeichnet und als Complex Event Processing bzw. Event Stream Processing bezeichnet wird. Hierbei werden auf der Grundlage vordefinierter Regeln (Event Processing Rules) eingehende Events ausgewertet und weiterverarbeitet, so dass entweder mit einer deduktiven Regel ein neues Event generiert wird, welches lediglich eine Abstraktion der eingegangenen Events darstellt, oder mit einer reaktiven Regel durch ein Event eine unmittelbare Reaktion ausgelöst wird. Beispiele für letztere sind etwa der Kauf einer bestimmten Anzahl Aktien, sobald der Kurs den gewünschten Kaufpreis unterschritten hat oder die sofortige Benachrichtigung eines Verantwortlichen bei einem Transportfehler eines mit einem RFID- Tag ausgerüsteten Containers. Als weitere typische Reaktion kann die unmittelbare Interaktion mit Geschäftsprozessen genannt werden (vgl. [4]). Wie bereits erwähnt, nimmt hier die Event Processing-Komponente sowohl die Rolle der Eventsenke ein, da sie Events empfängt und verarbeitet, als auch die der Eventquelle, wenn neue Events generiert werden. Der grundlegende Unterschied zu traditionellen Analysesystemen aus dem Datenbankumfeld ist hierbei die Tatsache, dass eingehende Events während ihres Passierens kontinuierlich anhand der Event Processing Rules ausgewertet werden und Reaktionen unmittelbar in Echtzeit angestoßen werden können (Push- Prinzip). Somit werden anstatt einmaliger Anfragen zu diskreten Zeitpunkten gegen eine endliche Datenmenge hier durchgehende Anfragen gegen eine (konzeptionell) unbegrenzte Eventmenge ausgeführt (vgl. [4]). Man unterscheidet grundsätzlich drei verschiedene Arten von Event Processing (vgl. [9]): Simple Event Processing: Hierbei wird auf ein bestimmtes Einzelevent eine vordefinierte Reaktion direkt ausgelöst, um Verzögerungszeiten zu vermeiden. Wenn beispielsweise ein Lagerverwaltungssystem bei zu niedrigem Bestand eines Artikels ein entsprechendes Event versendet, kann darauf unmittelbar mit der Initiierung eines zugehörigen Bestellungsprozesses und mit einer Nachricht an einen Verantwortlichen reagiert werden. Event Stream Processing (ESP): Das System analysiert einen oder mehrere zeitlich geordnete Eventströme (Event Streams) im Zeitablauf und versucht dabei, bedeutsame Events und Relationen zwischen Events in diesen zu identifizieren und darauf zu reagieren. Klassische Beispiele für ESP sind etwa der automatisierte Handel mit Wertpapieren, bei dem ein Handelssystem die Aktienkurse im Zeitablauf analysiert und gegebenenfalls automatisierte Kauf- oder Verkaufsorders platziert, sowie die Analyse von RFID-Eventströmen, bei der als Reaktion auf falsche Transportwege beispielsweise entsprechende Alarme versendet werden können. Fraunhofer IAO 9

11 1 Einführung Complex Event Processing (CEP): Komplexe Events (Complex Events) sind Mengen von Events, die in einem meist temporalen, kausalen oder räumlichen Zusammenhang stehen, aber nicht zwingend vom gleichen Eventtyp sein müssen. Das System analysiert eine so genannte Eventwolke (Event Cloud), die aus ungeordneten Events besteht, im Hinblick auf bestimmte Eventmuster (Event Patterns) und löst gegebenenfalls Reaktionen aus. Ein Beispiel für CEP ist ein Intrusion Detection System, das auf Unstimmigkeiten in laufenden Netzwerkzugriffen reagieren kann, indem es Events an verschiedenen Stellen im Netzwerk registriert und untereinander in Beziehung setzt. Ein weiteres Beispiel ist etwa die Betrugserkennung bei Kreditkartenbuchungen. Event Stream Processing (ESP) und Complex Event Processing (CEP) bauen bei der Analyse von eingehenden Events im Hinblick auf Event Patterns auf ähnlichen Konzepten auf, wobei ESP stärker auf kontinuierliche und (meist zeitlich) geordnete Eventströme abzielt, während CEP eher komplexe Operationen über mehrere Events und Eventtypen im Fokus hat. Eine klare konzeptionelle Abgrenzung ist hierbei allerdings kaum möglich (vgl. [6]). Das Event Processing wird durch die drei Grundschritte Erkennen, Verarbeiten und Reagieren charakterisiert, so dass sich daraus drei logische Strukturierungsschichten ergeben: Eventquellen, Eventverarbeitung und Eventbehandlung (vgl. [6]). Diese werden in Abbildung 1 mit entsprechenden Beispielen veranschaulicht (in Anlehnung an [1], [6] und [7]). Abbildung 1: Logische Strukturierungsschichten beim Event Processing Eventquellen Geschäftsprozesse Eventverarbeitung Event Processing Agent Eventmodelle Eventregeln Eventbehandlung s Datenbanken Sensoren Applikationen In-Adapter Event Processing Engine Verarbeitung von Events Erkennung von Event Patterns Out-Adapter Nachrichten Applikationen Datenbanken Jedes Event wird durch eine Eventquelle generiert und in das System eingebracht. Hierbei kann es sich beispielsweise um eine Anwendung, verschiedene Sensoren, ein Datenbanksystem oder einen Geschäftsprozess handeln. Weitere Beispiele sind RSS-Feeds, Aktienkursticker oder Benutzerinteraktionen. Aufgrund der Vielfältigkeit der möglichen Eventquellen werden die Eventobjekte im Regelfall auch durch unterschiedliche Eventtypen repräsentiert, so dass diverse 10 Fraunhofer IAO

12 1 Einführung Adapter erforderlich sind, um diese in der Eventverarbeitungsschicht empfangen zu können (vgl. [1], [6] und [7]). Den Kern von Event Processing-Systemen stellt in der Eventverarbeitungsschicht der so genannte Event Processing Agent (auch Event Processing Component oder Event Mediator) dar, in dem die Eventmodelle der zu verarbeitenden Events, die Event Processing Rules sowie die Event Processing Engine zur kontinuierlichen Interpretation dieser Regeln enthalten sind. Hier werden die übergebenen Events z.b. durch Filterung oder Transformation weiterverarbeitet und im Hinblick auf vordefinierte Event Patterns analysiert (vgl. [6]). Event Patterns beinhalten beispielsweise logische Operationen (Konjunktionen, Disjunktionen oder Negationen), Kardinalitäten, fachliche Korrelationen oder zeitliche Beziehungen zwischen verschiedenen Events. Um endliche Eventmengen analysieren zu können, werden zeitliche oder quantitative Fenster über den eingehenden Events definiert, z.b. die Events der letzten 2 Minuten oder die letzten 20 Events, und nur die aktuell in einem solchen Fenster befindlichen Events in die Auswertung einbezogen (vgl. [4], [6] und [10]). Bei der Verarbeitung können aus einzelnen atomaren Events (Raw Events) abgeleitete Events (Derived Events) erzeugt werden. Durch Abstraktionen mit Hilfe verschiedener Operationen, z.b. Durchschnittsberechnungen, können aggregierte Events (Composite Events) entstehen, welche die zugrundeliegenden Raw Events zusammenfassen, oder auch komplexe Events (Complex Events), welche die zugrundeliegenden Raw Events nicht beinhalten, sondern anhand von komplexeren Operationen neue Erkenntnisse aus diesen ziehen (vgl. [6]). Ein Beispiel für ein Complex Event ist etwa ein gemeldeter Betrugsversuch bei Kreditkartenbuchungen, welcher sich aus verschiedenen Abbuchungs- oder Bezahlungsevents und deren zeitlichen und räumlichen Abständen untereinander zusammensetzt. Sobald eine definierte Event Processing Rule im Hinblick auf ein vorliegendes Event Pattern greift, wird in der Eventverarbeitungsschicht ein neues Event ausgelöst. Dieses wird entweder für eine Weiterverarbeitung in der Event Processing Engine verwendet (deduktive Regel), was in Abbildung 1 durch den unteren Eventfluss zurück in die Event Processing Engine dargestellt wird, oder führt zu einer Reaktion durch eine Komponente der Eventbehandlungsschicht (reaktive Regel). Die Modellierung der entsprechenden Event Processing Rules wird mittels einer Event Processing Language (EPL) vorgenommen. Bisher hat sich hierfür allerdings noch kein Standard herausgebildet, so dass jede Engine eine spezifische EPL verwendet (vgl. [2]). Fraunhofer IAO 11

13 1 Einführung Grob lassen sich die verschiedenen Event Processing Languages zumindest in drei Gruppen kategorisieren (vgl. [4] und [7]): Datenstromorientierte Sprachen: Diese Sprachen basieren auf der bekannten Datenbankanfragesprache SQL (Structured Query Language) und verfolgen das Prinzip, dass Datenströme, in denen Events als Datensätze enthalten sind, in Relationen transformiert werden, auf denen dann Anfragen zu jedem Zeitpunkt einer diskreten Zeitachse ausgeführt werden. Die Anfrageergebnisse werden anschließend wieder in einen Datenstrom überführt. Regelbasierte Sprachen: Der Ursprung dieser Sprachen liegt in Systemen für das Business Rule Management. Sie arbeiten meist nach dem Prinzip»Event Condition Action«, d.h. es wird ein Event spezifiziert, das die Ausführung der Regel triggert, welche bei Vorliegen einer wahren Bedingung eine vordefinierte Aktion unmittelbar auslöst. Imperative Sprachen: Hierbei handelt es sich um spezifische Skriptsprachen, die eigens für das Event Processing entwickelt wurden. Häufig werden Event Processing-Systeme so entworfen, dass mehrere Event Processing Agents in der Eventverarbeitungsschicht zusammenarbeiten. Auf diese Weise lässt sich eine besser skalierte Anwendung realisieren, die auch physikalisch auf verschiedene Server verteilt werden kann (vgl. [6]). Durch den Austausch von Events zwischen den verschiedenen Event Processing Agents entsteht ein so genanntes Event Processing Network (vgl. [3]). Hierfür werden die Regeln und die Eventmodelle in geeigneter Weise auf die verschiedenen Event Processing Agents verteilt. Um die Events, die in der Eventverarbeitungsschicht generiert werden, auch für die Komponenten der Eventbehandlungsschicht verwertbar zu machen, sind wiederum diverse Adapter notwendig, um die erforderlichen Eventtypen zu erhalten (siehe Abbildung 1). In der Eventbehandlungsschicht werden schließlich die Aktionen in Echtzeit ausgeführt, um das gewünschte Verhalten zu realisieren. Hierbei kann es sich etwa um das Versenden von Warnungen an verantwortliche Personen, das Auslösen von Alarmen, den Aufruf von Diensten, eine dynamische Anpassung von Geschäftsprozessen oder die Ausführung von Operationen in einer Anwendung handeln. 12 Fraunhofer IAO

14 1 Einführung Mit solchen Event Processing-Systemen, die in diesem Abschnitt im Detail vorgestellt wurden, können viele Herausforderungen bewältigt werden. Nach [7] lässt sich die Motivation für die Nutzung von Event Processing-Systemen grob in folgende Kategorien einordnen: Überwachung: Feststellung von unerwünschtem Verhalten von Systemen oder Prozessen und sofortiges Auslösen von Benachrichtigungen, wobei die Reaktionen den Nachrichtenempfängern überlassen werden Informationsbereitstellung: personalisierte Übermittlung von Informationen, d.h. die richtige Information zur richtigen Zeit in der richtigen Granularität an den richtigen Abnehmer Dynamisches Betriebsverhalten: sofortiges Auslösen von Geschäftstransaktionen auf Basis von eingehenden Events Aktive Diagnostik: Problemdiagnose durch Auswertung von Symptomen als eingehende Events Prognostizierung: Treffen von Vorhersagen auf Basis der bisher eingegangenen Events und Verhinderung von vorausgesagten Events oder zumindest Abschwächung ihrer Wirkung Bei Vorliegen eines oder mehrerer dieser Beweggründe lohnt sich möglicherweise der Einsatz von Event Processing Tools, deren Komponenten nachfolgend allgemein beleuchtet werden. 1.2 Komponenten von Event Processing Tools Dedizierte Event Processing Tools ermöglichen die Umsetzung eines Event Processing-Systems, wie es im vorherigen Abschnitt beschrieben wurde. Solche Tools bestehen aus verschiedenen Komponenten auf der Entwicklungs- und Ausführungsebene, die nachfolgend aufgelistet und erläutert werden. Dabei werden je nach Produkt mehr oder weniger dieser Komponenten und in unterschiedlichen Ausprägungen angeboten. Event Processing Engine: Der Kern jedes Event Processing-Systems auf Ausführungsebene ist die Event Processing Engine, mit welcher das Complex Event Processing bzw. Event Stream Processing letztlich realisiert wird. Diese versteht die systemeigene Event Processing Language (EPL), mittels derer die Event Processing Rules definiert werden. Bei vielen Produkten sind besonders hohe Verarbeitungsgeschwindigkeiten und die Möglichkeit der Skalierung von Event Processing Engines für eine Hochverfügbarkeit vorhanden. Fraunhofer IAO 13

15 1 Einführung Adapter: Viele Event Processing Tools liefern bereits eine unterschiedliche Anzahl an vorgefertigten Adaptern mit, damit die Event Processing Engine mit den Eventquellen und den Komponenten der Eventbehandlung kommunizieren kann. Beispiele sind etwa Adapter für verschiedene Messaging Bus-Systeme, Datenbanken, Web Service-Schnittstellen, Dateien oder spezielle Anwendungssysteme. Meist besteht auch die Möglichkeit, eigene Adapter mittels einer Programmierschnittstelle (Application Programming Interface, API) selbst zu entwickeln. Event Monitor: Die meisten Produkte beinhalten eine Konsole zur einfachen Anzeige der ablaufenden Events, zum Beispiel in Form eines Logs, so dass eine Echtzeitverfolgung zur Laufzeit möglich ist. : Mit Hilfe von dedizierten Visualisierungsanwendungen können Events auch graphisch dargestellt werden. Dafür stehen bei vielen Event Processing Tools in der Regel eine Vielzahl an unterschiedlichen Diagrammtypen zur Verfügung, die mit Events verknüpft werden können und zur Laufzeit per Push-Prinzip aktualisiert werden. Gebräuchlich sind unter anderem Zähler, Torten-, Balken- und Liniendiagramme, Tachometer, Ampeln und Fortschrittsbalken. Der Benutzer kann sich auf diese Weise schnell eine Übersicht über das derzeit ablaufende Geschehen verschaffen. Häufig kann der aktuelle Status auch mit historischen Daten aus Datenbanken angereichert werden, um zusätzliche Informationen zu gewinnen. Allerdings enthalten nicht alle Event Processing Tools derartige Visualisierungskomponenten. In diesen Fällen kann eventuell eine vorgefertigte applikation eines anderen Anbieters eingesetzt werden, oder die Events werden an eigenentwickelte Lösungen zur Visualisierung übergeben. Entwicklungs- und/oder Modellierungsumgebung: Viele auf dem Markt angebotenen Event Processing Tools enthalten Entwicklungsumgebungen für die Formulierung der Event Processing Rules in der jeweiligen Event Processing Language (EPL) der verwendeten Laufzeitumgebung. Teilweise können Regeln sogar graphisch modelliert werden, welche dann intern in die EPL überführt werden. Einige Lösungen setzen ausschließlich auf die Code-basierte Definition von Regeln mittels einer EPL, einige bieten nur ein graphisches Interface für diesen Zweck an, manche Produkte beides. Auch für die Gestaltung von s werden zum Teil Modellierungstools bereitgestellt, mit denen die Platzierung der Visualisierungselemente und die Verknüpfung ihrer Werte mit den entsprechenden Events und deren Attributen benutzerfreundlich durchgeführt werden können. Auswertungs- und Analysetools: Mit Hilfe von Reportgeneratoren können Auswertungen von Events erzeugt werden. Teilweise sehen Event Processing Tools auch entsprechende Event Datenbanken vor, in denen 14 Fraunhofer IAO

16 1 Einführung eine Historie relevanter Events abgelegt werden kann, um ausführliche Analysen durchführen zu können. Erzeugte Reports können zum Teil auf Remotesystemen oder als Dokument im PDF- oder HTML-Format exportiert werden. Nicht alle Lösungen bieten diese Komponente an, so dass die Events von der Event Processing Engine an externe Applikationen übergeben werden müssen, wenn derartige Analysen durchgeführt werden sollen. Enterprise Service Bus (ESB): Mit Hilfe eines Enterprise Service Bus (ESB) können Nachrichten zwischen Quelle und Ziel transportiert, transformiert und geroutet werden. Dies können innerhalb einer EDA beispielsweise Events oder von der Event Processing Engine ausgelöste Reaktionen sein, aber auch Web Service Aufrufe aus einem automatisierten Geschäftsprozess heraus. Viele Event Processing Tools sehen zumindest die Anbindung an einen ESB vor, um Events zu lesen und abzusetzen. Manche Lösungen bieten sogar eine ESB-Implementation im Rahmen des Produktes an bzw. offerieren diese in ihrer Produktpalette. Die Anbindung an einen ESB ist für das Event Processing jedoch nicht zwingend notwendig, denn Events können auch direkt (zum Beispiel mittels eines selbstentwickelten Adapters) an die Event Processing Engine oder eine Eventsenke gesendet werden. Wie bereits erwähnt, sind je nach Produkt mehr oder weniger dieser Komponenten in verschiedenen Ausprägungen vorhanden. Die Marktübersicht im nächsten Kapitel liefert einen Überblick über die Funktionalitäten der zur Zeit am Markt befindlichen Event Processing Tools. Dabei werden sowohl kommerzielle Produkte betrachtet, als auch konkurrenzfähige Open Source-Produkte. Fraunhofer IAO 15