Marktübersicht Real-Time Monitoring Software - IAO-Wiki

Transcription

F R A U N H O F E R - I N S T I T U T F Ü R ar b eits w irts c haft un d or g anisation iao
Krešimir Vidačković, Thomas Renner, Sascha Rex
Marktübersicht
Real-Time Monitoring Software
Event Processing Tools im Überblick
Mit Complex Event Processing (CEP) und Event Stream Processing (ESP) stehen
neue Technologien zur Verfügung, mittels derer das Real-Time Monitoring
signifikanter Ereignisse und deren Beziehungen untereinander mit hohen
Verarbeitungsgeschwindigkeiten ermöglicht wird. Somit wird das Auslösen
unmittelbarer Reaktionen auf bestimmte Ereignisse und kritische Zustände nach
dem Push-Prinzip realisierbar.
Die vorliegende Marktübersicht liefert einen Einblick in die Funktionalitäten der
derzeit am Markt verfügbaren Event Processing Tools. Diese bieten neben der
reinen Ereignisverarbeitung in Echtzeit meist auch vielfältige Adapter zur Integration
in die vorliegende IT-Landschaft, Modellierungs- und Analysetools sowie
Dashboards zur visuellen Darstellung. Neben kommerziellen Produkten werden
auch ausgereifte Open Source-Lösungen betrachtet.
ISBN 978-3-8396-0185-3
9 783 839 60 1853
Fraunhofer Verlag
Marktübersicht Real-Time Monitoring Software
Aufgrund der stetig wachsenden Komplexität und Dynamik in der heutigen Zeit
erfordern viele Unternehmensanwendungen und Prozesse ein hohes Maß an
Transparenz und Agilität. Zudem steigen die Anforderungen nach einer
kontinuierlichen Verarbeitung von internen und externen Daten in Echtzeit und
mit zunehmenden Datenmengen.
Krešimir Vidačković
Thomas Renner
Sascha Rex
Autoren
Kontaktadresse
Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO
Nobelstraße 12
70569 Stuttgart
Telefon 0711 970-5120
Telefax 0711 970-5111
E-Mail [email protected]
URL
http://www.e-business.iao.fraunhofer.de
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 http://dnb.d-nb.de abrufbar.
ISBN: 978-3-8396-0185-3
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 800469, 70504 Stuttgart
Nobelstraße 12, 70569 Stuttgart
Telefon 0711 970-2500
Telefax 0711 970-2508
E-Mail [email protected]
URL
http://verlag.fraunhofer.de
© 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
Inhalt
Abbildungen
4 1 1.1 1.2 Einführung
Grundlagen
Komponenten von Event Processing Tools
5 6 13 2 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 2.3.9 2.3.10 2.3.11 2.3.12 2.3.13 2.3.14 2.3.15 2.3.16 2.3.17 2.3.18 2.3.19 2.3.20 2.3.21 2.4 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
16 16 16 18 20 23 26 29 31 33 36 38 41 44 47 49 51 54 57 59 61 63 65 67 70 72 3 Fazit
76 Abkürzungen
78 Referenzen
80 Fraunhofer IAO
3
Abbildungen
Abbildung 1: Logische Strukturierungsschichten beim Event Processing
Abbildung 2: Modellierung mit dem Sybase Aleri Studio
Abbildung 3: Entwicklung mit dem Progress Apama Studio
Abbildung 4: Modellierung mit dem Progress Apama Dashboard Builder
Abbildung 5: Exemplarisches TIBCO Spotfire Dashboard
Abbildung 6: Modellierung mit UC4 Decision
Abbildung 7: Beispielhafte Event Tunnel-Darstellung mit UC4 Insight
Abbildung 8: Entwicklung mit JBoss Drools
Abbildung 9: Modellierung mit der Oracle EDA Suite
Abbildung 10: Exemplarisches Oracle BAM Dashboard
Abbildung 11: Beispielhaftes EsperHQ Dashboard
Abbildung 12: Event Zero Administrations- und Entwicklungstool
Abbildung 13: Beispielhaftes Event Zero Dashboard
Abbildung 14: Modellierung mit dem StreamBase Studio
Abbildung 15: Elemente für die Entwicklung mit Open ESB IEP
Abbildung 16: Modellierung mit dem Vitria M3O Query Modeler
Abbildung 17: Beispielhafte Vitria M3O Operations Book Dashboards
Abbildung 18: Entwicklung mit dem RTM Analyzer
Abbildung 19: Exemplarisches RTM Analyzer Dashboard
Abbildung 20: Beispielhafter Informatica Rulepoint Alert Manager
Abbildung 21: Modellierung mit Starview
Abbildung 22: Entwicklung mit Microsoft StreamInsight
Abbildung 23: Exemplarische West Global Vantify Dashboards
Abbildung 24: Entwicklung mit IBM WebSphere Business Events
Abbildung 25: Beispielhafte Diagramme in IBM WebSphere Business Space
Abbildung 26: Modellierung mit dem SL RTView Builder
4
Fraunhofer IAO
10 22 24 25 27 34 35 37 39 40 42 45 46 48 50 52 53 55 56 58 60 62 66 68 69 71 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
Processing1, wird zwar schon seit Jahrzehnten 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 Jahren 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 Jahres 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
2
Im Text werden die in der Fachliteratur gebräuchlichen englischen Begriffe verwendet
Weitere Informationen zur Event Processing Technical Society (EPTS) unter http://www.ep-ts.com
Fraunhofer IAO
5
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 Dashboards, 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
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
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/SubscribePrinzip. 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
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 RFIDTag 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 (PushPrinzip). 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
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]).
Eventquellen
Eventverarbeitung
Eventbehandlung
Geschäftsprozesse
Event Processing Agent
Dashboards
Datenbanken
Sensoren
Applikationen
…
In-Adapter
Eventmodelle
Eventregeln
Event Processing Engine
• Verarbeitung
von Events
• Erkennung von
Event Patterns
Out-Adapter
Abbildung 1: Logische Strukturierungsschichten beim Event
Processing
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
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
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
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
1
14
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.
•
Dashboard: 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 Dashboardapplikation 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 Dashboards 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
Fraunhofer IAO
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
2
Marktübersicht
In diesem Kapitel werden die derzeit bedeutsamsten Event Processing Tools in
einer Marktübersicht gegenübergestellt. Zunächst wird die Vorgehensweise bei
der Erstellung der Marktübersicht erläutert und das verwendete Kriterienraster
definiert. Anschließend werden die am Markt verfügbaren Produkte einzeln im
Detail beschrieben und zum Abschluss des Kapitels in einer tabellarischen Übersicht zusammengefasst.
2.1
Vorgehensweise bei der Erstellung der Marktübersicht
Die verfügbaren Produkte für das Event Processing wurden durch OnlineRecherche und durch das Studium einschlägiger Fachliteratur identifiziert. Anschließend wurden diese bezüglich der in Abschnitt 1.2 behandelten Komponenten und insbesondere des im folgenden Abschnitt spezifizierten
Kriterienrasters untersucht. Die Informationen wurden im Wesentlichen mittels
Online-Recherche auf den Webseiten der Anbieter zusammengetragen und
zum Teil durch das Studium der verfügbaren Dokumentation ergänzt.
Eine detaillierte Evaluation der Produkte mittels Testinstallationen oder ausführlicher Befragungen der Anbieter war im Rahmen dieser Betrachtung nicht vorgesehen und wurde daher auch ausdrücklich nicht durchgeführt. Informationen, die nach intensiver Online-Recherche nicht verfügbar waren, bleiben somit
unberücksichtigt.
Die Erstellung der Marktübersicht erfolgte im Zeitraum von Januar bis März
2010. Von August bis Oktober 2010 wurde die Marktübersicht überarbeitet
und den Produktanbietern zur Durchsicht zugesendet.
2.2
Kriterienraster
Die Darstellung orientiert sich an folgendem Kriterienraster, das größtenteils auf
den in Abschnitt 1.2 prinzipiell erläuterten Komponenten von Event Processing
Tools basiert:
•
Allgemeine Daten zum Anbieter und Produkt:
-
•
16
Name des Anbieters
Name des Produktes
Website
Vom Produkt unterstützte Betriebssysteme
Fraunhofer IAO
2
Marktübersicht
•
Art von Softwarelizenz, der das Produkt unterliegt (kommerziell oder
Open Source)
•
Softwareart des Produktes mit der Unterscheidung in Event Processing
Engine und Komplettsystem, wobei sich letzteres auf das Vorhandensein
zusätzlicher Komponenten über die reine Eventverarbeitung hinaus bezieht (siehe auch Abschnitt 1.2)
•
Branchenfokus, sofern ein solcher explizit genannt wird
•
Verbreitung des Produktes, sofern dazu eine Angabe gemacht werden
kann
•
Referenzkunden, sofern diese genannt werden (gegebenenfalls auszugsweise), wobei vorrangig Unternehmen im deutschsprachigen Raum
aufgeführt werden
•
Vorhandensein einer Engine für Event Stream Processing und/oder
Complex Event Processing: in der textuellen Beschreibung werden diese
Engines meist im Detail beschrieben, wobei auch Angaben zur Skalierbarkeit und Verarbeitungsgeschwindigkeit gemacht werden, falls dies
möglich ist; ein besonderer Augenmerk wurde auch auf Art und Umfang der mitgelieferten Adapter gelegt, von denen die Wichtigsten aufgeführt werden
•
Sprachtyp der Event Processing Language (EPL), nach den im vorhergehenden Abschnitt genannten drei Kategorien:
-
Datenstromorientiert
Regelbasiert
Imperativ
•
Vorhandensein einer mit den üblichen Funktionalitäten ausgestatteten
integrierten Entwicklungsumgebung (Integrated Development Environment, IDE) für die Entwicklung von Event Processing Rules in einer EPL
•
Vorhandensein einer Möglichkeit für die graphische Modellierung von
Event Processing Rules: das Kriterium gilt als erfüllt, wenn mindestens
entsprechende Assistenten zur Regelerstellung vorhanden sind; manche
Produkte sehen aber auch ausgereifte graphische Modellierungstools
(beispielsweise mit Drag-and-Drop-Funktionalität) vor, was entsprechend
in der textuellen Beschreibung erwähnt wird
•
Möglichkeiten für Debugging oder Simulation: das Kriterium gilt als erfüllt, wenn mindestens die Möglichkeit vorhanden ist, EPL Code in der
Fraunhofer IAO
17
2
Marktübersicht
IDE zu debuggen und/oder Testanfragen an die Event Processing Engine
zu senden; manche Lösungen sehen aber auch sehr komplexe Mechanismen zur Durchführung von Simulationen vor, was entsprechend im
Text vermerkt wird
2.3
•
Vorhandensein einer Konsole (Event Monitor) zur textuellen Darstellung
der von der Event Processing Engine registrierten Events
•
Vorhandensein eines Dashboards zur graphischen Visualisierung von
Events in Echtzeit, gegebenenfalls mit der Möglichkeit zur Durchführung
weiterführender Analysen (zum Beispiel mittels Drill-DownFunktionalität); sofern angegeben, werden die wichtigsten zur Verfügung gestellten Diagrammtypen in der textuellen Beschreibung aufgeführt
•
Möglichkeit, das Layout und/oder das Verhalten von Dashboards über
eine graphische Benutzeroberfläche zu gestalten, zum Beispiel mittels
Widgets
•
Vorhandensein einer Event Datenbank, in der Events und/oder Alerts gespeichert werden können, zum Beispiel für die spätere Durchführung
von Auswertungen
•
Möglichkeit, Events zum Zwecke der Weiterverarbeitung zu exportierten: das Kriterium gilt als erfüllt, wenn mindestens der Export in eine externe Datenbank oder in eine Datei (zum Beispiel CSV) möglich ist
•
Vorhandensein von Werkzeugen für die Generierung von Reports oder
Auswertungen: sofern angegeben, werden die zur Verfügung gestellten
Exportmöglichkeiten für die generierten Reports (zum Beispiel PDF,
HTML, Microsoft Word) in der textuellen Beschreibung angeführt
•
Vorhandensein einer Anbindung an einen Enterprise Service Bus (ESB):
das Kriterium gilt als erfüllt, wenn mindestens eine bedeutsame ESBImplementation unterstützt wird
Produktbeschreibungen
Insgesamt wurden 20 Lösungen betrachtet, die als Mindestanforderung eine
Event Processing Engine enthalten müssen. Aufgrund des Umstands, dass einige Produkte keine Visualisierungskomponente enthalten, wurde zusätzlich die
Dashboardsoftware RTView in die Betrachtung aufgenommen, da sich in Verbindung mit einer reinen Event Processing Engine damit ein vollständiges RealTime Monitoring System realisieren lässt.
18
Fraunhofer IAO
2
Marktübersicht
Folgende Produkte wurden untersucht, wobei sich die Reihenfolge aus einer alphabetischen Sortierung nach den Produktnamen ergibt und die reine
Dashboardlösung RTView den Abschluss der Betrachtung bildet:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Progress Apama
ruleCore CEP Server
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
Starview Smart Enterprise Platform
Microsoft StreamInsight
Axway Synchrony Sentinel
West Global Vantify
IBM WebSphere Business Events
SL RTView
Das im Forschungsumfeld häufig erwähnte Event Processing Tool AMiT (Active
Middleware Technology)4 von IBM wird in dieser Marktübersicht nicht untersucht, da es sich hierbei um ein Forschungsprodukt handelt, zu dem kein Produktblatt und nur wenig Informationen verfügbar sind.
4
Weitere Informationen unter https://www.research.ibm.com/haifa/dept/services/soms_ebs.html
Fraunhofer IAO
19
2
Marktübersicht
2.3.1
Name des Anbieters
Sybase
Name des Produktes
Aleri Streaming Platform / CEP
Website
20
http://www.sybase.com/products/financialservicessolutions/
complex-event-processing
Unterstützte Betriebssysteme
Windows, Linux, Solaris
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Financial Services Solution, RFID, CRM und Telekommunikation explizit genannt
Verbreitung
Stark verbreitet (vgl. [11] - gemeinsam
mit Coral8, das mittlerweile in Sybase
CEP übergegangen ist)
Referenzkunden
Commerzbank, Barclays, ING
Event Stream Processing
Ja
Complex Event Processing
Ja
EPL Sprachtyp
Entwicklungsumgebung für EPL
Ja
Graphische Modellierungstools für
EPL
Ja (Aleri Studio) /
Nein (CEP Studio)
Debugging und Simulation
Ja
Event Monitor
Ja
Dashboard
Ja (SL RTView lizenziert)
Dashboard
Ja
Event Datenbank
Nein
Export von Events für statistische
Zwecke
Ja
Auswertungs- und Analysetools
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
2
Marktübersicht
Beschreibung der Event Processing Engine
Sybase hat neben der Aleri Streaming Platform die ehemalige Coral8 CEPEngine (unter dem Namen Sybase CEP) in ihre Produktpalette integriert, die
früher als eigenständige Produkte auf dem Markt angeboten wurden.
Bei der Aleri Streaming Platform stehen Adapter für verschiedene Messagingsysteme (z.B. TIBCO Rendezvous, IBM WebSphere MQ und JMS), Datenbanken
(via ODBC und JDBC), Sockets, Dateien, SMTP, XML, CSV und weitere zur Verfügung, insbesondere auch spezielle Adapter für Finanzmarktdaten. Mittels
APIs für C++, Java und .NET können auch eigene Adapter entwickelt werden.
Auch Sybase CEP stellt ähnlich viele Adapter zur Verfügung wie die Aleri
Streaming Platform. Zudem können ebenfalls eigene Adapter mit C/C++, C#,
Java, Perl und Python entwickelt werden.
Die Verarbeitungsgeschwindigkeit wird mit einigen 100.000 Events (Aleri
Streaming Platform) bis zu einer Million Events (Sybase CEP) pro Sekunde angegeben. Die Reaktionszeit soll dabei im Millisekundenbereich liegen.
Für die Anwendung auf dem Kapitalmarkt ist eine Integration mit der Marktdatenplattform Sybase RAP möglich, einer auf einen hochvolumigen Durchsatz
mit mehr als 100.000 Nachrichten pro Sekunde spezialisierten Lösung, die
Echtzeitverarbeitung und analytische Funktionen ermöglicht.
Für die Administration steht eine graphische Konsole zur Verfügung.
Beschreibung der Event Processing Language
Für die Aleri Streaming Engine kommt die sogenannte Aleri SQL zum Einsatz,
die eine Real-Time Erweiterung für SQL zur Verfügung stellt. Daneben kann die
Skriptsprache Aleri SPLASH verwendet werden, die eine Java-ähnliche Syntax
besitzt. Im Aleri Studio können Event Processing Rules zudem auch graphisch
modelliert werden (vgl. Abbildung 25).
Die für die Sybase CEP Engine verwendete Continuous Computation Language
(CCL) ist ebenfalls SQL-basiert mit den erforderlichen Erweiterungen für kontinuierliche Datenanfragen. Ein BPEL-to-CCL-Compiler wird für die Verarbeitung
von in BPEL dargestellten Geschäftsprozessen eingesetzt. Für die Entwicklung
5
Abbildung entnommen aus http://www.sybase.com/files/Data_Sheets/Sybase_Aleri_StreamingPlatform_ds.pdf
Fraunhofer IAO
21
2
Marktübersicht
steht eine Eclipse-basierte IDE zur Verfügung (Sybase CEP Studio), die allerdings
keine graphische Modellierung vorsieht.
Abbildung 2: Modellierung mit dem
Sybase Aleri Studio
Beschreibung des Dashboards
Mit Sybase Dashboard, einer Komponente, welche die Dashboardlösung SL
RTView (siehe Abschnitt 2.3.21) lizensiert, können individuelle Dashboards graphisch modelliert werden. Es steht eine Vielzahl von verschiedenen graphischen
und textuellen Darstellungskomponenten zur Verfügung, unter anderem Torten-, Balken- und Liniendiagramme. Die Selektion und Filterung von Daten
durch den Endbenutzer ist innerhalb der Anwendung möglich.
Beschreibung der Ausgabe und Reportingfunktionen
Aleri bietet ein Datenbank-Interface nach außen hin an, so dass als von externen Funktionen als In-Memory-Datenbank genutzt werden kann. Der Zugriff
auf die Datenströme erfolgt dabei über JDBC und ODBC.
22
Fraunhofer IAO
2
2.3.2
Marktübersicht
Progress Apama
Name des Anbieters
Progress
Name des Produktes
Apama
Website
http://web.progress.com/de/apama/index.html
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber insbesondere für Trading,
Location-Based Services und Logistik
geeignet
Verbreitung
Sehr stark verbreitet, ca. 20% Marktanteil bei CEP Software im Jahr 2008
(vgl. [12])
Referenzkunden
Deutsche Bank, ABN Amro, SEB
Ja
Ja
EPL Sprachtyp
Imperativ
Ja
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Ja (SL RTView lizenziert)
Dashboard
Ja
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
23
2
Marktübersicht
Die Event Processing Engine wird vom Anbieter als Correlator bezeichnet. Das
Apama Integration Adapter Framework (IAF) stellt die Anbindung der Architektur an Eventquellen und -senken sicher. Neben einigen finanzmarktspezifischen
Datenformaten kann IAF auch mit ODBC/JDBC- und KDB+Datenbankanbindungen sowie RFID-Signalen umgehen und beherrscht auch
verschiedene Nachrichtentransportprotokolle wie TCP, UDP, CORBA, Java RMI
und ESB-Anbindungen (JMS und TIBCO Rendezvous). Sollte dies nicht ausreichen, können mittels einer API auch individuelle Adapter in Java, C oder C++
entwickelt werden.
Die Verarbeitungsgeschwindigkeit des Correlators wird mit mehreren 10.000
Events pro Sekunde angegeben, während die Reaktionszeit im Sub-Millisekundenbereich liegen soll. Eine Steigerung der Skalierung ist durch Parallelschaltung möglich.
Für die Definition von Event Processing Rules wird die imperative Skriptsprache
MonitorScript genutzt. Daneben kann alternativ auch Java verwendet werden.
Mit dem Apama Studio steht eine Eclipse-basierte Entwicklungsumgebung zur
Verfügung, mit der auch eine graphische Modellierung möglich ist (vgl. Abbildung 36), wobei eine interne Transformation in MonitorScript vorgenommen
wird. Auch werden Debugging- und Profiling-Funktionalitäten bereitgestellt.
Abbildung 3: Entwicklung mit dem
Progress Apama
Studio
6
Abbildung entnommen aus http://web.progress.com/docs/datasheets/apama/Apama_EventModeler.pdf
24
Fraunhofer IAO
2
Marktübersicht
Mit Hilfe des Apama Dashboard Builders, der die Dashboardlösung SL RTView
(siehe Abschnitt 2.3.21) lizensiert, können individuelle Dashboards graphisch
modelliert werden. Es stehen etwa 120 verschiedene Komponenten (zum Beispiel Zähler oder vielfältige Diagrammtypen) zur Verfügung, die von der Event
Processing Engine übergebene Events in Echtzeit darstellen können. Daten
können dabei auch gefiltert, aggregiert und konvertiert werden. Die Anzeige ist
sowohl im Client als auch online über einen Webbrowser möglich. Ein beispielhaftes Apama Dashboard ist in Abbildung 47 dargestellt.
Progress Apama
Dashboard Builder
Events können in der Datenbank, dem so genannten Event Store, abgelegt und
mit Hilfe der im Research Studio enthaltenen Analysewerkzeuge ausgewertet
werden.
7
Abbildung entnommen aus http://web.progress.com/de/apama/dashboard-builder.html
Fraunhofer IAO
25
2
Marktübersicht
2.3.3
Name des Anbieters
TIBCO
Name des Produktes
BusinessEvents (Event Processing Engine) & Spotfire (Dashboard)
Website
26
http://www.tibco.com/products/businessoptimization/complex-event-processing/businessevents
Windows, Linux, Solaris, HP UX
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Produktion, Verkauf,
Verteidigung und Gesundheit explizit
genannt
Verbreitung
Sehr stark verbreitet, ca. 40% Marktanteil bei CEP Software im Jahr 2008
(vgl. [12])
Referenzkunden
Air France, Vodafone, Markant
Ja
Ja
EPL Sprachtyp
Regelbasiert
Ja
EPL
Ja
K.A.
Event Monitor
Ja
Dashboard
Ja (Spotfire)
Dashboard
Ja (Spotfire)
Event Datenbank
Ja
Zwecke
Ja
K.A.
ESB-Anbindung
Ja
Fraunhofer IAO
2
Marktübersicht
Als Adapter werden Web Services und ESB-Implementationen wie JMS und
TIBCO Rendezvous unterstützt. Ferner stehen Datenbankanbindungen über
JDBC zur Verfügung.
Mehrere Event Processing Engines können zur Erhöhung der Verarbeitungsgeschwindigkeit parallel geschaltet werden.
Es kommt eine SQL-ähnliche Syntax als Grundlage für die EPL zum Einsatz. Assistenten helfen Business Usern bei der Erstellung entsprechender Regeln.
Mit Hilfe der TIBCO Spotfire Komponente können Events visualisiert werden. Es
handelt sich dabei um eine eigene Analyse- und Visualisierungskomponente,
die allerdings an TIBCO BusinessEvents angebunden werden kann. Es kann dabei auf eine Vielzahl an unterschiedlichen Diagrammtypen zurückgegriffen
werden, unter anderem Graphen, Torten-, Balken- und Liniendiagramme, Karten usw. Die Dashboards können graphisch modelliert werden. Abbildung 58
zeigt ein exemplarisches TIBCO Spotfire Dashboard.
Abbildung 5: Exemplarisches TIBCO
Spotfire Dashboard
8
Abbildung entnommen aus http://spotfire.tibco.com/products/spotfire-professional/exploratory-data-analysis.aspx
Fraunhofer IAO
27
2
Marktübersicht
Events können in einer Datenbank abgelegt werden und damit für beliebige
Auswertungen weiterverwendet werden.
28
Fraunhofer IAO
2
2.3.4
Marktübersicht
ruleCore CEP Server
Name des Anbieters
ruleCore
Name des Produktes
CEP Server
Website
http://www.rulecore.com/
Alle (Software as a Service)
Lizenztyp
Kommerziell
Softwareart
Branchenfokus
Keiner, aber Mobile Asset Tracking
(Tracking von Fahrzeugen, GPSGeräten und Handys) als wichtiges
Anwendungsgebiet genannt
Verbreitung
K.A.
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
Regelbasiert
Nein
EPL
Nein
Ja
Event Monitor
Nein
Dashboard
Nein
Dashboard
Nein
Event Datenbank
Nein
Zwecke
Ja
Nein
ESB-Anbindung
Ja
Fraunhofer IAO
29
2
Marktübersicht
Die Nutzung des ruleCore CEP Servers wird als Dienst über das Internet (Software as a Service) angeboten. Zudem können durch ein sogenanntes OEM Kit
eigene, verteilte Anwendungen entwickelt werden, die auf dem ruleCore CEP
Server basieren.
Adapter sind unter anderem für JMS, Web Services und REST vorhanden. Sämtliche ein- und ausgehenden Events werden in XML dargestellt. Das Modul für
die Aufnahme und Ausgabe von Events basiert auf dem Open Source Enterprise
Service Bus Mule ESB.
Die Event Processing Engine kann auf mehrere Server verteilt werden, so dass
eine skalierbare Anwendung möglich ist.
Die von ruleCore verwendete deklarative Abfragesprache Reakt ist eine regelbasierte EPL, die auf XML basiert. Eine Entwicklungsumgebung ist nicht vorgesehen, allerdings vertreibt ruleCore unter dem Namen FleetNotice eine Lösung für
das Echtzeit-Tracking von Fahrzeugflotten, die auf dem ruleCore CEP Server basiert und eine webbasierte Benutzerschnittstelle für die Regeldefinition basierend auf Formularen bereitstellt. Diese kann auch generisch für die Erstellung
von Event Processing Rules für den ruleCore CEP Server genutzt werden.
30
Fraunhofer IAO
2
2.3.5
Marktübersicht
Name des Anbieters
Truviso
Name des Produktes
Continuous Analytics
Website
http://www.truviso.com/continuous-analyticstechnology.php
Linux
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Web Analytics,
Advertizing Analytics, Video Analytics
sowie Trading explizit genannt
Verbreitung
K.A.
Referenzkunden
K.A.
Ja
Nein
EPL Sprachtyp
Ja
EPL
K.A.
K.A.
Event Monitor
K.A.
Dashboard
Ja
Dashboard
Ja
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Nein
Fraunhofer IAO
31
2
Marktübersicht
Als Adapter werden JMS, SOAP, REST, XML, CSV und Textdateien mit Rohdaten unterstützt sowie Datenbankanbindungen über JDBC.
Die so genannte TruSQL Engine verarbeitet sowohl Datenströme in Echtzeit, als
auch persistierte Daten, so dass sowohl historische als auch vorausschauende
Analysen ermöglicht werden. Der Hersteller wirbt mit einer Verarbeitungsperformance von 500.000 Datensätzen pro Sekunde.
Als Event Processing Language kommt SQL zum Einsatz, die für kontinuierliche
Datenanfragen erweitert wurde, so dass sich Zeit- und Datenfenster auf den
Eventströmen ausdrücken lassen. Kontinuierliche Datenanfragen erzeugen weitere auswertbare Datenströme.
Das so genannte TruView Framework ermöglicht die Erstellung von anpassbaren Dashboards, die als Webanwendungen auf Adobe Flex basieren und anhand der kontinuierlichen Datenanfragen in Echtzeit aktualisiert werden.
Neben der Visualisierung von Daten in einem Dashboard sind auch Alarme in
Form von SMS, E-Mail oder per SNMP möglich und es können andere Systeme
getriggert werden.
Eine Reportingfunktionalität ist vorhanden, wird allerdings nicht näher beschrieben.
32
Fraunhofer IAO
2
2.3.6
Marktübersicht
Name des Anbieters
UC4 Software
Name des Produktes
UC4 Decision (Event Processing Engine) & UC4 Insight (Dashboard)
Website
http://www.uc4.com/de/produkte-loesungen/predictivepattern-engine/uc4-decision.html
Windows
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Intelligent Service Automation, Application Performance Assurance und Service Level Management beispielhaft als Anwendungsgebiete genannt
Verbreitung
Stark verbreitet (vgl. [11])
Referenzkunden
SBB, T-Systems
Ja
Ja
EPL Sprachtyp
Regelbasiert
Ja
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Ja (UC4 Insight)
Dashboard
Ja (UC4 Insight)
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
33
2
Marktübersicht
UC4 Decision besitzt eine skalierbare Event Processing Engine. Adapter sind für
MSMQ (Microsoft Message Queuing Service), IBM WebSphere MQ, TIBCO Rendezvous, JMS, Web Services und Sockets vorgesehen. Zudem können Dateien,
POP3-Nachrichten und RSS-Feeds ausgelesen und als Events genutzt werden.
Datenbankanbindungen existieren für Microsoft SQL Server, IBM DB2, Oracle,
MySQL und ODBC. Die Entwicklung eigener Adapter ist ebenfalls möglich.
Die Verarbeitungsgeschwindigkeit wird mit mehreren Tausend Events pro Sekunde angegeben.
Für die Administration steht eine graphische Konsole zur Verfügung. Zudem
können vordefinierte Szenarien mit dem Simulation Studio simuliert und getestet werden inklusive der Visualisierung auf einem Real-Time Dashboard.
Das Modelling Studio sieht die graphische Modellierung von Regeln, Eventstrukturen und -korrelationen vor. Die Code-basierte Programmierung in einer
EPL ist nicht vorgesehen. Abbildung 6 zeigt beispielhaft die Modellierungsumgebung von UC4 Decision.
Abbildung 6: Modellierung mit UC4
Decision
34
Fraunhofer IAO
2
Marktübersicht
Mit UC4 Insight steht ein Real-Time Dashboard zur Verfügung, welches als eigenständiges Produkt auch für Business Intelligence und weiterführende Analysen, beispielsweise Fehler-Ursachen-Analysen, eingesetzt werden kann. Das
Dashboard ist ausgerichtet auf die Visualisierung von Events und besitzt somit
neben verschiedenen Diagrammtypen wie Punkt-, Linien- oder Treppendiagrammen auch Visualisierungsmöglichkeiten für Event-Cluster und 3D-EventTunnel. Die beispielhafte Darstellung eines Event Tunnels mit UC4 Insight ist in
Abbildung 7 dargestellt.
Abbildung 7: Beispielhafte Event
Tunnel-Darstellung
mit UC4 Insight
Fraunhofer IAO
35
2
Marktübersicht
2.3.7
JBoss Drools Fusion
Name des Anbieters
JBoss
Name des Produktes
Drools Fusion
Website
36
http://www.jboss.org/drools/drools-fusion.html
Alle mit Java Runtime
Lizenztyp
Open Source
Softwareart
Branchenfokus
Keiner, aber Trading und Bezahlsysteme als beispielhafte Anwendungsgebiete genannt
Verbreitung
Drools 5.0 ca. 2.000 Downloads
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
Regelbasiert
Ja
EPL
Nein
Ja
Event Monitor
Nein
Dashboard
Nein
Dashboard
Nein
Event Datenbank
Nur Anbindung
Zwecke
Ja
Nein
ESB-Anbindung
Ja
Fraunhofer IAO
2
Marktübersicht
Drools ist eine sogenannte Business Logic Integration Plattform, die als Open
Source-Produkt der Apache Software License (ASL) unterliegt. Sie besteht aus
den vier Komponenten Guvnor (Knowledge Repository), Expert
(Geschäftsregelengine), Flow (Geschäftsprozessengine) und Fusion (Event Processing Engine). Drools Fusion kann zusammen mit den anderen Komponenten
verwendet werden, was allerdings nicht erforderlich ist.
Durch die Integration von Drools Fusion mit dem Integration Framework Apache Camel steht eine Vielzahl von Eingabeformaten und Transportprotokollen
für Events zur Verfügung. Unter anderem werden HTTP, JMS, Apache
ActiveMQ, JBI, Apache MINA und verschiedene Datenformate, wie beispielsweise CSV, JSON (JavaScript Object Notation), XML, SOAP und JAXB (Java
Architecture for XML Binding), unterstützt.
Drools Fusion bietet zudem eine Integration mit dem Spring und dem OSGi
Framework an.
Die verwendete EPL ist eine deklarative Sprache, die Produktionsregeln auf
Events anwenden kann. Für die Entwicklung der Regeln steht eine Eclipsebasierte IDE zur Verfügung, die in Abbildung 89 dargestellt ist.
Abbildung 8: Entwicklung mit JBoss
Drools
9
Abbildung entnommen aus http://www.jboss.org/drools/drools-fusion.html
Fraunhofer IAO
37
2
Marktübersicht
2.3.8
Oracle EDA Suite
Name des Anbieters
Oracle
Name des Produktes
EDA Suite
Website
38
http://www.oracle.com/us/technologies/soa/edasuite/index.html
Windows, Linux, Solaris, HP-UX, AIX
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Trading, Telekommunikation, Handel, Produktion und Verwaltung explizit genannt
Verbreitung
Sehr stark verbreitet (vgl. [11])
Referenzkunden
Monster.com, NH Hotels
Ja
Ja
EPL Sprachtyp
Ja
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Ja
Dashboard
Ja
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
2
Marktübersicht
Oracle CEP basierte ehemals auf der Esper Event Processing Engine, verwendet
mittlerweile aber eine eigene Engine. Als Adapter werden JMS und HTTP sowohl für eingehende als auch ausgehende Events unterstützt. Eine Datenbankanbindung kann über JDBC realisiert werden. Für die Entwicklung eigener
Adapter werden entsprechende APIs bereitgestellt.
In Bezug auf Hochverfügbarkeit ist ein Clustering von CEP-Instanzen möglich.
Auch ein ausfallsicherer, verteilter Datencache kann mittels Oracle Coherence
zur Verfügung gestellt werden.
Die Antwortzeit gibt Oracle im Mikrosekundenbereich an.
Die als Oracle Continuous Query Language (CQL) bezeichnete Programmiersprache ist SQL-basiert. Eine auf Eclipse aufsetzende Entwicklungsumgebung
wird für die Entwicklung bereitgestellt, mit welcher eine graphische Modellierung der CQL möglich ist (vgl. Abbildung 910). Mit Hilfe von mitgelieferten Assistenten verspricht Oracle eine schnelle Entwicklung EDA-basierter Anwendungen.
Abbildung 9: Modellierung mit der
Oracle EDA Suite
10
Abbildung entnommen aus http://download.oracle.com/docs/cd/E14571_01/doc.1111/e14476/overview.htm
Fraunhofer IAO
39
2
Marktübersicht
Der CEP Visualizer dient zur Anzeige von Events und kann sowohl von Entwicklern als auch von Administratoren und Endbenutzern verwendet werden. Die
Komponente setzt auf Adobe Flex auf und kann damit über das Web genutzt
werden.
Für ein weiterführendes Monitoring bietet Oracle eine Komponente für Business Activity Monitoring (BAM) an, die über vielfältige Möglichkeiten zur Anzeige von Events verfügt. Sie kann über JMS, JCA oder Web Services angebunden werden. Eine Vielzahl von Diagrammtypen wird unterstützt, unter anderem
Torten- und Balkendiagramme, sowie Zähler. Oracle BAM ist eine webbasierte
Anwendung, die Nutzung der BAM-Komponente ist derzeit allerdings nur mit
dem Microsoft Internet Explorer möglich. Abbildung 1011 zeigt ein exemplarisches Oracle BAM Dashboard.
Abbildung 10:
Exemplarisches
Oracle BAM Dashboard
Events können in einer Datenbank abgelegt werden und damit für beliebige
Auswertungen weiterverwendet werden.
11
Abbildung entnommen aus http://www.oracle.com/technetwork/middleware/bam/overview/bam-1.pdf
40
Fraunhofer IAO
2
2.3.9
Marktübersicht
EsperTech Esper
Name des Anbieters
EsperTech
Name des Produktes
Esper (Event Processing Engine) &
EsperHQ (Dashboard)
Website
http://esper.codehaus.org/
Windows, Linux, Solaris, AIX
Lizenztyp
Open Source (Event Processing Engine) / Kommerziell (Enterprise Edition
und zusätzliche Komponenten)
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Trading, RFID und CRM
explizit genannt
Verbreitung
Referenzkunden
ActiveEndpoints, AeroScout, Swisscom
Ja
Ja
EPL Sprachtyp
Ja (Enterprise Edition)
EPL
Event Monitor
Dashboard
Dashboard
Event Datenbank
Zwecke
Nein
ESB-Anbindung
Ja
Fraunhofer IAO
41
2
Marktübersicht
Die Java-basierte Event Processing Engine ist unter einer Open Source-Lizenz
(GPL V2) erhältlich und kann somit frei heruntergeladen und verwendet werden. Es ist auch eine Enterprise Edition mit erweiterten Funktionalitäten verfügbar. Mitgelieferte Adapter unterstützen JMS (inbound und outbound), JDBC
und CSV sowie .NET, XML und Java Beans. Desweiteren können auch Oracle,
MySQL und Microsoft SQL Datenbanken angebunden werden. Eigene Adapter
können mit Hilfe eines API selbst erstellt werden.
Die EsperHA-Komponente erweitert Esper im Hinblick auf Hochverfügbarkeit
(Caching, Clustering, Hot-Backup).
Die EPL verwendet eine SQL-ähnliche Syntax. In der Open Source-Variante ist
keine eigene Entwicklungsumgebung für die Erstellung der Statements vorgesehen. Die Enterprise Edition hingegen bietet eine Formular-basierte Designkomponente, einen Expression Builder sowie eine graphische Komponente zur
Darstellung von definierten Event Processing Rules und derer Abhängigkeiten.
Die Dashboardkomponente EsperHQ ist webbasiert und setzt auf Adobe Flex
auf. Mit Hilfe dieser kostenpflichtigen Applikation können so genannte
Eventlets in einer konfigurierbaren Umgebung graphisch dargestellt werden.
Abbildung 1112 zeigt ein beispielhaftes EsperHQ Dashboard.
Abbildung 11: Beispielhaftes EsperHQ
Dashboard
Es werden Torten-, Linien- und Balkendiagramme sowie Tachometer, Zähler
und einige andere Diagrammtypen, wie beispielsweise die Darstellung von iden-
12
Abbildung entnommen aus http://www.espertech.com/resources/sd_esperhqscreenshots.html
42
Fraunhofer IAO
2
Marktübersicht
tifizierten Events im Zeitablauf, bereitgestellt, die mit Events verbunden werden
können. Assistenten unterstützen auf Wunsch bei der Modellierung von Dashboards. Alternativ kann auch ein Code-Editor verwendet werden.
In der Enterprise Edition bietet Esper einen JDBC Server Endpoint an, so dass
von beliebigen Analyse- und Reportinganwendungen in Echtzeit auf die kontinuierlichen Eventabfragen bzw. Eventströme zugegriffen werden kann. Dies ist
sowohl lokal als auch per Remote-Zugriff möglich.
Fraunhofer IAO
43
2
Marktübersicht
2.3.10 Event Zero Event Processing Network
Name des Anbieters
Event Zero
Name des Produktes
Event Processing Network
Website
44
http://www.eventzero.com/Solutions/EDA.aspx
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner
Verbreitung
K.A.
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
K.A.
Nein
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Ja
Dashboard
Ja
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
2
Marktübersicht
Event Zero stellt mehr als 60 mitgelieferte Adapter zur Verfügung, mit denen
Events an die Event Processing Engine übergeben werden können. Neben verschiedenen ESB-Implementationen (TIBCO Rendezvous, IBM WebSphere MQ,
Progress SonicMQ, Apache ActiveMQ, JBoss ESB, Mule, JMS) und InternetProtokollen (HTTP, SMTP, Web Services, XML) werden auch CSV, CORBA und
DCOM unterstützt. Datenbanken können über JDBC und ODBC angebunden
werden.
Die Verarbeitungsgeschwindigkeit wird von Event Zero mit »Milliarden Events
pro Tag« angegeben.
Die Regeln werden mit einem Assistenten definiert (vgl. Abbildung 1213). Eine
direkte, Code-basierte Definition von Regeln ist nicht vorgesehen.
Abbildung 12: Event
Zero Administrationsund Entwicklungstool
Event Zero stellt eine Anzahl von Templates für die Gestaltung von Dashboards
bereit. Es können sowohl Events in Echtzeit dargestellt werden, als auch eine
13
Abbildung entnommen aus http://www.eventzero.com/technology/administrator.aspx
Fraunhofer IAO
45
2
Marktübersicht
Analyse historischer Daten vorgenommen werden, wobei mittels Drill-DownAnalysen die Aggregationsstufe variiert werden kann.
Die Gestaltung von Dashboards erfolgt über Widgets, wobei folgende Diagrammtypen für die Visualisierung von Events bereitgestellt werden: Fortschrittsbalken, Zähler, Linien-, Punkt- und Balkendiagramme.
Die Darstellung erfolgt in einem Webbrowser. Abbildung 1314 stellt ein beispielhaftes Event Zero Dashboard dar.
Abbildung 13: Beispielhaftes Event
Zero Dashboard
Mittels eines mitgelieferten Reportgenerators können Reports aus den Daten
erstellt und als PDF oder HTML auch online publiziert werden.
14
Abbildung entnommen aus http://www.eventzero.com/technology/perspective.aspx
46
Fraunhofer IAO
2
Marktübersicht
2.3.11 StreamBase Event Processing Platform
Name des Anbieters
StreamBase
Name des Produktes
Event Processing Platform
Website
http://www.streambase.com/products-home.htm
Windows, Linux
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Fokus auf Trading und Verteidigung,
Produkt aber auch für andere Zwecke
einsetzbar
Verbreitung
Referenzkunden
BNY ConvergEx Group
Ja
Ja
EPL Sprachtyp
Ja
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Nein
Dashboard
Nein
Event Datenbank
Ja
Zwecke
Ja
Nein
ESB-Anbindung
Ja
Fraunhofer IAO
47
2
Marktübersicht
Die Event Processing Engine stellt eine Vielzahl von mitgelieferten Adaptern zur
Verfügung. Neben mehreren finanzmarktspezifischen Formaten können auch
CSV, IBM WebSphere MQ, JMS, HTTP und Twitter-Daten verarbeitet werden.
Datenbankanbindungen existieren für JDBC, Oracle, MySQL und Microsoft SQL.
Mittels einer API für Java, C#, C++ und Python können eigene Adapter erstellt
werden. Für die Visualisierung ist die Ausgabe über .NET, Java Swing oder Microsoft Excel möglich.
Die Verarbeitungsgeschwindigkeit wird mit etwa 500.000 Events pro Sekunde
angegeben. Die Simulation von Events (zum Beispiel zur Fehlersuche) ist möglich.
Die StreamSQL genannte EPL von StreamBase setzt auf SQL auf. Für die Entwicklung steht eine Eclipse-basierte IDE zur Verfügung. StreamBase Studio erlaubt neben der Code-basierten Entwicklung auch die graphische Modellierung
von Regeln und Abfragen mit StreamSQL EventFlow (vgl. Abbildung 1415). Ein
Debugger ist ebenfalls enthalten.
StreamBase Studio
15
Abbildung entnommen aus http://www.streambase.com/products-StreamBaseStudio.htm
48
Fraunhofer IAO
2
Marktübersicht
2.3.12 Open ESB Intelligent Event Processor (IEP)
Name des Anbieters
Open ESB (Oracle)
Name des Produktes
Intelligent Event Processor (IEP)
Website
https://open-esb.dev.java.net/IEPSE.html
Lizenztyp
Open Source
Softwareart
Branchenfokus
Keiner
Verbreitung
K.A.
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
Ja (NetBeans IDE)
EPL
Ja (NetBeans IDE)
Nein
Event Monitor
Nein
Dashboard
Nein
Dashboard
Nein
Event Datenbank
Ja (Java DB)
Zwecke
Ja
Nein
ESB-Anbindung
Ja
Fraunhofer IAO
49
2
Marktübersicht
Der Intelligent Event Processor (IEP) ist ein Teil des Open ESB Projektes, das als
Open Source-Produkt der Common Development and Distribution License
(CDDL) unterliegt. Dieses ist wiederum stark mit der Java CAPS Plattform für
SOA verbunden ist. Die Pflege des Projektes ging mit der Übernahme von Sun
an Oracle über. Im Rahmen des Open ESB Projektes ist auch eine BPEL Service
Engine integriert. Als Adapter können alle von Open ESB unterstützten Anbindungen verwendet werden, unter anderem JMS, SOAP, XML, HTTP, FTP und
JBI.
Als EPL wird die Continuous Query Language (CQL) verwendet, die auch in der
Oracle EDA Suite zum Einsatz kommt (siehe Abschnitt 2.3.8). Mit einem Plugin
für die NetBeans IDE kann eine graphische Entwicklung von Event Processing
Rules durchgeführt werden (vgl. Abbildung 1516).
Abbildung 15: Elemente für die Entwicklung mit Open
ESB IEP
16
Abbildung entnommen aus https://open-esb.dev.java.net/kb/60/ep-iepse-devguide.html
50
Fraunhofer IAO
2
Marktübersicht
2.3.13 Vitria M3O Analytic Server & M3O Operations Book
Name des Anbieters
Vitria
Name des Produktes
M3O Analytic Server (Event Processing
Engine) & M3O Operations Book
(Dashboard)
Website
http://www.vitria.com/products/m3o-products/m3oanalytic-server/
Windows, Linux, Solaris, HP-UX
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Verbreitung in Telekommunikation, Energie und Versorger,
Finanzdienstleistungen und Versicherungen
Verbreitung
K.A.
Referenzkunden
TXU Energy, R Cable Galicia, Andorra
Telecom
Ja
Ja
EPL Sprachtyp
Ja
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Ja (M3O Operations Book)
Dashboard
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
51
2
Marktübersicht
Als Bestandteil der Vitria M3O (Model, Manage, Monitor and Optimize) Operational Intelligence Software Suite ist der M3O Analytic Server für Complex Event
Processing zuständig.
Die zugrundeliegende Event Processing Engine operiert direkt auf den im XMLFormat vorliegenden Events. Adapter werden unter anderem für JMS und Web
Services bereitgestellt. Die Anbindung von Datenbanken, RSS-Feeds oder Sensordaten ist ebenfalls möglich. Zur Erhöhung der Skalierbarkeit ist der Feed Server von der eigentlichen Event Processing Engine architektonisch getrennt.
Events können an den M3O BPMS Server oder an beliebige Dritt-Applikationen
weitergegeben werden.
Die Abfragesprache des M3O Analytic Server heißt StreamXQuery und verwendet eine auf der standardisierten XQuery basierende Syntax. Die Analyse von
XML-basierten Event Streams kann mit SQL-Abfragen kombiniert werden. Die
Abfragen selbst werden mittels des graphischen Editors M3O Query Modeler
konstruiert (vgl. Abbildung 1617).
Vitria M3O Query
Modeler
17
Abbildung entnommen aus http://www.vitria.com/wpcontent/download/Complex%20Event%20Processing%20for%20Operational%20Intelligence_3_16_10.pdf
52
Fraunhofer IAO
2
Marktübersicht
M3O Operations Book ist die Dashboardkomponente der M3O Operational
Intelligence Software Suite. Als webbasierte Anwendung basiert M3O Operations Book auf Adobe Flex. Einige Templates für oft benötigte Diagramme werden mitgeliefert, die Konstruktion individueller Dashboards erfolgt graphisch
über Widgets. Historische und Echtzeitdaten können kombiniert werden. Zur
Visualisierung werden unter anderem Torten-, Balken, Linien- und
Pivotdiagramme zur Verfügung gestellt. Drill-Down-Analysen können ebenfalls
vorgenommen werden. Beispielhafte Dashboards zeigt Abbildung 1718.
Abbildung 17: Beispielhafte Vitria M3O
Operations Book
Dashboards
18
Abbildung entnommen aus http://www.vitria.marketbright.com/resources/brochures-and-datasheets/vitria_m3o_opsbook_ds_1_09.pdf
Fraunhofer IAO
53
2
Marktübersicht
2.3.14 Realtime Monitoring RTM Analyzer
Name des Anbieters
Realtime Monitoring GmbH
Name des Produktes
RTM Analyzer
Website
54
http://www.realtimemonitoring.de/index.php/de/leistungen/rtm-analyzer
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner, aber Trading, Produktion,
Telekommunikation und Business
Activity Monitoring (BAM) explizit als
Anwendungsgebiete genannt
Verbreitung
K.A.
Referenzkunden
TeamBank AG
Ja
Ja
EPL Sprachtyp
Ja
EPL
Ja
K.A.
Event Monitor
Ja
Dashboard
Ja
Dashboard
Ja
Event Datenbank
Nein
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
2
Marktübersicht
Adapter stehen für JDBC/ODBC, Files, Sockets, OPC DA, JMS, SNMP und JMX
zur Verfügung. Zudem können mit einem mitgelieferten Framework auch eigene Adapter implementiert werden.
Die Verarbeitungsgeschwindigkeit des RTM Analyzers wird mit einigen 100.000
Events pro Sekunde angegeben.
Die Abfrage von Events erfolgt durch SQL-Statements, die von der Event Processing Engine kontinuierlich ausgeführt werden. Dafür steht ein Query Editor
zur Verfügung (vgl. Abbildung 1819). Alternativ besteht die Möglichkeit, Abfragen durch ein graphisches Interface zu modellieren.
Abbildung 18: Entwicklung mit dem
RTM Analyzer
Events können in konfigurierbaren Dashboards (Management Cockpits) dargestellt werden. Abbildung 1920 zeigt ein exemplarisches Dashboard.
19
20
Abbildung entnommen aus http://www.realtime-monitoring.de/pdfs/Manufacturing_Demo_RTM_EN.pdf
Abbildung entnommen aus http://www.realtime-monitoring.de/pdfs/WhitePaper_RTM_Analyzer_EN.pdf
Fraunhofer IAO
55
2
Marktübersicht
Abbildung 19:
Exemplarisches RTM
Analyzer Dashboard
Daten können an Datenbanken oder externe Anwendungen übergeben werden.
56
Fraunhofer IAO
2
Marktübersicht
2.3.15 Informatica Rulepoint
Name des Anbieters
Informatica
Name des Produktes
Rulepoint
Website
http://www.informatica.com/de/products_services/rulepoin
t_operational_intelligence/Pages/index.aspx
Lizenztyp
Kommerziell
Softwareart
Branchenfokus
Keiner, aber Trading, Bezahlsysteme
und Verteidigung als Anwendungsgebiete beispielhaft genannt
Verbreitung
K.A.
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
Regelbasiert
Ja
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Nein
Dashboard
Nein
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
57
2
Marktübersicht
Mitgelieferte Adapter sind für ESB-Implementationen, Datenbanken und Files
vorhanden (JDBC, Web Services, JMS, EJB, RMI, HTTP, POP3, SMTP, IMAP, FTP
und XML) sowie für RSS-Feeds. Events können sowohl gelesen als auch geschrieben werden.
Für die Administration steht eine graphische Konsole zur Verfügung. Die Darstellung erfolgt im Webbrowser. Endbenutzer können über die Konsole auch
weitere Analysen in den berichteten Events (zum Beispiel Drill-Down) vornehmen. Historische und Echtzeitdaten können in die Analysen einbezogen werden. In Abbildung 2021 ist ein beispielhafter Real-Time Alert Manager dargestellt. Eine Visualisierungskomponente in Form eines Dashboards ist allerdings
nicht vorhanden.
Abbildung 20: Beispielhafter
Alert Manager
Die Definition von Event Processing Rules wird entweder mittels einer regelbasierten EPL oder über Assistenten vorgenommen. Für oft verwendete Ausdrücke
sind Templates verfügbar.
21
Abbildung entnommen aus http://www.informatica.com/INFA_Resources/ds_rulepoint_7146.pdf
58
Fraunhofer IAO
2
Marktübersicht
2.3.16 Starview Smart Enterprise Platform
Name des Anbieters
Starview Technology
Name des Produktes
Smart Enterprise Platform
Website
http://www.starviewtechnology.com/starviewproducts.html
Lizenztyp
Kommerziell
Softwareart
Branchenfokus
Keiner
Verbreitung
K.A.
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
Regelbasiert
Ja
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Nein
Dashboard
Nein
Event Datenbank
Ja
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
59
2
Marktübersicht
Adapter werden für TCP/IP, JMX, JMS, TIBCO Rendezvous, HTTP, Comet und
Dateien bereitgestellt. Datenbanken können mittels JDBC angebunden werden
und es existiert ein Adapter für H2DB. Mehrere Event Processing Engines können parallel geschaltet werden.
Der Simulation Server kann sowohl mit Echtzeitdaten, als auch mit historischen
Daten verwendet werden.
Die Definition von Regeln wird mittels der StarRules Sprache durchgeführt. Die
Sprache ist Agenten-orientiert und eignet sich damit auch für sehr komplexe
Algorithmen. Dafür stellt Starview eine Eclipse-basierte Entwicklungsumgebung
zur Verfügung. Diese enthält auch Assistenten, die auch weniger IT-erfahrenen
Anwendern die Definition von Regeln erleichtern sollen (vgl. Abbildung 2122).
Abbildung 21: Modellierung mit
Starview
22
Abbildung entnommen aus http://www.starviewtechnology.com/documents/Starview%20Solutions%20White%20Paper.pdf
60
Fraunhofer IAO
2
Marktübersicht
2.3.17 Microsoft StreamInsight
Name des Anbieters
Microsoft
Name des Produktes
StreamInsight
Website
http://www.microsoft.com/sqlserver/2008/en/us/R2complex-event.aspx
Windows
Lizenztyp
Kommerziell
Softwareart
Branchenfokus
Keiner, aber Trading, Energiewirtschaft, Health Care und Logistik beispielhaft genannt
Verbreitung
K.A.
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
Ja (Visual Studio)
EPL
Nein
Ja
Event Monitor
Nein
Dashboard
Nein
Dashboard
Nein
Event Datenbank
Ja (SQL Server)
Zwecke
Ja
Nein
ESB-Anbindung
Nein
Fraunhofer IAO
61
2
Marktübersicht
Die Verwendung von StreamInsight setzt einen Microsoft SQL Server voraus,
der für die Ablage von Eventdaten eingesetzt wird. StreamInsight liefert keine
vorgefertigten Adapter mit, allerdings wird auf die Verfügbarkeit von spezialisierten Adaptern bei Microsoft-Partnern hingewiesen. Eigene Adapter können
mit einem bereitgestellten SDK entwickelt werden, um damit Events aus Datenbanken, Webquellen oder anderen Applikationen lesen und absetzen zu
können.
StreamInsight lässt die Verarbeitung von mehreren 100.000 Events pro Sekunde zu.
Die Abfragesprache LINQ (Language Integrated Query) ist SQL-basiert. Die Entwicklung kann im Microsoft Visual Studio vorgenommen werden. Dieses stellt
alle in einer IDE üblichen Funktionalitäten zur Verfügung, beispielsweise einen
(graphischen) Event Flow Debugger (vgl. Abbildung 2223).
Abbildung 22: Entwicklung mit Microsoft StreamInsight
23
Abbildung entnommen aus
http://channel9.msdn.com/learn/courses/SQL2008R2TrainingKit/SQL10R2UPD05/SQL10R2UPD05_HOL_03/Exercise-1-Working-withthe-StreamInsight-Event-Flow-Debugger/
62
Fraunhofer IAO
2
Marktübersicht
2.3.18 Axway Synchrony Sentinel
Name des Anbieters
Axway
Name des Produktes
Synchrony Sentinel
Website
http://www.axway.com/products-solutions/psoverview/axway-synchrony/sentinel
K.A.
Lizenztyp
Kommerziell
Softwareart
Branchenfokus
Keiner, aber Netzwerk- und Geschäftsprozessüberwachung als Anwendungsgebiete genannt
Verbreitung
K.A.
Referenzkunden
Renault, Procter+Gamble, Electrolux,
DB Schenker
K.A.
Ja
EPL Sprachtyp
K.A.
K.A.
EPL
K.A.
K.A.
Event Monitor
Ja
Dashboard
Nein
Dashboard
Nein
Event Datenbank
K.A.
Zwecke
Ja
Ja
ESB-Anbindung
K.A.
Fraunhofer IAO
63
2
Marktübersicht
Synchrony Sentinel eignet sich insbesondere zur Überwachung der Axway
Synchrony Plattform, kann aber auch in andere Systeme integriert werden. Mit
der Universal Agent Script Facility werden Events aus verschiedenen Applikationen gesammelt.
In Synchrony Sentinel wird ein personalisiertes User Interface basierend auf der
Java-Technologie zur Verfügung gestellt, dessen Anzeige in einem Webbrowser
erfolgt. Darauf aufbauend kann der Benutzer mittels Java eine eigene
Dashboardapplikation entwickeln.
64
Fraunhofer IAO
2
Marktübersicht
2.3.19 West Global Vantify
Name des Anbieters
West Global
Name des Produktes
Vantify
Website
http://www.westglobal.com/
Windows, Linux, Unix, Solaris
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Fokus auf CRM und Netzwerküberwachung
Verbreitung
K.A.
Referenzkunden
Vodafone Ireland
Ja
Ja
EPL Sprachtyp
Regelbasiert
K.A.
EPL
K.A.
K.A.
Event Monitor
Ja
Dashboard
Ja
Dashboard
Ja
Event Datenbank
K.A.
Zwecke
K.A.
Ja
ESB-Anbindung
K.A.
Fraunhofer IAO
65
2
Marktübersicht
Es werden verschiedene Adapter für Middleware-Applikationen basierend auf
TIBCO, .NET und Java angeboten sowie für SNMP und Dateien. Auch werden
offene APIs unterstützt. Zudem werden mehrere Templates für Regeln zur Verfügung gestellt, die der Benutzer für Benachrichtigungen und Alarme auf einem Dashboard einsetzen kann.
Es wird insbesondere für den Einsatz im Customer Experience Management
(CEM) und Service Experience Management (SEM) geworben, wofür bereits
vorgefertigte Templates und Dashboards verfügbar sind.
Die Verarbeitungsgeschwindigkeit wird mit mehreren Tausend Events pro Sekunde angegeben.
Die Darstellung des konfigurierbaren Dashboards erfolgt in einem Webbrowser.
Es stehen verschiedene Diagramme für die Verwendung zur Verfügung. Abbildung 2324 zeigt exemplarische Vantify Dashboards. Der Anwender kann mittels
Drill-Down eine Ursachenforschung für Events durchführen.
Abbildung 23:
Exemplarische West
Global Vantify Dashboards
24
Abbildung entnommen aus http://www.westglobal.com/index.php?option=com_docman&task=doc_download&gid=3&Itemid=69
66
Fraunhofer IAO
2
Marktübersicht
2.3.20 IBM WebSphere Business Events
Name des Anbieters
IBM
Name des Produktes
WebSphere Business Events
Website
http://www-01.ibm.com/software/integration/wbe/
Windows, Linux, Solaris, HP-UX, AIX
Lizenztyp
Kommerziell
Softwareart
Komplettsystem
Branchenfokus
Keiner
Verbreitung
Stark verbreitet, ca. 7% Marktanteil
bei CEP Software im Jahr 2008 (vgl.
[12])
Referenzkunden
K.A.
Ja
Ja
EPL Sprachtyp
Regelbasiert
Nein
EPL
Ja
Ja
Event Monitor
Ja
Dashboard
Ja
Dashboard
Ja
Event Datenbank
Ja
Zwecke
Ja
Nein
ESB-Anbindung
Ja
Fraunhofer IAO
67
2
Marktübersicht
Die Event Processing Engine kann Events aus der IBM ESB-Implementation
WebSphere ESB, dem WebSphere Message Broker oder JMS beziehen bzw. zur
Weiterverarbeitung an andere Applikationen senden. Adapter stehen weiterhin
für eine Anzahl von Standardprotokollen wie HTTP, SMTP, FTP und Web Services zur Verfügung. Datenbanken können über JDBC und ODBC angebunden
werden. Für das Load Balancing können mehrere Event Processing Engines parallel geschaltet werden. Server Clustering wird ebenfalls unterstützt.
Die Definition von Event Processing Rules wird über die Design Komponente
mit Hilfe von Formularen vorgenommen (vgl. Abbildung 2425). Eine direkte,
Code-basierte Regeldefinition ist nicht vorgesehen.
Abbildung 24: Entwicklung mit IBM
WebSphere Business
Events
Die mitgelieferte Komponente für die Visualisierung von Events heißt Business
Space. Das Layout der Dashboards wird über Widgets definiert. Für die Gestaltung von Dashboards stehen mehrere Diagrammtypen, wie etwa Zähler, Linien, Torten-, Balken- und Punktdiagramme, zur Verfügung. Abbildung 2526 zeigt
beispielhafte Diagramme, die mit Business Space erstellt werden können.
25
Abbildung entnommen aus
http://publib.boulder.ibm.com/infocenter/wbevents/v7r0m0/topic/com.ibm.wbe.tutorial.doc/doc/exercise3.html
26 Abbildung entnommen aus
http://publib.boulder.ibm.com/infocenter/wbevents/v7r0m0/topic/com.ibm.wbe.monitoring.doc/doc/bs_overviewofcreatingcharts.html
68
Fraunhofer IAO
2
Marktübersicht
Abbildung 25: Beispielhafte Diagramme in IBM
WebSphere Business
Space
Werden weitergehende Visualisierungsmöglichkeiten benötigt, kann alternativ
auch eine Integration mit dem WebSphere Business Monitor erfolgen. Die Anzeige eines Dashboards ist auch auf Remotesystemen möglich.
Fraunhofer IAO
69
2
Marktübersicht
2.3.21 SL RTView
Name des Anbieters
SL
Name des Produktes
RTView
Website
70
http://www.sl.com/products/rtview.shtml
Lizenztyp
Kommerziell
Softwareart
Dashboard
Branchenfokus
Keiner
Verbreitung
Sehr verbreitet (unter anderem auch
lizensiert durch Sybase und Progress)
Referenzkunden
Deutsche Bank, Shell, NCR, HSBC,
UBS
Nein
Nein
EPL Sprachtyp
keine EPL
Nein
EPL
Nein
Nein
Event Monitor
Ja
Dashboard
Ja
Dashboard
Ja
Event Datenbank
Nur Anbindung
Zwecke
Ja
Ja
ESB-Anbindung
Ja
Fraunhofer IAO
2
Marktübersicht
RTView ist eine reine Visualisierungslösung, die in einer EDA für das Business
Activity Monitoring (BAM) integriert werden kann. Daten können aus einer
Vielzahl von Eventquellen gelesen werden. Eine Anbindung an JMS, IBM
WebSphere MQ, TIBCO Rendezvous und JMX ist vorhanden, ebenso wie für
Datenbanken, z.B. Oracle, Mircrosoft SQL Server und IBM DB2, sowie mittels
JDBC oder ODBC. Ferner können XML, CSV-basierte Dateien und Microsoft Excel Dateien verarbeitet werden. Die Entwicklung eigener Adapter ist möglich.
Mit dem RTView Builder können individuelle Dashboards und Reports mittels
einer graphischen Modellierungsumgebung gestaltet werden (vgl. Abbildung
2627).
SL RTView Builder
Es stehen mehrere Diagrammtypen für die graphische Darstellung zur Verfügung, beispielsweise Zähler, Fortschrittsbalken, Torten-, Linien- und Balkendiagramme. Die Darstellung der Dashboards auf Remotesystemen ist möglich. Der
Benutzer kann über das User Interface auch Drill-Down-Analysen durchführen.
Historische und Echtzeitdaten können kombiniert und gegenübergestellt werden.
RTView ist auch zur Verarbeitung von Alerts in der Lage. Diese können entweder per Mail oder SMS gesendet werden, aber auch in elektronischen Formaten
an Applikationen zum Zwecke der automatisierten Weiterverarbeitung.
Reports können als PDF, HTML oder Microsoft Excel Sheet erstellt und exportiert werden.
27
Abbildung entnommen aus http://www.sl.com/pdfs/SLRTViewDatasheet-Nov08.pdf
Fraunhofer IAO
71
2
Marktübersicht
2.4
Tabellarische Übersicht
Auf den folgenden Seiten werden die betrachteten Event Processing Tools anhand des in Abschnitt 2.2 eingeführten Kriterienrasters in einer tabellarischen
Übersicht gegenübergestellt.
72
Fraunhofer IAO
Aleri Streaming
Platform / CEP
Windows, Linux,
Solaris
Kommerziell
Komplettsystem
Ja
Ja
Ja
Name des Produktes
Softwareart
EPL Sprachtyp
Ja
Ja (SL RTView
lizenziert)
Ja
Nein
Dashboard
Export von Events für statistische Zwecke
ESB-Anbindung
Graphische Modellierungstools für Dashboard
Event Datenbank
Ja (SL RTView
lizenziert)
Ja
Ja
Event Monitor
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja (Aleri Studio)
Nein (CEP Studio)
Ja
Ja
Imperativ
Ja
Ja
Komplettsystem
Windows, Linux,
Solaris
Kommerziell
Apama
Progress
Entwicklungsumgebung für
EPL
Graphische Modellierungstools für EPL
Lizenztyp
Sybase
Name des Anbieters
Ja
K.A.
Ja
Ja
Ja (Spotfire)
Ja (Spotfire)
Ja
K.A.
Ja
Ja
Regelbasiert
Ja
Ja
Komplettsystem
BusinessEvents &
Spotfire
Windows, Linux,
Solaris, HP UX
Kommerziell
TIBCO
Ja
Nein
Ja
Nein
Nein
Nein
Nein
Ja
Nein
Nein
Regelbasiert
Ja
Event Processing
Engine
Ja
Alle (Software as
a Service)
Kommerziell
CEP Server
ruleCore
Nein
Ja
Ja
Ja
Ja
Ja
K.A.
K.A.
K.A.
Ja
Nein
Ja
Komplettsystem
Kommerziell
Continuous
Analytics
Linux
Truviso
Ja
Ja
Ja
Ja
Ja (UC4 Insight)
Ja (UC4 Insight)
Ja
Ja
Ja
Ja
Regelbasiert
Ja
Ja
Komplettsystem
Kommerziell
UC4 Decision &
UC4 Insight
Windows
UC4 Software
Ja
Nein
Ja
Nur Anbindung
Nein
Nein
Nein
Ja
Nein
Ja
Regelbasiert
Ja
Event Processing
Engine
Ja
Alle mit Java
Runtime
Open Source
Drools Fusion
JBoss
2
Marktübersicht
Fraunhofer IAO
73
74
Ja (Enterprise
Edition)
Ja (Enterprise
Edition)
Ja (Enterprise
Edition)
Ja (Enterprise
Edition)
Ja (Enterprise
Edition)
Ja (Enterprise
Edition)
Ja (Enterprise
Edition)
Ja (Enterprise
Edition)
Nein
Ja
Komplettsystem
Ja
Ja
Ja
Ja
Softwareart
EPL Sprachtyp
Fraunhofer IAO
Ja
Ja
Ja
Event Monitor
Dashboard
Event Datenbank
ESB-Anbindung
Ja
Ja
Ja
Ja
Ja
EPL
Lizenztyp
Windows, Linux,
Solaris, HP-UX, AIX
Kommerziell
Ja
Ja
Windows, Linux,
Solaris, AIX
Open Source /
Kommerziell
Komplettsystem
Esper & EsperHQ
EDA Suite
Name des Produktes
EsperTech
Oracle
Name des Anbieters
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
K.A.
Ja
Ja
Komplettsystem
Alle mit Java
Runtime
Kommerziell
Event Processing
Network
Event Zero
Ja
Nein
Ja
Ja
Nein
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Komplettsystem
Kommerziell
Windows, Linux
Event Processing
Platform
StreamBase
Ja
Nein
Ja
Ja (Java DB)
Nein
Nein
Nein
Nein
Ja (NetBeans IDE)
Ja (NetBeans IDE)
Ja
Event Processing
Engine
Ja
Alle mit Java
Runtime
Open Source
Open ESB
(Oracle)
Intelligent Event
Processor (IEP)
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Komplettsystem
M3O Analytic
Server & M3O
Operations Book
Windows, Linux,
Solaris, HP-UX
Kommerziell
Vitria
Ja
Ja
Ja
Nein
Ja
Ja
Ja
K.A.
Ja
Ja
Ja
Ja
Komplettsystem
Alle mit Java
Runtime
Kommerziell
Realtime Monitoring GmbH
RTM Analyzer
2
Marktübersicht
Ja
Ja
Nein
Ja
Event Processing
Engine
Ja
Ja
Regelbasiert
Ja
Ja
Ja
Ja
Nein
Nein
Ja
Softwareart
EPL Sprachtyp
EPL
Event Monitor
Dashboard
Event Datenbank
ESB-Anbindung
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Regelbasiert
Ja
Event Processing
Engine
Ja
Windows, Linux,
Solaris
Kommerziell
Lizenztyp
Rulepoint
Name des Produktes
Starview Technology
Smart Enterprise
Platform
Windows, Linux,
Solaris
Kommerziell
Informatica
Name des Anbieters
Nein
Nein
Ja
Ja (SQL Server)
Nein
Nein
Nein
Ja
Nein
Ja (Visual Studio)
Ja
Event Processing
Engine
Ja
Kommerziell
Windows
StreamInsight
Microsoft
K.A.
Ja
Ja
K.A.
Nein
Nein
Ja
K.A.
K.A.
K.A.
K.A.
Ja
Event Processing
Engine
K.A.
Kommerziell
Synchrony
Sentinel
K.A.
Axway
K.A.
Ja
K.A.
K.A.
Ja
Ja
Ja
K.A.
K.A.
K.A.
Regelbasiert
Ja
Ja
Komplettsystem
Windows, Linux,
Unix, Solaris
Kommerziell
Vantify
West Global
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Regelbasiert
Ja
Ja
Komplettsystem
WebSphere Business Events
Windows, Linux,
Solaris, HP-UX, AIX
Kommerziell
IBM
Ja
Ja
Ja
Nur Anbindung
Ja
Ja
Ja
Nein
Nein
Nein
keine EPL
Nein
Nein
Dashboard
Alle mit Java
Runtime
Kommerziell
RTView
SL
2
Marktübersicht
Fraunhofer IAO
75
3
Fazit
Die betrachteten Event Processing Tools sind zum Einsatz in einer EDA allesamt
geeignet. Die Minimalfunktionalität – den Empfang von Events, das Erkennen
von relevanten Events und Event Patterns nach definierten Regeln, sowie das
unmittelbare Auslösen entsprechender Reaktionen – beherrschen alle. Die meisten Produkte setzen dabei auf der Java Plattform auf.
Allerdings existieren auch große Unterschiede:
76
•
Umfang der mitgelieferten Adapter: Manche Produkte bieten eine breite
Palette an Anbindungen, von den verschiedensten ESB-Implementationen, über Internet-Protokolle und Datenbank-Anbindungen bis hin zu
Dateiformaten (beispielsweise Progress Apama, EventZero). Manche
Produkte, die sich sehr stark an den Einsatz in Finanzmärkten richten,
bringen auch eine weitgehende Unterstützung der in dieser Branche
verbreiteten Austauschformate mit (zum Beispiel Sybase, StreamBase).
Andere Anbieter setzen nur auf einige wenige verbreitete Standards,
wie etwa SOAP, und erwarten vom Anwender gegebenenfalls Eigenarbeit bei der Entwicklung eigener Adapter (beispielsweise Beispiel Microsoft StreamInsight).
•
Art und Umfang der mitgelieferten Werkzeuge: Viele Produkte enthalten letztendlich nur die Kernkomponente: die Event Processing Engine
mit einer entsprechenden EPL. Solche Produkte setzen aber regelmäßig
das Vorhandensein weiterer Software voraus, zum Beispiel Datenbanken, ESB-Implementationen, Application Server etc. Der Anwender
übernimmt die Integration der Event Processing Engine in die vorhandene Architektur dann selbst (zum Beispiel Esper, ruleCore, Open ESB IEP,
Informatica Rulepoint). Andere wiederum sind Komplettlösungen, die
auch Entwicklungsumgebungen, Dashboards, Datenbanken für die
Speicherung historischer Daten, Software für die graphische Regelmodellierung und sogar Reportgeneratoren enthalten, die fast sämtliche
Anforderungen an die Funktionalität von Event Processing abdecken
(zum Beispiel Progress Apama, TIBCO BusinessEvents, Vitria M3O
Analytic Server).
•
Dashboards: Einige Produkte beschränken sich auf die Kernfunktionalität des Event Processing und überlassen die Visualisierung einer entsprechenden Eventsenke, die nicht Teil des Produkts ist (beispielsweise
ruleCore, StreamBase, Starview oder die Open Source-Produkte JBoss
Drools Fusion und Open ESB IEP). Anderen Produkte liefern ausgereifte,
meist webbasierte Dashboards mit entsprechenden Modellierungstools
Fraunhofer IAO
3
Fazit
direkt mit (zum Beispiel Truviso Continuous Analytics, RTM Analyzer,
IBM WebSphere Business Events). Verschiedene Hersteller bieten auch
eine Visualisierungskomponente als eigenständiges Produkt an, welches
gut in eine Architektur mit der Event Processing Engine integriert werden kann (beispielsweise TIBCO BusinessEvents & Spotfire, UC4 Decision
& UC4 Insight, EsperTech Esper & EsperHQ oder Vitria M3O Analytic
Server & M3O Operations Book). Es gibt auch Anbieter, welche die reine
Dashboardlösung RTView von SL für ihr Event Processing Produkte lizensiert haben und auf diese Weise ein Dashboard mit Dashboard Builder
anbieten können (Sybase und Progress Apama).
•
Art und Umfang der EPL: Hier richten sich die Produkte erkennbar an
unterschiedliche Zielgruppen. Viele Event Processing Engines arbeiten
auf der Grundlage einer komplexen Abfragesprache, die eine Vielzahl
von Möglichkeiten zur Definition sehr komplexer Regeln erlaubt. Diese
benötigen im Gegenzug entsprechendes Fachwissen, da die Entwicklung entsprechender Regeln Kenntnisse in der Softwareentwicklung und
die Beherrschung der mitgelieferten IDEs (oft Eclipse-basiert) voraussetzt
(zum Beispiel Sybase Aleri, Microsoft StreamInsight). Andere Produkte
zielen erkennbar auf den Einsatz durch nicht IT-erfahrene Benutzer und
bringen dann entsprechende Werkzeuge mit, die die direkte Programmierung in einer EPL unterstützen (zum Beispiel Assistenten zur Regelgenerierung) oder durch graphische Drag-and-Drop-Modellierung gar
völlig ersetzen (beispielsweise Oracle EDA Suite oder Progress Apama).
•
Zusammenspiel mit Produkten desselben Anbieters: Viele Produkte sind
erkennbar für den Einsatz in einer weitergehenden Architektur desselben Anbieters optimiert und bieten dann entsprechenden Mehrwert
(zum Beispiel TIBCO BusinessEvents, IBM WebSphere Business Events
und Microsoft StreamInsight). Andere wurden für den isolierten Einsatz
optimiert (beispielsweise Progress Apama, RTM Analyzer, EventZero oder
Informatica Rulepoint).
•
Verarbeitungsgeschwindigkeit: Ein besonders bedeutendes Anwendungsgebiet für Event Processing Software ist der automatisierte Handel
mit Wertpapieren (Algorithmic Trading). Dabei kommt es auf eine besonders hohe Verarbeitungsgeschwindigkeit an, da nur dann die Realisierung von Gewinnen möglich ist. Deswegen sind einige Produkte auf
diese Anwendung hin ausgelegt und bieten Reaktionszeiten im
Millisekundenbereich (zum Beispiel Progress Apama, StreamBase). Es
gibt aber auch Produkte, die eher für die Unternehmenssteuerung gedacht sind, nur relativ wenige Daten pro Zeiteinheit verarbeiten müssen
und daher weniger Augenmerk auf die Skalierbarkeit richten (beispielsweise UC4 Decision).
Fraunhofer IAO
77
Abkürzungen
API
ASL
BAM
BPMS
BPEL
CDDL
CEP
CORBA
CRM
CSV
DB
DCOM
EDA
EJB
EPL
ESB
ESP
FTP
GPL
HTML
HTTP
IDE
IMAP
IP
IT
JAXB
JBI
JCA
JDBC
JMS
JMX
JSON
K.A.
ODBC
OPC DA
PDF
POP3
REST
RFID
RMI
RSS
SDK
78
Application Programming Interface
Apache Software License
Business Activity Monitoring
Business Process Management Suite
Business Process Execution Language
Common Development and Distribution License
Common Object Request Broker Architecture
Customer Relationship Management
Comma-Separated Values
Database
Distributed Component Object Model
Event-Driven Architecture
Enterprise JavaBeans
Event Processing Language
Enterprise Service Bus
File Transfer Protocol
General Public License
HyperText Markup Language
HyperText Transfer Protocol
Integrated Development Environment
Internet Message Access Protocol
Internet Protocol
Information Technology
Java Architecture for XML Binding
Java Business Integration
Java EE Connector Architecture
Java Database Connectivity
Java Message Service
Java Management Extensions
JavaScript Object Notation
Keine Angabe
Open Database Connectivity
OPC Data Access
Portable Document Format
Post Office Protocol, Version 3
REpresentational State Transfer
Radio Frequency IDentification
Remote Method Invocation
Really Simple Syndication
Software Development Kit
Fraunhofer IAO
Abkürzungen
SQL
SMS
SMTP
SNMP
SOA
TCP
UDP
XML
Structured Query Language
Short Message Service
Simple Mail Transfer Protocol
Simple Network Management Protocol
Service-Oriented Architecture
Transmission Control Protocol
User Datagram Protocol
eXtensible Markup Language
Fraunhofer IAO
79
Referenzen
[1] B. Seeger: Kontinuierliche Kontrolle - Complex Event Processing: Auswertung von Datenströmen, in: iX, 2010, S. 131-134.
[2] N. Leavitt: Complex-Event Processing Poised for Growth, in: Computer, 42,
2009, S. 17-20.
[3] D. Luckham: The Power of Events - An Introduction to Complex Event
Processing in Distributed Enterprise Systems, Addison-Wesley, Boston,
London, 2002.
[4] M. Eckert und F. Bry: Complex Event Processing (CEP), in: InformatikSpektrum, 32, 2009, S. 163-167.
[5] K.M. Chandy und W.R. Schulte: Event Processing: Designing IT Systems for
Agile Companies, McGraw-Hill, New York, 2010.
[6] R. Bruns und J. Dunkel: Event-Driven Architecture: Softwarearchitektur für
ereignisgesteuerte Geschäftsprozesse, Springer, Berlin, Heidelberg, 2010.
[7] O. Etzion und P. Niblett: Event Processing in Action, Manning, Stamford,
CT, 2010.
[8] D. Luckham und R. Schulte: Event Processing Glossary - Version 1.1, Event
Processing Technical Society, http://www.epts.com/component/option,com_docman/task,doc_download/gid,66/Itemid,
84/, 2008.
[9] B.M. Michelson: Event-Driven Architecture Overview - Event-Driven SOA Is
Just Part of the EDA Story,
http://soa.omg.org/Uploaded%20Docs/EDA/bda2-2-06cc.pdf, 2006.
[10] A. Barros, G. Decker und A. Grosskopf: Complex Events in Business
Processes, in: W. Abramowicz (Hrsg.): Business Information Systems,
Springer, Berlin, Heidelberg, 2007, S. 29-40.
[11] M. Gualtieri und J.R. Rymer: The Forrester Wave™: Complex Event
Processing (CEP) Platforms, Q3 2009,
http://www.forrester.com/rb/Research/wave&trade%3B_complex_event_pr
ocessing_cep_platforms,_q3/q/id/48084/t/2, 2009.
[12] C. Kanaracus: Tibco Beefs up Business Events Processing Wares,
http://www.cio.com/article/450524/Tibco_Beefs_Up_Business_Events_Proc
essing_Wares, 2008.
80
Fraunhofer IAO
F R A U N H O F E R - I N S T I T U T F Ü R ar b eits w irts c haft un d or g anisation iao
Marktübersicht
Real-Time Monitoring Software
Mit Complex Event Processing (CEP) und Event Stream Processing (ESP) stehen
neue Technologien zur Verfügung, mittels derer das Real-Time Monitoring
signifikanter Ereignisse und deren Beziehungen untereinander mit hohen
Verarbeitungsgeschwindigkeiten ermöglicht wird. Somit wird das Auslösen
unmittelbarer Reaktionen auf bestimmte Ereignisse und kritische Zustände nach
dem Push-Prinzip realisierbar.
Die vorliegende Marktübersicht liefert einen Einblick in die Funktionalitäten der
derzeit am Markt verfügbaren Event Processing Tools. Diese bieten neben der
reinen Ereignisverarbeitung in Echtzeit meist auch vielfältige Adapter zur Integration
in die vorliegende IT-Landschaft, Modellierungs- und Analysetools sowie
Dashboards zur visuellen Darstellung. Neben kommerziellen Produkten werden
auch ausgereifte Open Source-Lösungen betrachtet.
ISBN 978-3-8396-0185-3
9 783 839 60 1853
Fraunhofer Verlag
Aufgrund der stetig wachsenden Komplexität und Dynamik in der heutigen Zeit
erfordern viele Unternehmensanwendungen und Prozesse ein hohes Maß an
Transparenz und Agilität. Zudem steigen die Anforderungen nach einer
kontinuierlichen Verarbeitung von internen und externen Daten in Echtzeit und
mit zunehmenden Datenmengen.

Marktübersicht Real-Time Monitoring Software - IAO-Wiki

Transcription

Similar documents

E-Paper - Aboutfleet.ch

Business meets paradise - im Resort Schwielowsee

Mediadaten

hr-software aktuell

Neues-von-NEC-Enterprice-Solutions

zwischen bühne und strandhaus

Fraunhofer IAO - Jahresbericht 2012

- Kultur Cottbus

Mini-Preamp

meeting point - IMEX in Frankfurt

Meraki Systems Manager

JAHRESBERICHT - Fraunhofer FEP - Fraunhofer

Austria Export Nr. 133 - Fachverband der chemischen Industrie

AMA Innovationspreis 2015 - AMA Verband für Sensorik und

Eliciting Requirements for a Company

Polymerase-Kettenreaktion - Gene

Laser Technology

Monitoring Altbausanierung zum Passivhaus