1. F R A U N H O F E R - I N S T I T U T F Ü R A R b E I T S w I R T S c H A F T U N d O R g A N I S AT I O N I A O
Krešimir Vidačković, Thomas Renner, Sascha Rex
Marktübersicht
real-tiMe Monitoring software
n
io
EvENT PROcESSINg TOOlS Im ÜbERblIck
rs
Ve
e
ig
uf
rlä
Vo
2. Krešimir Vidačković
Thomas Renner
Sascha Rex
Marktübersicht Real-Time Monitoring Software
n
io
Event Processing Tools im Überblick
rs
Ve
e
ig
uf
rlä
Vo
3. Autoren
Krešimir Vidačković
Thomas Renner
Sascha Rex
Kontaktadresse
Fraunhofer-Institut für Arbeitswirtschaft und Organisation
Nobelstraße 12
70569 Stuttgart
Telefon: +49 (0) 711/970-51 20
Telefax: +49 (0) 711/970-51 11
E-Mail: XXX
Web-Adresse: XXX
Hinweis auf das Forschungsprojekt iC-RFID
Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums
n
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.
io
Bibliografische Information der Deutschen Nationalbibliothek
rs
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibli-
ografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN: XXX-X-XXXX-XXXX-X
Ve
Druck und Weiterverarbeitung
IRB Mediendienstleistungen
e
Fraunhofer-Informationszentrum Raum und Bau IRB, Stuttgart
ig
Verlag und Druck
Fraunhofer Verlag, Fraunhofer-Informationszentrum Raum und Bau IRB
uf
Postfach 800469, 70504 Stuttgart
Nobelstraße 12, 70569 Stuttgart
Telefon: +49 (0) 711/970-25 00
rlä
Telefax: +49 (0) 711/970-25 08
E-Mail: verlag@fraunhofer.de
Web-Adresse: http://verlag.fraunhofer.de
Vo
Für den Druck des Buches wurde chlor- und säurefreies Papier verwendet.
Copyright 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 Zu-
stimmung des Verlages 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ürf-
ten. 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
4. Inhalt
Abbildungen 4
1 Einführung 5
1.1 Grundlagen 6
1.2 Komponenten von Event Processing Tools 8
n
2 Marktübersicht 14
io
2.1 Vorgehensweise bei der Erstellung der Marktübersicht 14
2.2 Kriterienraster 14
2.3
2.3.1
rs
Produktbeschreibungen
Sybase Aleri Streaming Platform / CEP
16
18
Ve
2.3.2 Progress Apama 21
2.3.3 TIBCO BusinessEvents & Spotfire 24
2.3.4 ruleCore CEP Server 27
e
2.3.5 Truviso Continuous Analytics 29
2.3.6 UC4 Decision & Insight 31
ig
2.3.7 JBoss Drools Fusion 34
2.3.8 Oracle EDA Suite 36
uf
2.3.9 EsperTech Esper 39
2.3.10 Event Zero Event Processing Network 41
rlä
2.3.11 StreamBase Event Processing Platform 44
2.3.12 Open ESB Intelligent Event Processor (IEP) 46
2.3.13 Vitria M3O Analytic Server & M3O Operations Book 48
Vo
2.3.14 Realtime Monitoring RTM Analyzer 51
2.3.15 Informatica Rulepoint 54
2.3.16 Starview Smart Enterprise Platform 56
2.3.17 Microsoft StreamInsight 58
2.3.18 Axway Synchrony Sentinel 60
2.3.19 West Global Vantify Experience Center 62
2.3.20 IBM WebSphere Business Events 64
2.3.21 SL RTView 67
2.4 Tabellarische Übersicht 69
3 Fazit 73
Abkürzungen 75
Referenzen 77
3
5. Abbildungen
Abbildung 1: Grundkomponenten eines Event Processing Systems 11
Abbildung 2: Modellierung mit dem Sybase Aleri Studio 20
Abbildung 3: Entwicklung mit dem Progress Apama Studio 22
Abbildung 4: Modellierung mit dem Progress Apama Dashboard Builder 23
Abbildung 5: Exemplarisches TIBCO Spotfire Dashboard 25
Abbildung 6: Beispielhafte Diagramme mit UC4 Insight 33
Abbildung 7: Entwicklung mit JBoss Drools 35
n
Abbildung 8: Modellierung mit der Oracle EDA Suite 37
Abbildung 9: Exemplarisches Oracle BAM Dashboard 38
io
Abbildung 10: Event Zero Administrations- und Entwicklungstool 42
Abbildung 11: Beispielhaftes Event Zero Dashboard 43
rs
Abbildung 12: Modellierung mit dem StreamBase Studio
Abbildung 13: Elemente für die Entwicklung mit Open ESB IEP
45
47
Ve
Abbildung 14: Modellierung mit dem Vitria M3O Query Modeler 49
Abbildung 15: Beispielhafte Vitria M3O Operations Book Dashboards 50
Abbildung 16: Entwicklung mit dem RTM Analyzer 52
e
Abbildung 17: Exemplarisches RTM Analyzer Dashboard 53
ig
Abbildung 18: Beispielhafter Informatica Rulepoint Alert Manager 55
Abbildung 19: Modellierung mit Starview 57
uf
Abbildung 20: Entwicklung mit Microsoft StreamInsight 59
Abbildung 21: Exemplarische West Global Vantify Dashboards 63
Abbildung 22: Entwicklung mit IBM WebSphere Business Events 65
rlä
Abbildung 23: Beispielhafte Diagramme in IBM WebSphere Business Space 66
Abbildung 24: Modellierung mit dem SL RTView Builder 68
Vo
4
6. 1 Einführung
Die klassische Analyse von Unternehmensdaten erfolgt in der Regel rückwir-
kend. In der Vergangenheit aufgelaufene Daten werden zum Beispiel aus ei-
nem Data Warehouse selektiert und auf die gewünschten Fragestellungen hin
untersucht. Anhand der Ergebnisse können dann entsprechende Konsequen-
zen gezogen werden (vgl. [1]).
Aufgrund seiner Vergangenheitsbezogenheit ist dieses Vorgehen oft unbefrie-
n
digend, da eine zeitnahe Reaktion auf aktuelle Begebenheiten meistens un-
möglich ist. In vielen Anwendungsfällen ist es allerdings erforderlich, zeitkriti-
io
sche Daten in Echtzeit zu verarbeiten, um so auf Ereignisse im Unternehmen
und in der Umwelt rasch reagieren zu können. Beispiele hierfür sind Aktien-
rs
handel, Betrugserkennung, zeitkritische Überwachungssysteme oder Sensor-
netzwerke mit RFID (vgl. [2]).
Ve
Die Echtzeitverarbeitung von relevanten Ereignissen, das so genannte Event
Processing1, wird zwar schon seit Jahrzehnten praktiziert, allerdings wurden
e
hierfür häufig selbst entwickelte Skripte eingesetzt, denen es an Flexibilität und
ig
Standardisierung mangelte (vgl. [1] und [2]). Demgegenüber zielt das in den
letzten Jahren entstandene und stetig wachsende Fachgebiet des Complex
uf
Event Processing (vgl. insbesondere [3]) auf eine kontinuierliche und unmittel-
bare Verarbeitung einer Vielzahl an Ereignissen ab, die methodisch und tech-
nologisch sowie durch den Einsatz dedizierter Softwaretools unterstützt wird,
rlä
so dass die notwendige Systematik im Einsatz möglich wird (vgl. [4]). Im Zuge
der Digitalisierung und Vernetzung in der heutigen Zeit sowie einer einherge-
Vo
henden Explosion von in Echtzeit zu verarbeitenden Datenmengen spielen sol-
che 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 Wis-
senstransfer 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 schnelles Wachstum und noch immer nur ein Bruchteil der potentiellen
1 Im Text werden die in der Fachliteratur gebräuchlichen englischen Begriffe verwendet
2 Weitere Informationen zur Event Processing Technical Society (EPTS) unter http://www.ep-ts.com
5
7. Nutzung im Markt attestiert. Die vorliegende Marktübersicht liefert einen Ein-
blick in die Funktionalitäten dieser Produkte.
Die Marktübersicht entstand im Rahmen des vom Bundesministerium für Wirt-
schaft und Technologie (BMWi) geförderten Verbundprojekts iC-RFID (»Intelli-
gentes Catering mittels Radio Frequency IDentification«), dessen Forschungs-
gegenstand die Integration und Echtzeitsteuerung einer unternehmensüber-
greifenden Prozesskette am Beispiel Luftfahrtcatering mit Hilfe der RFID-
Technologie umfasste. Ein wesentlicher Bestandteil war die Konzeption und
Realisierung eines Real-Time Dashboards, welches den Prozessfluss von mit
RFID-Tags ausgerüsteten Flugzeugtrolleys visualisiert und bei Engpässen auto-
matisierte Benachrichtigungen in Echtzeit erzeugt.
n
io
Die folgenden Abschnitte dieses Kapitels behandeln die Grundlagen von Event
Processing und die wesentlichen Komponenten von Event Processing Tools, um
rs
das Verständnis für die zugrundeliegende Thematik zu vertiefen.
Ve
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 Pro-
e
dukte einzeln und im Detail zu beschreiben. Als Abschluss folgt eine Zusam-
menfassung dieser Produkte und ihrer Funktionalitäten in tabellarischer Form.
ig
Das letzte Kapitel enthält schließlich ein Fazit mit einer Darstellung der wesent-
uf
lichen Erkenntnisse der vorliegenden Marktübersicht.
rlä
1.1 Grundlagen
Vo
Ein Softwaresystem mit einer ereignisgesteuerten Architektur (Event-Driven
Architecture, EDA) unterliegt einem Softwarearchitekturmuster mit lose ge-
koppelten Komponenten, die lediglich mit Hilfe von Ereignissen (Events) in ei-
ner einfachgerichteten Weise miteinander kommunizieren, ohne dabei Wissen
über das Gesamtsystem zu besitzen (vgl. [5]). Ein Event bezeichnet hierbei alles,
was passiert oder von dem erwartet wird, dass es passiert. Für eine automati-
sierte 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 Lesevor-
gangs eines RFID-Sensors (vgl. [8]).
Auf der Grundlage vordefinierter Regeln (Event Processing Rules) können ein-
gehende Events ausgewertet und weiterverarbeitet werden, so dass entweder
mit einer deduktiven Regel ein neues Event generiert wird oder mit einer reak-
tiven Regel eine direkte Reaktion ausgelöst wird. Beispiele für letztere sind et-
wa der Kauf einer bestimmten Anzahl Aktien, sobald der Kurs den gewünsch-
ten Kaufpreis unterschritten hat oder die sofortige Benachrichtigung eines Ver-
6
8. antwortlichen bei einem Transportfehler eines mit einem RFID-Tag ausgerüste-
ten Containers. Als weitere typische Reaktion kann die unmittelbare Interaktion
mit Geschäftsprozessen genannt werden (vgl. [4]).
Der grundlegende Unterschied zu traditionellen Analysesystemen aus dem Da-
tenbankumfeld ist hierbei die Tatsache, dass eingehende Events während ihres
Passierens kontinuierlich anhand der Event Processing Rules ausgewertet wer-
den und Reaktionen unmittelbar in Echtzeit angestoßen werden können (Push-
Prinzip). Somit werden anstatt einmaliger Anfragen zu diskreten Zeitpunkten
gegen eine endliche Datenmenge hier durchgehende Anfragen gegen eine
(konzeptionell) unbegrenzte Eventmenge ausgeführt (vgl. [4]).
n
Man unterscheidet grundsätzlich drei verschiedene Arten von Event Processing
io
(vgl. [9]):
•
rs
Simple Event Processing: Hierbei wird auf ein bestimmtes Einzelevent
eine vordefinierte Reaktion direkt ausgelöst, um Verzögerungszeiten zu
Ve
vermeiden. Wenn beispielsweise ein Lagerverwaltungssystem bei zu
niedrigem Bestand eines Artikels ein entsprechendes Event versendet,
kann darauf unmittelbar mit der Initiierung eines zugehörigen Bestel-
e
lungsprozesses und mit einer Nachricht an einen Verantwortlichen rea-
giert werden.
ig
• Event Stream Processing (ESP): Das System analysiert einen oder mehre-
uf
re zeitlich geordnete Ereignisströme (Event Streams) im Zeitablauf und
versucht dabei, bedeutsame Events und Relationen zwischen Events in
rlä
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 gegebenen-
Vo
falls automatisierte Kauf- oder Verkaufsorders platziert, sowie die Ana-
lyse von RFID Event Streams, bei der als Reaktion auf falsche Transport-
wege beispielsweise entsprechende Alarme versendet werden können.
• Complex Event Processing (CEP): Komplexe Ereignisse (Complex Events)
sind Mengen von Events, die in einem meist temporalen, kausalen oder
räumlichen Zusammenhang stehen, aber nicht zwingend vom gleichen
Ereignistyp sein müssen. Das System analysiert eine so genannte Ereig-
niswolke (Event Cloud), die aus ungeordneten Events besteht, im Hin-
blick auf bestimmte Ereignismuster (Event Patterns) und löst gegebe-
nenfalls Reaktionen aus. Ein Beispiel für CEP ist ein Intrusion Detection
System, das auf Unstimmigkeiten in laufenden Netzwerkzugriffen rea-
gieren kann, indem es Events an verschiedenen Stellen im Netzwerk re-
gistriert und untereinander in Beziehung setzt. Ein weiteres Beispiel ist
die Betrugserkennung bei Kreditkartenbuchungen.
7
9. Event Stream Processing (ESP) und Complex Event Processing (CEP) bauen bei
der Analyse von eingehenden Events im Hinblick auf Event Patterns auf ähnli-
chen Konzepten auf, wobei ESP stärker auf kontinuierliche und (meist zeitlich)
geordnete Ereignisströ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]). Eine nähere Be-
schreibung der Funktionalitäten von Event Processing Systemen und der Erken-
nung von Event Patterns erfolgt in Abschnitt 1.2.
Nach [7] lässt sich die Motivation für die Nutzung von Event Processing Syste-
men grob in folgende Kategorien einordnen:
n
• Überwachung: Feststellung von unerwünschtem Verhalten von Syste-
io
men oder Prozessen und sofortiges Auslösen von Benachrichtigungen,
wobei die Reaktionen den Nachrichtenempfängern überlassen werden
•
rs
Informationsbereitstellung: personalisierte Übermittlung von Informati-
Ve
onen, d.h. die richtige Information zur richtigen Zeit in der richtigen
Granularität an den richtigen Abnehmer
e
• Dynamisches Betriebsverhalten: sofortiges Auslösen von Geschäfts-
ig
transaktionen auf Basis von eingehenden Events
•
uf
Aktive Diagnostik: Problemdiagnose durch Auswertung von Symptomen
als eingehende Events
rlä
• Prognostizierung: Treffen von Vorhersagen auf Basis der bisher einge-
gangenen Events und Verhinderung von vorausgesagten Ereignissen
oder zumindest Abschwächung ihrer Wirkung
Vo
Häufig bestehen die Anforderungen der zu lösenden Geschäftsprobleme in ei-
ner komplexen Fachlogik, großen Datenvolumina, geringen Latenzzeiten, ho-
her Skalierbarkeit und erforderlicher Agilität bzw. einfacher Änderbarkeit der
Anwendung (vgl. [6]). Bei Vorliegen eines oder mehrerer dieser Beweggründe
lohnt sich möglicherweise der Einsatz von Event Processing Tools, deren Kom-
ponenten nachfolgend allgemein beleuchtet werden.
1.2 Komponenten von Event Processing Tools
Im engeren Sinn besteht ein System für das Event Processing aus drei Kompo-
nenten: Ereignisquelle (Event Source), Ereignisverarbeitungskomponente (Event
8
10. Processing Agent) und Ereignissenke (Event Sink), die jeweils durch einen Er-
eigniskanal (Event Channel) miteinander verbunden sind.3 Diese werden im
Folgenden näher beschrieben (vgl. etwa [1], [6] oder [7]):
• Ereignisquelle (Event Source): Jedes Event wird durch eine Ereignis-
quelle generiert und in das System eingebracht. Hierbei kann es sich
beispielsweise um eine Anwendung, verschiedene Sensoren, ein Daten-
banksystem oder einen Geschäftsprozess handeln. Für die Übergabe
über einen Event Channel an einen Event Processing Agent muss das
Event dabei lediglich in eine für diesen verarbeitbare Form gebracht
werden. Die Umwandlung in ein entsprechendes Format übernimmt ein
n
Adapter. Viele Event Processing Tools liefern bereits eine unterschiedli-
che Anzahl an vorgefertigten Adaptern mit oder bieten zumindest die
io
Möglichkeit, eigene Adapter mittels einer Programmierschnittstelle
(Application Programming Interface, API) selbst zu entwickeln.
•
rs
Event Processing Agent: Ein Event Processing Agent ist der Kern jedes
Ve
Event Processing Tools, in dem das Eventmodell der zu verarbeitenden
Events, die Event Processing Rules sowie die Event Processing Engine
zur kontinuierlichen Interpretation dieser Regeln enthalten sind. Hier
e
werden die übergebenen Events z.B. durch Filterung oder Transformati-
ig
on weiterverarbeitet und im Hinblick auf vordefinierte Event Patterns
analysiert (vgl. [6]).
uf
Event Patterns beinhalten beispielsweise logische Operationen (Kon-
junktionen, Disjunktionen oder Negationen), Kardinalitäten, fachliche
rlä
Korrelationen oder zeitliche Beziehungen zwischen verschiedenen
Events. Um endliche Eventmengen analysieren zu können, werden zeit-
liche oder logische Fenster über den eingehenden Events definiert, z.B.
Vo
Events der letzten 2 Minuten oder die letzten 20 Events, und nur die ak-
tuell 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,
3 Im englischen Sprachgebrauch werden verschiedene Synonyme für diese Komponenten benutzt, etwa Event Emitter oder Event
Producer für eine Ereignisquelle, Event Processing Component oder Event Mediator für eine Ereignisverarbeitungskomponente,
Event Consumer für eine Ereignissenke sowie Event Connection, Event Pathway oder Event Topic für einen Ereigniskanal. Bei den
englischen Begriffen beziehen wir uns auf das herausgegebene Glossar der EPTS (vgl. [8]) und deren jeweils erste Nennungen.
9
11. sondern anhand von komplexeren Operationen neue Erkenntnisse aus
diesen ziehen (vgl. [6]).
Sobald eine Event Processing Rule im Hinblick auf ein vorliegendes
Event Pattern greift, können vordefinierte Reaktionen ausgelöst wer-
den, wobei es sich neben dem Senden eines neuen Events auch um
konkrete Aktionen, wie etwa das Versenden von Warnungen, das Aus-
lösen von Alarmen oder den direkten Aufruf von Diensten, handeln
kann.
Die Modellierung der entsprechenden Regeln wird mittels einer Event
Processing Language (EPL) vorgenommen. Bisher hat sich hierfür aller-
n
dings noch kein Standard herausgebildet, so dass jede Engine eine spe-
io
zifische EPL verwendet (vgl. [2]). Grob lassen sich die verschiedenen
Event Processing Languages zumindest in drei Gruppen kategorisieren
(vgl. [4] und [7]):
rs
Ve
- Datenstromorientierte Sprachen: Diese Sprachen basieren auf der
bekannten Datenbankanfragesprache SQL (Structured Query Lan-
guage) und verfolgen das Prinzip, dass Datenströme, in denen
e
Events als Datensätze enthalten sind, in Relationen transformiert
werden, auf denen dann Anfragen zu jedem Zeitpunkt einer dis-
ig
kreten Zeitachse ausgeführt werden. Die Anfrageergebnisse wer-
den anschließend wieder in einen Datenstrom überführt.
uf
- Regelbasierte Sprachen: Der Ursprung dieser Sprachen liegt in
rlä
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
Vo
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.
• Ereignissenke (Event Sink): Die vom Event Processing Agent über ei-
nen Event Channel emittierten Events werden von Ereignissenken emp-
fangen. Hierfür sind wiederum Adapter notwendig, um die Nachrichten
in ein für die Ereignissenke verarbeitbares Format zu übersetzen. Bei-
spiele für Ereignissenken, die allerdings nicht Teil des Event Processing
Tools sein müssen, sind:
- Event Monitor Software: Anzeige der derzeit ablaufenden Events
(zum Beispiel in Form eines Logs)
10
12. - Dashboards: graphische Visualisierung von Events oder Zustän-
den, zum Beispiel mit Hilfe verschiedener Diagramme
- Benachrichtigungsdienste: E-Mail- oder SMS-Nachrichten, die Per-
sonen über bestimmte Events informieren (Notifications bzw.
Alerts)
- Beliebige Dritt-Applikationen: Auslösen von unmittelbaren Reakti-
onen auf relevante Events (zum Beispiel Handelsplattformen, die
basierend auf Kursveränderungen bestimmte automatische
Transaktionen auslösen oder Systeme für die automatisierte Aus-
führung von Geschäftsprozessen)
n
io
- Datenbanken: Speicherung von relevanten Ereignissen für die spä-
tere Auswertung
rs
Häufig werden diese ausgehenden Events von der Event Processing En-
Ve
gine in ein Event Topic auf einem Event Bus veröffentlicht (Publish), für
das sich verschiedene Ereignissenken anmelden können (Subscribe), so
dass durch eine solch lose Kopplung alle relevanten Ereignissenken
e
gleichzeitig über das erkannte Event Pattern informiert werden.
ig
Ein beispielhaftes System für das Event Processing, welches diese Grundkom-
ponenten enthält, wird in Abbildung 1 veranschaulicht (in Anlehnung an [1],
uf
[6] und [7]):
rlä
Abbildung 1: Grund-
komponenten eines
Event Processing
Vo
Systems
Im Kern besteht ein Event Processing Tool aus dem Event Processing Agent und
meist aus verfügbaren Adaptern zu bestimmten Ereignisquellen und -senken.
Daneben bieten die meisten dedizierten Event Processing Tools noch verschie-
dene weitere Komponenten und Funktionalitäten, um ihren Einsatz möglichst
benutzerfreundlich zu gestalten. Die wichtigsten zusätzlichen Komponenten
werden im Folgenden erläutert:
11
13. • Dashboard: Mit Hilfe von Visualisierungsanwendungen können Events
graphisch oder textuell dargestellt werden. Dafür stehen bei den meis-
ten Event Processing Tools in der Regel eine Vielzahl an unterschiedli-
chen Diagrammtypen zur Verfügung, die mit Events verknüpft werden
können und zur Laufzeit per Push-Prinzip aktualisiert werden. Ge-
bräuchlich sind unter anderem Zähler, Torten-, Balken- und Liniendia-
gramme sowie Fortschrittsbalken. Der Benutzer kann sich auf diese
Weise schnell eine Übersicht über das derzeit ablaufende Geschehen
verschaffen. Oft kann der aktuelle Status mit historischen Daten aus Da-
tenbanken angereichert werden, um zusätzliche Informationen zu ge-
winnen. Allerdings enthalten nicht alle Event Processing Tools derartige
n
Visualisierungskomponenten. In diesen Fällen kann eventuell eine vor-
gefertigte Dashboardapplikation eines anderen Anbieters eingesetzt
io
werden, oder die Events werden an eigenentwickelte Lösungen zur Vi-
sualisierung übergeben.
•
rs
Entwicklungs- und/oder Modellierungsumgebung: Viele auf dem
Ve
Markt angebotenen Event Processing Tools enthalten Entwicklungsum-
gebungen für die Formulierung der Event Processing Rules in der jewei-
ligen Event Processing Language (EPL) der verwendeten Laufzeitumge-
e
bung. Teilweise können Regeln sogar graphisch modelliert werden,
ig
welche dann intern in die EPL überführt werden. Einige Lösungen set-
zen ausschließlich auf die Code-basierte Definition von Regeln mittels
uf
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 Plat-
rlä
zierung der Visualisierungselemente und die Verknüpfung ihrer Werte
mit den entsprechenden Events und deren Attributen benutzerfreund-
lich durchgeführt werden können.
Vo
• Analysetools: Mit Hilfe von Reportgeneratoren können Auswertungen
von Events erzeugt werden. Teilweise sehen Event Processing Tools
auch entsprechende Event Datenbanken vor, in denen eine Historie re-
levanter Events abgelegt werden kann. Erzeugte Reports können zum
Teil auf Remotesystemen oder als Dokument im PDF- oder HTML-
Format exportiert werden. Nicht alle Lösungen bieten diese Komponen-
te an, so dass die Events vom Event Processing Agent an externe Appli-
kationen übergeben werden müssen, wenn derartige Analysen durch-
geführt werden sollen.
• Enterprise Service Bus (ESB): Mit Hilfe eines Enterprise Service Bus
(ESB) können Nachrichten zwischen Quelle und Ziel transportiert, trans-
formiert und geroutet werden. Dies können innerhalb einer EDA bei-
spielsweise Events oder vom Event Processing Agent ausgelöste Reakti-
onen sein, aber auch Web Service Aufrufe aus einem automatisierten
12
14. Geschäftsprozess heraus. Viele Event Processing Tools sehen zumindest
die Anbindung an einen ESB vor, um Ereignisse zu lesen und abzuset-
zen. Manche Lösungen bieten sogar eine ESB-Implementation im Rah-
men des Produktes mit an bzw. offerieren diese in ihrer Produktpalette.
Die Anbindung an einen ESB ist für das Event Processing jedoch nicht
zwingend notwendig, Events können auch direkt (zum Beispiel mittels
eines selbstentwickelten Adapters) an den Event Processing Agent oder
eine Ereignissenke gesendet werden.
Je nach Produkt sind mehr oder weniger dieser zusätzlichen Komponenten in
verschiedenen Ausprägungen vorhanden. Die Marktübersicht im nächsten Ka-
pitel liefert einen Überblick über die Funktionalitäten der zur Zeit am Markt be-
n
findlichen Event Processing Tools. Dabei werden sowohl kommerzielle Produk-
io
te betrachtet, als auch konkurrenzfähige Open Source Produkte.
rs
Ve
e
ig
uf
rlä
Vo
13
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.
n
2.1 Vorgehensweise bei der Erstellung der Marktübersicht
io
Die verfügbaren Produkte für das Event Processing wurden durch Online-
Recherche und durch das Studium einschlägiger Fachliteratur identifiziert. An-
rs
schließend wurden diese bezüglich der in Abschnitt 1.2 behandelten Kompo-
nenten und insbesondere des im folgenden Abschnitt spezifizierten
Ve
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.
e
ig
Eine detaillierte Evaluation der Produkte mittels Testinstallationen oder Befra-
gungen der Anbieter war im Rahmen dieser Betrachtung nicht vorgesehen und
uf
wurde daher auch ausdrücklich nicht durchgeführt. Informationen, die nach in-
tensiver Online-Recherche nicht verfügbar waren, bleiben somit auch unbe-
rücksichtigt.
rlä
Die Erstellung der Marktübersicht erfolgte im Zeitraum von Anfang Januar bis
Ende März 2010. Im August 2010 wurde die Marktübersicht überarbeitet.
Vo
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 Proces-
sing Tools basiert:
• Allgemeine Daten zum Anbieter und Produkt:
- Name des Anbieters
- Name des Produktes
- Website
• Vom Produkt unterstützte Betriebssysteme
14
16. • Art von Softwarelizenz, der das Produkt unterliegt (kommerziell oder
Open Source)
• Softwareart des Produktes mit der Unterscheidung in Event Processing
Agent und Komplettsystem, wobei sich letzteres auf das Vorhandensein
zusätzlicher Komponenten über die reine Eventverarbeitung hinaus be-
zieht (siehe auch Abschnitt 1.2)
• Branchenfokus, sofern ein solcher explizit genannt wird
• Verbreitung des Produktes, sofern dazu eine Angabe gemacht werden
n
kann
io
• Referenzkunden, sofern diese genannt werden (gegebenenfalls aus-
zugsweise), wobei vorrangig Unternehmen im deutschsprachigen Raum
aufgeführt werden rs
Ve
• 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 Skalier-
e
barkeit und Verarbeitungsgeschwindigkeit gemacht werden, falls dies
ig
möglich ist; ein besonderer Augenmerk wurde auch auf Art und Um-
fang der mitgelieferten Adapter gelegt, von denen die Wichtigsten auf-
uf
geführt werden
• Sprachtyp der Event Processing Language (EPL), nach den im vorherge-
rlä
henden Abschnitt genannten drei Kategorien:
Vo
- Datenstromorientiert
- Regelbasiert
- Imperativ
• Vorhandensein einer mit den üblichen Funktionalitäten ausgestatteten
integrierten Entwicklungsumgebung (Integrated Development Environ-
ment, 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 entspre-
chend in der textuellen Beschreibung erwähnt wird
• Möglichkeiten für Debugging oder Simulation: das Kriterium gilt als er-
füllt, wenn mindestens die Möglichkeit vorhanden ist, EPL Code in der
15
17. IDE zu debuggen und/oder Testanfragen an den Event Processing Agent
zu senden; manche Lösungen sehen aber auch sehr komplexe Mecha-
nismen zur Durchführung von Simulationen vor, was entsprechend im
Text vermerkt wird
• Vorhandensein einer Konsole (Event Monitor) zur textuellen Darstellung
der vom Event Processing Agent registrierten Events
• Vorhandensein eines Dashboards zur graphischen Visualisierung von
Events in Echtzeit, gegebenenfalls mit der Möglichkeit zur Durchfüh-
rung weiterführender Analysen (zum Beispiel mittels Drill-Down-
n
Funktionalität); sofern angegeben, werden die wichtigsten zur Verfü-
gung gestellten Diagrammtypen in der textuellen Beschreibung aufge-
io
führt
•
rs
Möglichkeit, das Layout und/oder das Verhalten von Dashboards über
eine graphische Benutzeroberfläche zu gestalten, zum Beispiel mittels
Ve
Widgets
• Vorhandensein einer Event Datenbank, in der Events und/oder Alerts
e
gespeichert werden können, zum Beispiel für die spätere Durchführung
ig
von Auswertungen
uf
• Möglichkeit, Events zum Zwecke der Weiterverarbeitung zu exportier-
ten: das Kriterium gilt als erfüllt, wenn mindestens der Export in eine
externe Datenbank oder in eine Datei (zum Beispiel CSV) möglich ist
rlä
• Vorhandensein von Werkzeugen für die Generierung von Reports oder
Vo
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 ESB-
Implementation unterstützt wird
2.3 Produktbeschreibungen
Insgesamt wurden 20 Lösungen betrachtet, die als Mindestanforderung einen
Event Processing Agent enthalten müssen. Aufgrund des Umstands, dass eini-
ge Produkte keine Visualisierungskomponente enthalten, wurde zusätzlich die
Dashboardsoftware RTView in die Betrachtung aufgenommen, da sich in Ver-
bindung mit einem reinen Event Processing Agent damit ein vollständiges Real-
Time Monitoring System realisieren lässt.
16
18. 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:
• Sybase Aleri Streaming Platform / CEP
• Progress Apama
• TIBCO BusinessEvents & Spotfire
• ruleCore CEP Server
• Truviso Continuous Analytics
• UC4 Decision & Insight
• JBoss Drools Fusion
n
• Oracle EDA Suite
•
io
EsperTech Esper
• Event Zero Event Processing Network
•
•
StreamBase Event Processing Platform
rs
Open ESB Intelligent Event Processor (IEP)
Ve
• Vitria M3O Analytic Server & M3O Operations Book
• Realtime Monitoring RTM Analyzer
• Informatica Rulepoint
e
• Starview Smart Enterprise Platform
• Microsoft StreamInsight
ig
• Axway Synchrony Sentinel
• West Global Vantify Experience Center
uf
• IBM WebSphere Business Events
• SL RTView
rlä
Das im Forschungsumfeld häufig erwähnte Event Processing Tool AMiT (Active
Middleware Technology)4 von IBM wird in dieser Marktübersicht nicht unter-
Vo
sucht, da es sich hierbei um ein Forschungsprodukt handelt, zu dem kein Pro-
duktblatt und nur wenig Informationen verfügbar sind.
4 Weitere Informationen unter https://www.research.ibm.com/haifa/dept/services/soms_ebs.html
17
19. 2.3.1 Sybase Aleri Streaming Platform / CEP
Name des Anbieters Sybase
Name des Produktes Aleri Streaming Platform / CEP
Website http://www.aleri.com/products
Unterstützte Betriebssysteme Windows, Linux, Solaris
Lizenztyp Kommerziell
Softwareart Komplettsystem
n
Branchenfokus Keiner, aber Trading, RFID und Cus-
tomer Relationship Management
io
(CRM) explizit genannt
Verbreitung
rsStark verbreitet (vgl. [11] - gemein-
sam mit Coral8, das mittlerweile in
Ve
Sybase CEP übergegangen ist)
Referenzkunden Commerzbank, Barclays, ING
Event Stream Processing Ja
e
Complex Event Processing Ja
ig
EPL Sprachtyp Datenstromorientiert
uf
Entwicklungsumgebung für EPL Ja
rlä
Graphische Modellierungstools für Ja (Aleri Studio) /
EPL Nein (CEP Studio)
Debugging und Simulation Ja
Vo
Event Monitor Ja
Dashboard Ja
Graphische Modellierungstools für Ja
Dashboard
Event Datenbank Nein
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Ja
ESB-Anbindung Ja
18
20. Beschreibung des Event Processing Agents
Sybase hat neben der Aleri Streaming Platform die ehemalige Coral8 CEP-
Engine (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 Messaging-
systeme (z.B. TIBCO Rendezvous, IBM WebSphere MQ und JMS), Datenbanken
(via ODBC und JDBC), Sockets, Dateien, SMTP, XML, CSV und weitere zur Ver-
fügung, insbesondere auch spezielle Adapter für Finanzmarktdaten. Mittels
APIs für C++, Java und .NET können auch eigene Adapter entwickelt werden.
n
Auch Sybase CEP stellt ähnlich viele Adapter zur Verfügung wie die Aleri
io
Streaming Platform. Zudem können ebenfalls eigene Adapter mit C/C++, C#,
Java, Perl und Python entwickelt werden.
rs
Die Verarbeitungsgeschwindigkeit wird mit einigen 100.000 Events (Aleri
Ve
Streaming Platform) bis zu einer Million Events (Sybase CEP) pro Sekunde an-
gegeben. Die Reaktionszeit soll dabei im Millisekundenbereich liegen.
e
Für die Administration steht eine graphische Konsole zur Verfügung.
ig
Beschreibung der Event Processing Language
uf
Für die Aleri Streaming Engine kommt die sogenannte Aleri SQL zum Einsatz,
rlä
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
Vo
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 konti-
nuierliche Datenanfragen. Ein BPEL-to-CCL-Compiler wird für die Verarbeitung
von in BPEL dargestellten Geschäftsprozessen eingesetzt. Für die Entwicklung
steht eine Eclipse-basierte IDE zur Verfügung (Sybase CEP Studio), die aller-
dings keine graphische Modellierung zulässt.
5 Abbildung entnommen aus http://www.sybase.com/files/Data_Sheets/Sybase_Aleri_StreamingPlatform_ds.pdf
19
21. Abbildung 2: Model-
lierung mit dem
Sybase Aleri Studio
n
io
Beschreibung des Dashboards
rs
Ve
Mit Sybase Dashboard, einer auf SL RTView (siehe Abschnitt 2.3.21) basieren-
den Komponente, können individuelle Dashboards graphisch modelliert wer-
den. Es steht eine Vielzahl von verschiedenen graphischen und textuellen Dar-
e
stellungskomponenten zur Verfügung, unter anderem Torten-, Balken- und Li-
niendiagramme. Die Selektion und Filterung von Daten durch den Endbenutzer
ig
ist innerhalb der Anwendung möglich.
uf
rlä
Vo
20
22. 2.3.2 Progress Apama
Name des Anbieters Progress
Name des Produktes Apama
Website http://web.progress.com/en-gb/apama/index.html
Unterstützte Betriebssysteme Windows, Linux, Solaris
Lizenztyp Kommerziell
Softwareart Komplettsystem
n
Branchenfokus Keiner, aber insbesondere für
Trading, Location-Based Services und
io
Logistik geeignet
Verbreitung
rsSehr stark verbreitet, ca. 20% Markt-
anteil bei CEP Software im Jahr 2008
Ve
(vgl. [12])
Referenzkunden Deutsche Bank, ABN Amro, SEB
Event Stream Processing Ja
e
Complex Event Processing Ja
ig
EPL Sprachtyp Imperativ
uf
Entwicklungsumgebung für EPL Ja
rlä
Graphische Modellierungstools für Ja
EPL
Debugging und Simulation Ja
Vo
Event Monitor Ja
Dashboard Ja
Graphische Modellierungstools für Ja
Dashboard
Event Datenbank Ja
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Ja
ESB-Anbindung Ja
21
23. Beschreibung des Event Processing Agents
Die Event Processing Engine wird vom Anbieter als Correlator bezeichnet. Das
Apama Integration Adapter Framework (IAF) stellt die Anbindung der Architek-
tur an Ereignisquellen und -senken sicher. Neben einigen finanzmarktspezifi-
schen 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 ausrei-
chen, können mittels einer API auch individuelle Adapter in Java, C oder C++
entwickelt werden.
n
Die Verarbeitungsgeschwindigkeit des Correlators wird mit mehreren 10.000
io
Events pro Sekunde angegeben, während die Reaktionszeit im Sub-Milli-
sekundenbereich liegen soll. Eine Steigerung der Skalierung ist durch Parallel-
schaltung möglich.
rs
Ve
Für die Administration steht eine graphische Konsole zur Verfügung.
e
Beschreibung der Event Processing Language
ig
Für die Definition von Event Processing Rules wird die imperative Skriptsprache
MonitorScript genutzt. Daneben kann alternativ auch Java verwendet werden.
uf
Mit dem Apama Studio steht eine Eclipse-basierte Entwicklungsumgebung zur
Verfügung, mit der auch eine graphische Modellierung möglich ist (vgl. Abbil-
rlä
dung 36), wobei eine interne Transformation in MonitorScript vorgenommen
wird. Auch werden Debugging- und Profiling-Funktionalitäten bereitgestellt.
Vo
Abbildung 3: Ent-
wicklung mit dem
Progress Apama
Studio
6 Abbildung entnommen aus http://web.progress.com/docs/datasheets/apama/Apama_EventModeler.pdf
22
24. Beschreibung des Dashboards
Mit Hilfe des Apama Dashboard Builders, der auf SL RTView (siehe Abschnitt
2.3.21) basiert, können individuelle Dashboards graphisch modelliert werden.
Es stehen etwa 120 verschiedene Komponenten (zum Beispiel Zähler oder viel-
fä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.
Abbildung 4: Model-
n
lierung mit dem
io
Progress Apama
Dashboard Builder
rs
Ve
e
ig
uf
Beschreibung der Ausgabe und Reportingfunktionen
rlä
Events können in der Datenbank, dem so genannten Event Store, abgelegt und
mit Hilfe der im Research Studio enthaltenen Analysewerkzeuge ausgewertet
Vo
werden.
7 Abbildung entnommen aus http://web.progress.com/en/apama/dashboard-builder.html
23
25. 2.3.3 TIBCO BusinessEvents & Spotfire
Name des Anbieters TIBCO
Name des Produktes BusinessEvents (Event Processing
Agent) & Spotfire (Dashboard)
Website http://www.tibco.com/software/complex-event-
processing/businessevents/default.jsp
Unterstützte Betriebssysteme Windows, Linux, Solaris, HP UX
Lizenztyp Kommerziell
n
Softwareart Komplettsystem
io
Branchenfokus Keiner, aber Produktion, Verkauf,
Verteidigung und Gesundheit explizit
rsgenannt
Ve
Verbreitung Sehr stark verbreitet, ca. 40% Markt-
anteil bei CEP Software im Jahr 2008
(vgl. [12])
e
Referenzkunden Air France, Vodafone, Markant
ig
Event Stream Processing Ja
Complex Event Processing Ja
uf
EPL Sprachtyp Regelbasiert
rlä
Entwicklungsumgebung für EPL Ja
Graphische Modellierungstools für Ja
Vo
EPL
Debugging und Simulation K.A.
Event Monitor Ja
Dashboard Ja (Spotfire)
Graphische Modellierungstools für Ja (Spotfire)
Dashboard
Event Datenbank Ja
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools K.A.
ESB-Anbindung Ja
24
26. Beschreibung des Event Processing Agents
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 Verarbeitungsge-
schwindigkeit parallel geschaltet werden.
Für die Administration steht eine graphische Konsole zur Verfügung.
n
Beschreibung der Event Processing Language
io
Es kommt eine SQL-ähnliche Syntax als Grundlage für die EPL zum Einsatz. As-
rs
sistenten helfen Business Usern bei der Erstellung entsprechender Regeln.
Ve
Beschreibung des Dashboards
e
Mit Hilfe der TIBCO Spotfire Komponente können Events visualisiert werden. Es
handelt sich dabei um eine eigene Analyse- und Visualisierungskomponente,
ig
die allerdings an TIBCO BusinessEvents angebunden werden kann. Es kann da-
bei auf eine Vielzahl an unterschiedlichen Diagrammtypen zurückgegriffen
uf
werden, unter anderem Graphen, Torten-, Balken- und Liniendiagramme, Kar-
ten usw. Die Dashboards können graphisch modelliert werden. Abbildung 58
rlä
zeigt ein exemplarisches TIBCO Spotfire Dashboard.
Abbildung 5: Exemp-
Vo
larisches TIBCO
Spotfire Dashboard
8 Abbildung entnommen aus http://spotfire.tibco.com/products/spotfire-professional/exploratory-data-analysis.aspx
25
27. Beschreibung der Ausgabe und Reportingfunktionen
Events können in einer Datenbank abgelegt werden und damit für beliebige
Auswertungen weiterverwendet werden.
n
io
rs
Ve
e
ig
uf
rlä
Vo
26
28. 2.3.4 ruleCore CEP Server
Name des Anbieters ruleCore
Name des Produktes CEP Server
Website http://www.rulecore.com/
Unterstützte Betriebssysteme K.A.
Lizenztyp Kommerziell
Softwareart Event Processing Agent
n
Branchenfokus Keiner, aber RFID-Anwendungen und
Netzwerküberwachung als mögliche
io
Anwendungsgebiete genannt
Verbreitung
Referenzkunden
rsK.A.
K.A.
Ve
Event Stream Processing Ja
Complex Event Processing Ja
e
EPL Sprachtyp Regelbasiert
ig
Entwicklungsumgebung für EPL Nein
uf
Graphische Modellierungstools für Nein
EPL
rlä
Debugging und Simulation Nein
Event Monitor Nein
Vo
Dashboard Nein
Graphische Modellierungstools für Nein
Dashboard
Event Datenbank Nein
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Nein
ESB-Anbindung Ja
27
29. Beschreibung des Event Processing Agents
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 En-
terprise Service Bus Mule ESB. Die Event Processing Engine kann auf mehrere
Server verteilt werden, so dass eine skalierbare Anwendung möglich ist.
Beschreibung der Event Processing Language
Die von ruleCore verwendete deklarative Abfragesprache Reakt ist eine regel-
n
basierte EPL, die auf XML basiert.
io
rs
Ve
e
ig
uf
rlä
Vo
28
30. 2.3.5 Truviso Continuous Analytics
Name des Anbieters Truviso
Name des Produktes Continuous Analytics
Website http://www.truviso.com/continuous-analytics-
technology.php
Unterstützte Betriebssysteme Linux
Lizenztyp Kommerziell
Softwareart Komplettsystem
n
Branchenfokus Keiner, aber Web Analytics,
io
Advertizing Analytics, Video Analytics
sowie Trading explizit genannt
Verbreitung rs K.A.
Ve
Referenzkunden K.A.
Event Stream Processing Ja
e
Complex Event Processing Nein
ig
EPL Sprachtyp Datenstromorientiert
Entwicklungsumgebung für EPL Ja
uf
Graphische Modellierungstools für K.A.
rlä
EPL
Debugging und Simulation K.A.
Vo
Event Monitor K.A.
Dashboard Ja
Graphische Modellierungstools für Ja
Dashboard
Event Datenbank Ja
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Ja
ESB-Anbindung Nein
29
31. Beschreibung des Event Processing Agents
Als Adapter werden JMS, SOAP, REST, XML, CSV und Textdateien mit Rohda-
ten 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 Verarbeitungsper-
formance von 500.000 Datensätzen pro Sekunde.
Beschreibung der Event Processing Language
n
io
Als Event Processing Language kommt SQL zum Einsatz, die für kontinuierliche
Datenanfragen erweitert wurde, so dass sich Zeit- und Datenfenster auf den
rs
Eventströmen ausdrücken lassen. Kontinuierliche Datenanfragen erzeugen wei-
tere auswertbare Datenströme.
Ve
Beschreibung des Dashboards
e
Das so genannte TruView Framework ermöglicht die Erstellung von anpassba-
ig
ren Dashboards, die als Webanwendungen auf Adobe Flex basieren und an-
hand der kontinuierlichen Datenanfragen in Echtzeit aktualisiert werden.
uf
rlä
Beschreibung der Ausgabe und Reportingfunktionen
Neben der Visualisierung von Daten in einem Dashboard sind auch Alarme in
Vo
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 be-
schrieben.
30
32. 2.3.6 UC4 Decision & Insight
Name des Anbieters UC4
Name des Produktes Decision (Event Processing Agent) &
Insight (Dashboard)
Website http://www.uc4.com/uk/products-solutions/predictive-
pattern-engine/uc4-decision.html
Unterstützte Betriebssysteme Windows
Lizenztyp Kommerziell
n
Softwareart Komplettsystem
io
Branchenfokus Keiner, aber Trading, Produktion,
Logistik und IT-Netzwerke beispielhaft
rs als Anwendungsgebiete genannt
Ve
Verbreitung Stark verbreitet (vgl. [11])
Referenzkunden SBB, T-Systems
Event Stream Processing Ja
e
Complex Event Processing Ja
ig
EPL Sprachtyp Regelbasiert
uf
Entwicklungsumgebung für EPL Ja
rlä
Graphische Modellierungstools für Ja
EPL
Debugging und Simulation Ja
Vo
Event Monitor Ja
Dashboard Ja (Insight)
Graphische Modellierungstools für Ja (Insight)
Dashboard
Event Datenbank Ja
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Ja
ESB-Anbindung Ja
31
33. Beschreibung des Event Processing Agents
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 Da-
teien, 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ög-
lich.
Die Verarbeitungsgeschwindigkeit wird mit mehreren Tausend Events pro Se-
kunde angegeben.
n
io
Für die Administration steht eine graphische Konsole zur Verfügung. Zudem
können vordefinierte Szenarien mit dem Simulation Studio simuliert und getes-
rs
tet werden inklusive der Visualisierung auf einem Real-Time Dashboard.
Ve
Beschreibung der Event Processing Language
e
Das Modelling Studio sieht die graphische Modellierung von Regeln, Event-
strukturen und -korrelationen vor. Die Code-basierte Programmierung in einer
ig
EPL ist nicht vorgesehen.
uf
Beschreibung des Dashboards
rlä
Mit Insight steht ein Real-Time Dashboard zur Verfügung, welches als eigenes
Produkt auch für Business Intelligence und weiterführende Analysen eingesetzt
Vo
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-Event-Tunnel. Beispielhafte Diagramme mit UC4 Insight sind in Abbil-
dung 69 dargestellt.
9 Abbildung entnommen aus http://offer.uc4.com/rs/uc4/images/Web_UC4_Insight_WP_us.pdf
32
35. 2.3.7 JBoss Drools Fusion
Name des Anbieters JBoss
Name des Produktes Drools Fusion
Website http://www.jboss.org/drools/drools-fusion.html
Unterstützte Betriebssysteme Alle mit Java Runtime
Lizenztyp Open Source
Softwareart Event Processing Agent
n
Branchenfokus Keiner, aber Trading und Bezahlsys-
teme als beispielhafte Anwendungs-
io
gebiete genannt
Verbreitung
Referenzkunden
rs Drools 5.0 ca. 2.000 Downloads
K.A.
Ve
Event Stream Processing Ja
Complex Event Processing Ja
e
EPL Sprachtyp Regelbasiert
ig
Entwicklungsumgebung für EPL Ja
uf
Graphische Modellierungstools für Nein
EPL
rlä
Debugging und Simulation Ja
Event Monitor Nein
Vo
Dashboard Nein
Graphische Modellierungstools für Nein
Dashboard
Event Datenbank Nur Anbindung
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Nein
ESB-Anbindung Ja
34
36. Beschreibung des Event Processing Agents
Drools ist eine sogenannte Business Logic Integration Plattform, die als Open
Source Produkt der Apache Software License (ASL) unterliegt. Sie besteht aus
vier Komponeten:
• Guvnor: Knowledge Repository
• Expert: Rule Engine
• Flow: Geschäftsprozessengine
• Fusion: Event Processing Engine
n
Drools Fusion kann zusammen mit den anderen Komponenten verwendet
werden, was allerdings nicht erforderlich ist. Als Adapter steht eine JMS-
io
Anbindung zur Verfügung.
Beschreibung der Event Processing Language
rs
Ve
Die verwendete EPL ist eine deklarative Sprache, die Produktionsregeln auf
Events anwenden kann. Für die Entwicklung der Regeln steht eine Eclipse-
e
basierte IDE zur Verfügung, die in Abbildung 710 dargestellt ist.
ig
Abbildung 7: Ent-
wicklung mit JBoss
uf
Drools
rlä
Vo
10 Abbildung entnommen aus http://www.jboss.org/drools/drools-fusion.html
35
37. 2.3.8 Oracle EDA Suite
Name des Anbieters Oracle
Name des Produktes EDA Suite
Website http://www.oracle.com/us/technologies/soa/eda-
suite/index.html
Unterstützte Betriebssysteme Windows, Linux
Lizenztyp Kommerziell
Softwareart Komplettsystem
n
Branchenfokus Keiner, aber Trading, Telekommuni-
io
kation, Handel, Produktion und Ver-
waltung explizit genannt
Verbreitung rsSehr stark verbreitet (vgl. [11])
Ve
Referenzkunden Monster.com, NH Hotels
Event Stream Processing Ja
e
Complex Event Processing Ja
ig
EPL Sprachtyp Datenstromorientiert
Entwicklungsumgebung für EPL Ja
uf
Graphische Modellierungstools für Ja
rlä
EPL
Debugging und Simulation Ja
Vo
Event Monitor Ja
Dashboard Ja
Graphische Modellierungstools für Ja
Dashboard
Event Datenbank Ja
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Ja
ESB-Anbindung Ja
36
38. Beschreibung des Event Processing Agents
Oracle verwendet die Esper Event Processing 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. Die Antwortzeit
gibt Oracle im Mikrosekundenbereich an.
Für die Administration steht eine graphische Konsole zur Verfügung.
Beschreibung der Event Processing Language
n
io
Die als Oracle Continuous Query Language (CQL) bezeichnete Programmier-
sprache ist SQL-basiert. Eine auf Eclipse aufsetzende Entwicklungsumgebung
rs
wird für die Entwicklung bereitgestellt, mit welcher eine graphische Modellie-
rung der CQL möglich ist (vgl. Abbildung 811). Mit Hilfe von mitgelieferten As-
Ve
sistenten verspricht Oracle eine schnelle Entwicklung EDA-basierter Anwen-
dungen.
e
Abbildung 8: Model-
lierung mit der
ig
Oracle EDA Suite
uf
rlä
Vo
Beschreibung des Dashboards
Der CEP Visualizer dient zur Anzeige von Events und kann sowohl von Entwick-
lern als auch von Administratoren und Endbenutzern verwendet werden. Die
Komponente setzt auf Adobe Flex auf und kann damit über das Web genutzt
werden.
11Abbildung entnommen aus http://www.oracle.com/products/middleware/docs/microsite09-flashmedia-pdfs/complex-event-
processing-datasheet.pdf
37
39. Für das Eventmonitoring selbst bietet Oracle eine Business Activity Monitoring
(BAM) Komponente an, die über vielfältige Möglichkeiten zur Anzeige von
Events verfügt. Sie kann über JMS, JCA oder Web Services angebunden wer-
den. Eine Vielzahl von Diagrammtypen wird unterstützt, unter anderem Torten-
und Balkendiagramme, sowie Zähler. Oracle BAM ist eine webbasierte Anwen-
dung, die Nutzung der BAM-Komponente ist derzeit allerdings nur mit dem
Microsoft Internet Explorer möglich. Abbildung 912 zeigt ein exemplarisches
Oracle BAM Dashboard.
Abbildung 9: Exemp-
larisches Oracle BAM
Dashboard
n
io
rs
Ve
e
ig
Beschreibung der Ausgabe und Reportingfunktionen
uf
Events können in einer Datenbank abgelegt werden und damit für beliebige
Auswertungen weiterverwendet werden.
rlä
Vo
12Abbildung entnommen aus http://www.oracle.com/products/middleware/docs/microsite09-flashmedia-pdfs/oracle-bam-
datasheet.pdf
38
40. 2.3.9 EsperTech Esper
Name des Anbieters EsperTech
Name des Produktes Esper (Event Processing Agent) &
EsperHQ (Dashboard)
Website http://esper.codehaus.org/
Unterstützte Betriebssysteme Windows, Linux, Solaris, AIX
Lizenztyp Open Source (Event Processing
Agent) / Kommerziell (Enterprise Edi-
n
tion und zusätzliche Komponenten)
io
Softwareart Komplettsystem
Branchenfokus Keiner, aber Trading, RFID und CRM
rs explizit genannt
Ve
Verbreitung Stark verbreitet (vgl. [11])
Referenzkunden swisscom, eBay, HypoVereinsbank,
Raytheon
e
Event Stream Processing Ja
ig
Complex Event Processing Ja
uf
EPL Sprachtyp Datenstromorientiert
Entwicklungsumgebung für EPL Ja (Enterprise Edition)
rlä
Graphische Modellierungstools für Nein
EPL
Vo
Debugging und Simulation Ja (Enterprise Edition)
Event Monitor Ja (Enterprise Edition)
Dashboard Ja (Enterprise Edition)
Graphische Modellierungstools für Ja (Enterprise Edition)
Dashboard
Event Datenbank Ja (Enterprise Edition)
Export von Events für statistische Ja (Enterprise Edition)
Zwecke
Auswertungs- und Analysetools Nein
ESB-Anbindung Ja
39
41. Beschreibung des Event Processing Agents
Die Java-basierte Event Processing Engine ist unter einer Open Source Lizenz
(GPL V2) erhältlich und kann somit frei heruntergeladen und verwendet wer-
den. Es ist auch eine Enterprise Edition mit erweiterten Funktionalitäten ver-
fü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).
n
io
Beschreibung der Event Processing Language
rs
Die EPL verwendet eine SQL-ähnliche Syntax. Für die Entwicklung wird eine
Ve
Eclipse Integration bereitgestellt.
e
Beschreibung des Dashboards
ig
Die Dashboardkomponente EsperHQ ist webbasiert und setzt auf Adobe Flex
auf. Mit Hilfe dieser kostenpflichtigen Applikation können so genannte
uf
Eventlets in einer konfigurierbaren Umgebung graphisch dargestellt werden. Es
werden Torten- und Balkendiagramme sowie Zähler und einige andere Dia-
rlä
grammtypen bereitgestellt, die mit Events verbunden werden können. Assis-
tenten unterstützen auf Wunsch bei der Modellierung von Dashboards. Alter-
nativ kann auch ein Code-Editor verwendet werden.
Vo
Beschreibung der Ausgabe und Reportingfunktionen
Events können in eine Datenbank exportiert und für Auswertungszwecke wei-
terverwendet werden.
40
42. 2.3.10 Event Zero Event Processing Network
Name des Anbieters Event Zero
Name des Produktes Event Processing Network
Website http://www.eventzero.com/Solutions/EDA.aspx
Unterstützte Betriebssysteme Windows mit .NET
Lizenztyp Kommerziell
Softwareart Komplettsystem
n
Branchenfokus Keiner
io
Verbreitung K.A.
Referenzkunden K.A.
Event Stream Processing rsJa
Ve
Complex Event Processing Ja
EPL Sprachtyp K.A.
e
Entwicklungsumgebung für EPL Nein
ig
Graphische Modellierungstools für Ja
EPL
uf
Debugging und Simulation Nein
rlä
Event Monitor Ja
Dashboard Ja
Vo
Graphische Modellierungstools für Ja
Dashboard
Event Datenbank Ja
Export von Events für statistische Ja
Zwecke
Auswertungs- und Analysetools Ja
ESB-Anbindung Ja
41