82
FRAUNHOFER-INSTITUT FÜR ARBEITSWIRTSCHAFT UND ORGANISATION IAO MARKTÜBERSICHT REAL-TIME MONITORING SOFTWARE EVENT PROCESSING TOOLS IM ÜBERBLICK Krešimir Vidačković, Thomas Renner, Sascha Rex

Marktübersicht Real-Time Monitoring Software · 2 Fraunhofer IAO Marktübersicht Real-Time Monitoring Software Autoren Krešimir Vidačković, Thomas Renner, Sascha Rex Kontaktadresse

  • Upload
    others

  • View
    8

  • Download
    0

Embed Size (px)

Citation preview

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

Marktübersicht real-tiMe Monitoring softwareEvENT PROcESSINg TOOlS Im ÜbERblIck

Krešimir Vidačković, Thomas Renner, Sascha Rex

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.

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.

FRAUNHOFER vERlAg

ISBN 978-3-8396-0185-3

9 783839 601853

mA

Rk

bE

RS

IcH

T R

EA

l-T

ImE

mO

NIT

OR

INg

SO

FTw

AR

E

Krešimir Vidačković Thomas Renner

Sascha Rex

Marktübersicht Real-Time Monitoring Software Event Processing Tools im Überblick

2

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Autoren Krešimir Vidačković, Thomas Renner, Sascha Rex 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 Wirt-schaft und Technologie (BMWi) unter dem Förderkennzeichen 01MT06006 gefördert. Die Verantwor-tung 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 Gren-zen 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 genom-men oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr für Richtigkeit, Vollständigkeit oder Aktualität übernehmen.

3

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Inhalt

Abbildungen 4 

1  Einführung 5 1.1  Grundlagen 6 1.2  Komponenten von Event Processing Tools 13 

2  Marktübersicht 16 2.1  Vorgehensweise bei der Erstellung der Marktübersicht 16 2.2  Kriterienraster 16 2.3  Produktbeschreibungen 18 2.3.1  Sybase Aleri Streaming Platform / CEP 20 2.3.2  Progress Apama 23 2.3.3  TIBCO BusinessEvents & Spotfire 26 2.3.4  ruleCore CEP Server 29 2.3.5  Truviso Continuous Analytics 31 2.3.6  UC4 Decision & UC4 Insight 33 2.3.7  JBoss Drools Fusion 36 2.3.8  Oracle EDA Suite 38 2.3.9  EsperTech Esper 41 2.3.10  Event Zero Event Processing Network 44 2.3.11  StreamBase Event Processing Platform 47 2.3.12  Open ESB Intelligent Event Processor (IEP) 49 2.3.13  Vitria M3O Analytic Server & M3O Operations Book 51 2.3.14  Realtime Monitoring RTM Analyzer 54 2.3.15  Informatica Rulepoint 57 2.3.16  Starview Smart Enterprise Platform 59 2.3.17  Microsoft StreamInsight 61 2.3.18  Axway Synchrony Sentinel 63 2.3.19  West Global Vantify 65 2.3.20  IBM WebSphere Business Events 67 2.3.21  SL RTView 70 2.4  Tabellarische Übersicht 72 

3  Fazit 76 

Abkürzungen 78 

Referenzen 80 

4

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Abbildungen

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

5

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

1 Einführung

Die klassische Analyse von Unternehmensdaten erfolgt in der Regel rückwir-kend. In der Vergangenheit aufgelaufene Daten werden zum Beispiel aus einem Data Warehouse selektiert und auf die gewünschten Fragestellungen hin unter-sucht. Anhand der Ergebnisse können dann entsprechende Konsequenzen ge-zogen werden (vgl. [1]).

Aufgrund seiner Vergangenheitsbezogenheit ist dieses Vorgehen oft unbefrie-digend, da eine zeitnahe Reaktion auf aktuelle Begebenheiten meistens un-möglich ist. In vielen Anwendungsfällen ist es allerdings erforderlich, zeitkriti-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-handel, Betrugserkennung, zeitkritische Überwachungssysteme oder Sensor-netzwerke 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 unmittel-bare Verarbeitung einer Vielzahl an Ereignissen ab, die methodisch und techno-logisch 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 un-terstreicht nicht zuletzt die Gründung der Event Processing Technical Society (EPTS)2 zu Beginn des Jahres 2008, der die meisten Anbieter von Event Proces-sing Tools sowie Einzelpersonen aus dem Forschungsumfeld angehören und die sich für ein gemeinsames Verständnis, die Entwicklung von Standards und für den Wissenstransfer in diesem Fachgebiet einsetzt (vgl. [6]).

Mehrere ausgereifte Produkte sind bereits auf dem Markt verfügbar, welche für das Real-Time Monitoring in verschiedenen Anwendungen geeignet sind. In [7] wird diesen Event Processing Tools mit einem Verweis auf Analystenberichte ein

1 Im Text werden die in der Fachliteratur gebräuchlichen englischen Begriffe verwendet 2 Weitere Informationen zur Event Processing Technical Society (EPTS) unter http://www.ep-ts.com

1 Einführung

6

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

schnelles Wachstum und noch immer nur ein Bruchteil der potentiellen Nut-zung 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 Wirt-schaft und Technologie (BMWi) geförderten Verbundprojekts iC-RFID (intelli-gentes Catering mittels Radio Frequency IDentification), dessen Forschungsge-genstand die Integration und Echtzeitsteuerung einer unternehmensübergrei-fenden Prozesskette am Beispiel Luftfahrtcatering mit Hilfe der RFID-Technolo-gie 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 aus-löst.

Die folgenden Abschnitte dieses Kapitels behandeln die Grundlagen von Ereig-nis-gesteuerten Architekturen (Event-Driven Architectures, EDA) und Event Pro-cessing 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 an-schließend herangezogen, um die derzeit auf dem Markt befindlichen Produkte einzeln und im Detail zu beschreiben. Als Abschluss folgt eine Zusammenfas-sung dieser Produkte und ihrer Funktionalitäten in tabellarischer Form.

Das letzte Kapitel enthält schließlich ein Fazit mit einer Darstellung der wesent-lichen Erkenntnisse der vorliegenden Marktübersicht.

1.1 Grundlagen

Ein Softwaresystem mit einer Ereignis-gesteuerten Architektur (Event-Driven Architecture, EDA) unterliegt einem Softwarearchitekturmuster mit lose gekop-pelten 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äsen-tiert wird. Beispiele hierfür sind ein Bestellungseingang, eine Aktienwertände-rung oder der Eingang eines Lesevorgangs eines RFID-Sensors (vgl. [8]).

1 Einführung

7

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Neben dem Eventobjekt, das konzeptionell lediglich eine Benachrichtigung dar-stellt und keine direkte Anfrage oder Anweisung, besitzt eine EDA noch fol-gende Elemente (vgl. [6], [7] und [8]):

• Eventquelle (Event Source, auch Event Emitter oder Event Producer)3: Ei-ne Komponente, die aufgrund von erkannten Informationen Eventob-jekte erzeugt und diese an einen angebundenen Eventkanal überreicht, wird als Eventquelle bezeichnet. Diese kennt den Empfänger des Event-objekts, 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 Zeit-punkt 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 ver-schiedene 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 aus-schließ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-Kompo-nente 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.

1 Einführung

8

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

quellen und Eventsenken hinzugefügt werden, ohne dass hierfür das Gesamt-system angepasst werden muss.

Zusammenfassend besitzt eine EDA konzeptionell folgende Eigenschaften (vgl. [5] und [6]):

• Informationen werden durch das Versenden von Eventobjekten berich-tet. Dies geschieht immer zu den Zeitpunkten, an denen das entspre-chende Event auch eingetreten ist.

• Die Kommunikation erfolgt nach dem Push-Prinzip. Im Gegensatz zum Pull-Prinzip, bei dem der Empfänger der Nachricht diese zunächst beim Sender anfragt, geht hier die Initiative von der Eventquelle selbst aus.

• Reaktionen auf Events erfolgen unmittelbar und in Echtzeit, sobald das entsprechende Event eingetroffen ist.

• Die Kommunikation verläuft asynchron und in einfachgerichteter Weise. Wenn die Eventquelle ein Eventobjekt gesendet hat, fährt es mit den weiteren Operationen fort, ohne das Event weiterzuverfolgen oder auf eine Antwort der Eventsenke zu warten.

• Der Austausch von Eventobjekten erfolgt nach dem Publish/Subscribe-Prinzip. Typischerweise publiziert (Publish) eine Eventquelle Events an ei-nen Eventkanal (Middleware). Beliebige Eventsenken können einen be-stimmten Eventtyp abonnieren (Subscribe) und werden bei Eintreffen ei-nes 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 Datenvolumi-na, 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-

1 Einführung

9

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

tereinander auszeichnet und als Complex Event Processing bzw. Event Stream Processing bezeichnet wird.

Hierbei werden auf der Grundlage vordefinierter Regeln (Event Processing Ru-les) eingehende Events ausgewertet und weiterverarbeitet, so dass entweder mit einer deduktiven Regel ein neues Event generiert wird, welches lediglich ei-ne 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 Benachrichti-gung eines Verantwortlichen bei einem Transportfehler eines mit einem RFID-Tag ausgerüsteten Containers. Als weitere typische Reaktion kann die unmittel-bare 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 Event-quelle, wenn neue Events generiert werden.

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]).

Man unterscheidet grundsätzlich drei verschiedene Arten von Event Processing (vgl. [9]):

• Simple Event Processing: Hierbei wird auf ein bestimmtes Einzelevent ei-ne 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 Bestel-lungsprozesses und mit einer Nachricht an einen Verantwortlichen rea-giert werden.

• Event Stream Processing (ESP): Das System analysiert einen oder mehrere zeitlich geordnete Eventströme (Event Streams) im Zeitablauf und ver-sucht dabei, bedeutsame Events und Relationen zwischen Events in die-sen 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-falls automatisierte Kauf- oder Verkaufsorders platziert, sowie die Analy-se von RFID-Eventströmen, bei der als Reaktion auf falsche Transport-wege beispielsweise entsprechende Alarme versendet werden können.

1 Einführung

10

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

• 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 Event-wolke (Event Cloud), die aus ungeordneten Events besteht, im Hinblick auf bestimmte Eventmuster (Event Patterns) und löst gegebenenfalls Re-aktionen 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 Be-trugserkennung bei Kreditkartenbuchungen.

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 Eventströme abzielt, während CEP eher komplexe Operationen über mehrere Events und Eventtypen im Fokus hat. Eine klare konzeptionelle Ab-grenzung 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 Strukturierungs-schichten ergeben: Eventquellen, Eventverarbeitung und Eventbehandlung (vgl. [6]). Diese werden in Abbildung 1 mit entsprechenden Beispielen veranschau-licht (in Anlehnung an [1], [6] und [7]).

Abbildung 1: Logi-sche Strukturierungs-schichten beim Event Processing

EventbehandlungEventquellen Eventverarbeitung

Event Processing Agent

Event Processing Engine

Eventmodelle Eventregeln

In-A

dapt

er

• Verarbeitung von Events

• Erkennung vonEvent Patterns

Out

-Ada

pter

Geschäftsprozesse

… …

Dashboards

Nachrichten

Applikationen

Datenbanken

Datenbanken

Sensoren

Applikationen

Jedes Event wird durch eine Eventquelle generiert und in das System einge-bracht. 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. Auf-grund der Vielfältigkeit der möglichen Eventquellen werden die Eventobjekte im Regelfall auch durch unterschiedliche Eventtypen repräsentiert, so dass diverse

1 Einführung

11

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Adapter erforderlich sind, um diese in der Eventverarbeitungsschicht empfan-gen 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 konti-nuierlichen Interpretation dieser Regeln enthalten sind. Hier werden die über-gebenen 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 Eventmen-gen 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) ab-geleitete Events (Derived Events) erzeugt werden. Durch Abstraktionen mit Hilfe verschiedener Operationen, z.B. Durchschnittsberechnungen, können aggre-gierte 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 Be-zahlungsevents 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 aus-gelöst. Dieses wird entweder für eine Weiterverarbeitung in der Event Proces-sing Engine verwendet (deduktive Regel), was in Abbildung 1 durch den unte-ren Eventfluss zurück in die Event Processing Engine dargestellt wird, oder führt zu einer Reaktion durch eine Komponente der Eventbehandlungsschicht (reak-tive Regel).

Die Modellierung der entsprechenden Event Processing Rules wird mittels einer Event Processing Language (EPL) vorgenommen. Bisher hat sich hierfür aller-dings noch kein Standard herausgebildet, so dass jede Engine eine spezifische EPL verwendet (vgl. [2]).

1 Einführung

12

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Grob lassen sich die verschiedenen Event Processing Languages zumindest in drei Gruppen kategorisieren (vgl. [4] und [7]):

• Datenstromorientierte Sprachen: Diese Sprachen basieren auf der be-kannten Datenbankanfragesprache SQL (Structured Query Language) und verfolgen das Prinzip, dass Datenströme, in denen Events als Daten-sä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 Be-dingung eine vordefinierte Aktion unmittelbar auslöst.

• Imperative Sprachen: Hierbei handelt es sich um spezifische Skriptspra-chen, 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 er-halten (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 Aus-lösen von Alarmen, den Aufruf von Diensten, eine dynamische Anpassung von Geschäftsprozessen oder die Ausführung von Operationen in einer Anwendung handeln.

1 Einführung

13

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Mit solchen Event Processing-Systemen, die in diesem Abschnitt im Detail vor-gestellt 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 Syste-men oder Prozessen und sofortiges Auslösen von Benachrichtigungen, wobei die Reaktionen den Nachrichtenempfängern überlassen werden

• Informationsbereitstellung: personalisierte Übermittlung von Informatio-nen, d.h. die richtige Information zur richtigen Zeit in der richtigen Gra-nularität an den richtigen Abnehmer

• Dynamisches Betriebsverhalten: sofortiges Auslösen von Geschäftstrans-aktionen auf Basis von eingehenden Events

• Aktive Diagnostik: Problemdiagnose durch Auswertung von Symptomen als eingehende Events

• Prognostizierung: Treffen von Vorhersagen auf Basis der bisher einge-gangenen Events und Verhinderung von vorausgesagten Events oder zumindest Abschwächung ihrer Wirkung

Bei Vorliegen eines oder mehrerer dieser Beweggründe lohnt sich möglicher-weise 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 Pro-cessing-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 unter-schiedlichen 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 reali-siert wird. Diese versteht die systemeigene Event Processing Language (EPL), mittels derer die Event Processing Rules definiert werden. Bei vie-len Produkten sind besonders hohe Verarbeitungsgeschwindigkeiten und die Möglichkeit der Skalierung von Event Processing Engines für ei-ne Hochverfügbarkeit vorhanden.

1 Einführung

14

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

• Adapter: Viele Event Processing Tools liefern bereits eine unterschiedli-che Anzahl an vorgefertigten Adaptern mit, damit die Event Processing Engine mit den Eventquellen und den Komponenten der Eventbehand-lung kommunizieren kann. Beispiele sind etwa Adapter für verschiedene Messaging Bus-Systeme, Datenbanken, Web Service-Schnittstellen, Da-teien oder spezielle Anwendungssysteme. Meist besteht auch die Mög-lichkeit, eigene Adapter mittels einer Programmierschnittstelle (Applica-tion Programming Interface, API) selbst zu entwickeln.

• Event Monitor: Die meisten Produkte beinhalten eine Konsole zur einfa-chen 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ön-nen 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ön-nen und zur Laufzeit per Push-Prinzip aktualisiert werden. Gebräuchlich sind unter anderem Zähler, Torten-, Balken- und Liniendiagramme, Ta-chometer, Ampeln und Fortschrittsbalken. Der Benutzer kann sich auf diese Weise schnell eine Übersicht über das derzeit ablaufende Gesche-hen verschaffen. Häufig kann der aktuelle Status auch mit historischen Daten aus Datenbanken angereichert werden, um zusätzliche Informati-onen zu gewinnen. Allerdings enthalten nicht alle Event Processing Tools derartige Visualisierungskomponenten. In diesen Fällen kann even-tuell eine vorgefertigte Dashboardapplikation eines anderen Anbieters eingesetzt werden, oder die Events werden an eigenentwickelte Lösun-gen zur Visualisierung übergeben.

• Entwicklungs- und/oder Modellierungsumgebung: Viele auf dem Markt angebotenen Event Processing Tools enthalten Entwicklungsumgebun-gen 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 aus-schließ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 Vi-sualisierungselemente und die Verknüpfung ihrer Werte mit den ent-sprechenden Events und deren Attributen benutzerfreundlich durchge-führt werden können.

• Auswertungs- und Analysetools: Mit Hilfe von Reportgeneratoren kön-nen Auswertungen von Events erzeugt werden. Teilweise sehen Event Processing Tools auch entsprechende Event Datenbanken vor, in denen

1 Einführung

15

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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 expor-tiert 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, transfor-miert und geroutet werden. Dies können innerhalb einer EDA beispiels-weise Events oder von der Event Processing Engine ausgelöste Reaktio-nen sein, aber auch Web Service Aufrufe aus einem automatisierten Ge-schäftsprozess heraus. Viele Event Processing Tools sehen zumindest die Anbindung an einen ESB vor, um Events zu lesen und abzusetzen. Man-che Lösungen bieten sogar eine ESB-Implementation im Rahmen des Produktes an bzw. offerieren diese in ihrer Produktpalette. Die Anbin-dung 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 Kompo-nenten 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 kommer-zielle Produkte betrachtet, als auch konkurrenzfähige Open Source-Produkte.

16

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

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 Über-sicht zusammengefasst.

2.1 Vorgehensweise bei der Erstellung der Marktübersicht

Die verfügbaren Produkte für das Event Processing wurden durch Online-Recherche und durch das Studium einschlägiger Fachliteratur identifiziert. An-schließend wurden diese bezüglich der in Abschnitt 1.2 behandelten Kompo-nenten 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ühr-licher Befragungen der Anbieter war im Rahmen dieser Betrachtung nicht vor-gesehen und wurde daher auch ausdrücklich nicht durchgeführt. Informatio-nen, 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:

- Name des Anbieters - Name des Produktes - Website

• Vom Produkt unterstützte Betriebssysteme

2 Marktübersicht

17

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

• 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 be-zieht (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 aus-zugsweise), 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 Skalier-barkeit und Verarbeitungsgeschwindigkeit gemacht werden, falls dies möglich ist; ein besonderer Augenmerk wurde auch auf Art und Um-fang der mitgelieferten Adapter gelegt, von denen die Wichtigsten auf-geführt werden

• Sprachtyp der Event Processing Language (EPL), nach den im vorherge-henden Abschnitt genannten drei Kategorien:

- 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 entsprechend 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

2 Marktübersicht

18

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

IDE zu debuggen und/oder Testanfragen an die Event Processing Engine 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 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-Down-Funktionalität); sofern angegeben, werden die wichtigsten zur Verfü-gung gestellten Diagrammtypen in der textuellen Beschreibung aufge-fü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 ge-speichert werden können, zum Beispiel für die spätere Durchführung von Auswertungen

• Möglichkeit, Events zum Zwecke der Weiterverarbeitung zu exportier-ten: das Kriterium gilt als erfüllt, wenn mindestens der Export in eine ex-terne 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 ESB-Implementation unterstützt wird

2.3 Produktbeschreibungen

Insgesamt wurden 20 Lösungen betrachtet, die als Mindestanforderung eine Event Processing Engine 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 einer reinen Event Processing Engine damit ein vollständiges Real-Time Monitoring System realisieren lässt.

2 Marktübersicht

19

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Folgende Produkte wurden untersucht, wobei sich die Reihenfolge aus einer al-phabetischen 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 & 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

Das im Forschungsumfeld häufig erwähnte Event Processing Tool AMiT (Active Middleware Technology)4 von IBM wird in dieser Marktübersicht nicht unter-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

2 Marktübersicht

20

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

2.3.1 Sybase Aleri Streaming Platform / CEP

Name des Anbieters Sybase

Name des Produktes Aleri Streaming Platform / CEP

Website http://www.sybase.com/products/financialservicessolutions/complex-event-processing

Unterstützte Betriebssysteme Windows, Linux, Solaris

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Keiner, aber Financial Services Soluti-on, RFID, CRM und Telekommunikati-on 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 Datenstromorientiert

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)

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Nein

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

21

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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.

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 ange-geben. Die Reaktionszeit soll dabei im Millisekundenbereich liegen.

Für die Anwendung auf dem Kapitalmarkt ist eine Integration mit der Marktda-tenplattform 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 konti-nuierliche 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

2 Marktübersicht

22

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

steht eine Eclipse-basierte IDE zur Verfügung (Sybase CEP Studio), die allerdings keine graphische Modellierung vorsieht.

Abbildung 2: Model-lierung 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 gra-phisch modelliert werden. Es steht eine Vielzahl von verschiedenen graphischen und textuellen Darstellungskomponenten zur Verfügung, unter anderem Tor-ten-, 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 exter-nen Funktionen als In-Memory-Datenbank genutzt werden kann. Der Zugriff auf die Datenströme erfolgt dabei über JDBC und ODBC.

2 Marktübersicht

23

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.2 Progress Apama

Name des Anbieters Progress

Name des Produktes Apama

Website http://web.progress.com/de/apama/index.html

Unterstützte Betriebssysteme Windows, Linux, Solaris

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Keiner, aber insbesondere für Trading, Location-Based Services und Logistik geeignet

Verbreitung Sehr stark verbreitet, ca. 20% Markt-anteil bei CEP Software im Jahr 2008 (vgl. [12])

Referenzkunden Deutsche Bank, ABN Amro, SEB

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Imperativ

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Ja (SL RTView lizenziert)

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

24

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

Die Event Processing Engine wird vom Anbieter als Correlator bezeichnet. Das Apama Integration Adapter Framework (IAF) stellt die Anbindung der Architek-tur 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 ausrei-chen, 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-Milli-sekundenbereich liegen soll. Eine Steigerung der Skalierung ist durch Parallel-schaltung möglich.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

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. Abbil-dung 36), wobei eine interne Transformation in MonitorScript vorgenommen wird. Auch werden Debugging- und Profiling-Funktionalitäten bereitgestellt.

Abbildung 3: Ent-wicklung mit dem Progress Apama Studio

6 Abbildung entnommen aus http://web.progress.com/docs/datasheets/apama/Apama_EventModeler.pdf

2 Marktübersicht

25

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung des Dashboards

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 Bei-spiel 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 beispiel-haftes Apama Dashboard ist in Abbildung 47 dargestellt.

Abbildung 4: Model-lierung mit dem Progress Apama Dashboard Builder

Beschreibung der Ausgabe und Reportingfunktionen

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

2 Marktübersicht

26

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

2.3.3 TIBCO BusinessEvents & Spotfire

Name des Anbieters TIBCO

Name des Produktes BusinessEvents (Event Processing En-gine) & Spotfire (Dashboard)

Website http://www.tibco.com/products/business-optimization/complex-event-processing/businessevents

Unterstützte Betriebssysteme 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% Markt-anteil bei CEP Software im Jahr 2008 (vgl. [12])

Referenzkunden Air France, Vodafone, Markant

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation K.A.

Event Monitor Ja

Dashboard Ja (Spotfire)

Graphische Modellierungstools für Dashboard

Ja (Spotfire)

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools K.A.

ESB-Anbindung Ja

2 Marktübersicht

27

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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.

Beschreibung der Event Processing Language

Es kommt eine SQL-ähnliche Syntax als Grundlage für die EPL zum Einsatz. As-sistenten helfen Business Usern bei der Erstellung entsprechender Regeln.

Beschreibung des Dashboards

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 da-bei auf eine Vielzahl an unterschiedlichen Diagrammtypen zurückgegriffen werden, unter anderem Graphen, Torten-, Balken- und Liniendiagramme, Kar-ten usw. Die Dashboards können graphisch modelliert werden. Abbildung 58 zeigt ein exemplarisches TIBCO Spotfire Dashboard.

Abbildung 5: Exemp-larisches TIBCO Spotfire Dashboard

8 Abbildung entnommen aus http://spotfire.tibco.com/products/spotfire-professional/exploratory-data-analysis.aspx

2 Marktübersicht

28

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Ausgabe und Reportingfunktionen

Events können in einer Datenbank abgelegt werden und damit für beliebige Auswertungen weiterverwendet werden.

2 Marktübersicht

29

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.4 ruleCore CEP Server

Name des Anbieters ruleCore

Name des Produktes CEP Server

Website http://www.rulecore.com/

Unterstützte Betriebssysteme Alle (Software as a Service)

Lizenztyp Kommerziell

Softwareart Event Processing Engine

Branchenfokus Keiner, aber Mobile Asset Tracking (Tracking von Fahrzeugen, GPS-Geräten und Handys) als wichtiges Anwendungsgebiet genannt

Verbreitung K.A.

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL Nein

Graphische Modellierungstools für EPL

Nein

Debugging und Simulation Ja

Event Monitor Nein

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank Nein

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Nein

ESB-Anbindung Ja

2 Marktübersicht

30

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

Die Nutzung des ruleCore CEP Servers wird als Dienst über das Internet (Soft-ware 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ämt-liche 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.

Beschreibung der Event Processing Language

Die von ruleCore verwendete deklarative Abfragesprache Reakt ist eine regelba-sierte EPL, die auf XML basiert. Eine Entwicklungsumgebung ist nicht vorgese-hen, allerdings vertreibt ruleCore unter dem Namen FleetNotice eine Lösung für das Echtzeit-Tracking von Fahrzeugflotten, die auf dem ruleCore CEP Server ba-siert und eine webbasierte Benutzerschnittstelle für die Regeldefinition basie-rend auf Formularen bereitstellt. Diese kann auch generisch für die Erstellung von Event Processing Rules für den ruleCore CEP Server genutzt werden.

2 Marktübersicht

31

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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

Branchenfokus Keiner, aber Web Analytics, Advertizing Analytics, Video Analytics sowie Trading explizit genannt

Verbreitung K.A.

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Nein

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

K.A.

Debugging und Simulation K.A.

Event Monitor K.A.

Dashboard Ja

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Nein

2 Marktübersicht

32

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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

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 wei-tere auswertbare Datenströme.

Beschreibung des Dashboards

Das so genannte TruView Framework ermöglicht die Erstellung von anpassba-ren Dashboards, die als Webanwendungen auf Adobe Flex basieren und an-hand der kontinuierlichen Datenanfragen in Echtzeit aktualisiert werden.

Beschreibung der Ausgabe und Reportingfunktionen

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 be-schrieben.

2 Marktübersicht

33

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.6 UC4 Decision & UC4 Insight

Name des Anbieters UC4 Software

Name des Produktes UC4 Decision (Event Processing En-gine) & UC4 Insight (Dashboard)

Website http://www.uc4.com/de/produkte-loesungen/predictive-pattern-engine/uc4-decision.html

Unterstützte Betriebssysteme Windows

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Keiner, aber Intelligent Service Auto-mation, Application Performance As-surance und Service Level Manage-ment beispielhaft als Anwendungsge-biete genannt

Verbreitung Stark verbreitet (vgl. [11])

Referenzkunden SBB, T-Systems

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Ja (UC4 Insight)

Graphische Modellierungstools für Dashboard

Ja (UC4 Insight)

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

34

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

UC4 Decision besitzt eine skalierbare Event Processing Engine. Adapter sind für MSMQ (Microsoft Message Queuing Service), IBM WebSphere MQ, TIBCO Ren-dezvous, 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 Se-kunde angegeben.

Für die Administration steht eine graphische Konsole zur Verfügung. Zudem können vordefinierte Szenarien mit dem Simulation Studio simuliert und getes-tet werden inklusive der Visualisierung auf einem Real-Time Dashboard.

Beschreibung der Event Processing Language

Das Modelling Studio sieht die graphische Modellierung von Regeln, Event-strukturen und -korrelationen vor. Die Code-basierte Programmierung in einer EPL ist nicht vorgesehen. Abbildung 6 zeigt beispielhaft die Modellierungsum-gebung von UC4 Decision.

Abbildung 6: Model-lierung mit UC4 Decision

2 Marktübersicht

35

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung des Dashboards

Mit UC4 Insight steht ein Real-Time Dashboard zur Verfügung, welches als ei-genständiges Produkt auch für Business Intelligence und weiterführende Analy-sen, 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 Treppendia-grammen auch Visualisierungsmöglichkeiten für Event-Cluster und 3D-Event-Tunnel. Die beispielhafte Darstellung eines Event Tunnels mit UC4 Insight ist in Abbildung 7 dargestellt.

Abbildung 7: Bei-spielhafte Event Tunnel-Darstellung mit UC4 Insight

2 Marktübersicht

36

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

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 Engine

Branchenfokus Keiner, aber Trading und Bezahlsys-teme als beispielhafte Anwendungs-gebiete genannt

Verbreitung Drools 5.0 ca. 2.000 Downloads

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Nein

Debugging und Simulation Ja

Event Monitor Nein

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank Nur Anbindung

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Nein

ESB-Anbindung Ja

2 Marktübersicht

37

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 Pro-cessing 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 Apa-che 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 beispiels-weise 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.

Beschreibung der Event Processing Language

Die verwendete EPL ist eine deklarative Sprache, die Produktionsregeln auf Events anwenden kann. Für die Entwicklung der Regeln steht eine Eclipse-basierte IDE zur Verfügung, die in Abbildung 89 dargestellt ist.

Abbildung 8: Ent-wicklung mit JBoss Drools

9 Abbildung entnommen aus http://www.jboss.org/drools/drools-fusion.html

2 Marktübersicht

38

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

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, Solaris, HP-UX, AIX

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Keiner, aber Trading, Telekommunika-tion, Handel, Produktion und Verwal-tung explizit genannt

Verbreitung Sehr stark verbreitet (vgl. [11])

Referenzkunden Monster.com, NH Hotels

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Ja

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

39

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

Oracle CEP basierte ehemals auf der Esper Event Processing Engine, verwendet mittlerweile aber eine eigene Engine. Als Adapter werden JMS und HTTP so-wohl für eingehende als auch ausgehende Events unterstützt. Eine Datenbank-anbindung 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.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

Die als Oracle Continuous Query Language (CQL) bezeichnete Programmier-sprache ist SQL-basiert. Eine auf Eclipse aufsetzende Entwicklungsumgebung wird für die Entwicklung bereitgestellt, mit welcher eine graphische Modellie-rung der CQL möglich ist (vgl. Abbildung 910). Mit Hilfe von mitgelieferten As-sistenten verspricht Oracle eine schnelle Entwicklung EDA-basierter Anwendun-gen.

Abbildung 9: Model-lierung mit der Oracle EDA Suite

10 Abbildung entnommen aus http://download.oracle.com/docs/cd/E14571_01/doc.1111/e14476/overview.htm

2 Marktübersicht

40

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

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.

Für ein weiterführendes Monitoring bietet Oracle eine Komponente für Busi-ness Activity Monitoring (BAM) an, die über vielfältige Möglichkeiten zur An-zeige von Events verfügt. Sie kann über JMS, JCA oder Web Services angebun-den 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 exemplari-sches Oracle BAM Dashboard.

Abbildung 10: Exemplarisches Oracle BAM Dash-board

Beschreibung der Ausgabe und Reportingfunktionen

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

2 Marktübersicht

41

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.9 EsperTech Esper

Name des Anbieters EsperTech

Name des Produktes Esper (Event Processing Engine) & EsperHQ (Dashboard)

Website http://esper.codehaus.org/

Unterstützte Betriebssysteme Windows, Linux, Solaris, AIX

Lizenztyp Open Source (Event Processing Engi-ne) / Kommerziell (Enterprise Edition und zusätzliche Komponenten)

Softwareart Komplettsystem

Branchenfokus Keiner, aber Trading, RFID und CRM explizit genannt

Verbreitung Stark verbreitet (vgl. [11])

Referenzkunden ActiveEndpoints, AeroScout, Swiss-com

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja (Enterprise Edition)

Graphische Modellierungstools für EPL

Ja (Enterprise Edition)

Debugging und Simulation Ja (Enterprise Edition)

Event Monitor Ja (Enterprise Edition)

Dashboard Ja (Enterprise Edition)

Graphische Modellierungstools für Dashboard

Ja (Enterprise Edition)

Event Datenbank Ja (Enterprise Edition)

Export von Events für statistische Zwecke

Ja (Enterprise Edition)

Auswertungs- und Analysetools Nein

ESB-Anbindung Ja

2 Marktübersicht

42

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 verfüg-bar. 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).

Beschreibung der Event Processing Language

Die EPL verwendet eine SQL-ähnliche Syntax. In der Open Source-Variante ist keine eigene Entwicklungsumgebung für die Erstellung der Statements vorge-sehen. Die Enterprise Edition hingegen bietet eine Formular-basierte Design-komponente, einen Expression Builder sowie eine graphische Komponente zur Darstellung von definierten Event Processing Rules und derer Abhängigkeiten.

Beschreibung des Dashboards

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: Bei-spielhaftes 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

2 Marktübersicht

43

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

tifizierten Events im Zeitablauf, bereitgestellt, die mit Events verbunden werden können. Assistenten unterstützen auf Wunsch bei der Modellierung von Dash-boards. Alternativ kann auch ein Code-Editor verwendet werden.

Beschreibung der Ausgabe und Reportingfunktionen

In der Enterprise Edition bietet Esper einen JDBC Server Endpoint an, so dass von beliebigen Analyse- und Reportinganwendungen in Echtzeit auf die konti-nuierlichen Eventabfragen bzw. Eventströme zugegriffen werden kann. Dies ist sowohl lokal als auch per Remote-Zugriff möglich.

2 Marktübersicht

44

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

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 Alle mit Java Runtime

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Keiner

Verbreitung K.A.

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp K.A.

Entwicklungsumgebung für EPL Nein

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Ja

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

45

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

Event Zero stellt mehr als 60 mitgelieferte Adapter zur Verfügung, mit denen Events an die Event Processing Engine übergeben werden können. Neben ver-schiedenen ESB-Implementationen (TIBCO Rendezvous, IBM WebSphere MQ, Progress SonicMQ, Apache ActiveMQ, JBoss ESB, Mule, JMS) und Internet-Protokollen (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.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

Die Regeln werden mit einem Assistenten definiert (vgl. Abbildung 1213). Eine direkte, Code-basierte Definition von Regeln ist nicht vorgesehen.

Abbildung 12: Event Zero Administrations- und Entwicklungs-tool

Beschreibung des Dashboards

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

2 Marktübersicht

46

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Analyse historischer Daten vorgenommen werden, wobei mittels Drill-Down-Analysen die Aggregationsstufe variiert werden kann.

Die Gestaltung von Dashboards erfolgt über Widgets, wobei folgende Dia-grammtypen für die Visualisierung von Events bereitgestellt werden: Fort-schrittsbalken, Zähler, Linien-, Punkt- und Balkendiagramme.

Die Darstellung erfolgt in einem Webbrowser. Abbildung 1314 stellt ein bei-spielhaftes Event Zero Dashboard dar.

Abbildung 13: Bei-spielhaftes Event Zero Dashboard

Beschreibung der Ausgabe und Reportingfunktionen

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

2 Marktübersicht

47

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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

Unterstützte Betriebssysteme Windows, Linux

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Fokus auf Trading und Verteidigung, Produkt aber auch für andere Zwecke einsetzbar

Verbreitung Stark verbreitet (vgl. [11])

Referenzkunden BNY ConvergEx Group

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Nein

ESB-Anbindung Ja

2 Marktübersicht

48

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 Mic-rosoft Excel möglich.

Die Verarbeitungsgeschwindigkeit wird mit etwa 500.000 Events pro Sekunde angegeben. Die Simulation von Events (zum Beispiel zur Fehlersuche) ist mög-lich.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

Die StreamSQL genannte EPL von StreamBase setzt auf SQL auf. Für die Ent-wicklung steht eine Eclipse-basierte IDE zur Verfügung. StreamBase Studio er-laubt neben der Code-basierten Entwicklung auch die graphische Modellierung von Regeln und Abfragen mit StreamSQL EventFlow (vgl. Abbildung 1415). Ein Debugger ist ebenfalls enthalten.

Abbildung 14: Mo-dellierung mit dem StreamBase Studio

15 Abbildung entnommen aus http://www.streambase.com/products-StreamBaseStudio.htm

2 Marktübersicht

49

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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

Unterstützte Betriebssysteme Alle mit Java Runtime

Lizenztyp Open Source

Softwareart Event Processing Engine

Branchenfokus Keiner

Verbreitung K.A.

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja (NetBeans IDE)

Graphische Modellierungstools für EPL

Ja (NetBeans IDE)

Debugging und Simulation Nein

Event Monitor Nein

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank Ja (Java DB)

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Nein

ESB-Anbindung Ja

2 Marktübersicht

50

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 Anbin-dungen verwendet werden, unter anderem JMS, SOAP, XML, HTTP, FTP und JBI.

Beschreibung der Event Processing Language

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: Ele-mente für die Ent-wicklung mit Open ESB IEP

16 Abbildung entnommen aus https://open-esb.dev.java.net/kb/60/ep-iepse-devguide.html

2 Marktübersicht

51

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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/m3o-analytic-server/

Unterstützte Betriebssysteme Windows, Linux, Solaris, HP-UX

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Keiner, aber Verbreitung in Telekom-munikation, Energie und Versorger, Finanzdienstleistungen und Versiche-rungen

Verbreitung K.A.

Referenzkunden TXU Energy, R Cable Galicia, Andorra Telecom

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Ja (M3O Operations Book)

Graphische Modellierungstools für Dashboard

Ja (M3O Operations Book)

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

52

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

Als Bestandteil der Vitria M3O (Model, Manage, Monitor and Optimize) Opera-tional 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 XML-Format vorliegenden Events. Adapter werden unter anderem für JMS und Web Services bereitgestellt. Die Anbindung von Datenbanken, RSS-Feeds oder Sen-sordaten ist ebenfalls möglich. Zur Erhöhung der Skalierbarkeit ist der Feed Ser-ver von der eigentlichen Event Processing Engine architektonisch getrennt. Events können an den M3O BPMS Server oder an beliebige Dritt-Applikationen weitergegeben werden.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

Die Abfragesprache des M3O Analytic Server heißt StreamXQuery und verwen-det 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).

Abbildung 16: Mo-dellierung mit dem Vitria M3O Query Modeler

17 Abbildung entnommen aus http://www.vitria.com/wp-content/download/Complex%20Event%20Processing%20for%20Operational%20Intelligence_3_16_10.pdf

2 Marktübersicht

53

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung des Dashboards

M3O Operations Book ist die Dashboardkomponente der M3O Operational Intelligence Software Suite. Als webbasierte Anwendung basiert M3O Operati-ons Book auf Adobe Flex. Einige Templates für oft benötigte Diagramme wer-den 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: Bei-spielhafte Vitria M3O Operations Book Dashboards

18 Abbildung entnommen aus http://www.vitria.marketbright.com/resources/brochures-and-data-sheets/vitria_m3o_opsbook_ds_1_09.pdf

2 Marktübersicht

54

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

2.3.14 Realtime Monitoring RTM Analyzer

Name des Anbieters Realtime Monitoring GmbH

Name des Produktes RTM Analyzer

Website http://www.realtime-monitoring.de/index.php/de/leistungen/rtm-analyzer

Unterstützte Betriebssysteme Alle mit Java Runtime

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

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation K.A.

Event Monitor Ja

Dashboard Ja

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Nein

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

55

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 eige-ne Adapter implementiert werden.

Die Verarbeitungsgeschwindigkeit des RTM Analyzers wird mit einigen 100.000 Events pro Sekunde angegeben.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

Die Abfrage von Events erfolgt durch SQL-Statements, die von der Event Pro-cessing Engine kontinuierlich ausgeführt werden. Dafür steht ein Query Editor zur Verfügung (vgl. Abbildung 1819). Alternativ besteht die Möglichkeit, Abfra-gen durch ein graphisches Interface zu modellieren.

Abbildung 18: Ent-wicklung mit dem RTM Analyzer

Beschreibung des Dashboards

Events können in konfigurierbaren Dashboards (Management Cockpits) darge-stellt werden. Abbildung 1920 zeigt ein exemplarisches Dashboard.

19 Abbildung entnommen aus http://www.realtime-monitoring.de/pdfs/Manufacturing_Demo_RTM_EN.pdf 20 Abbildung entnommen aus http://www.realtime-monitoring.de/pdfs/WhitePaper_RTM_Analyzer_EN.pdf

2 Marktübersicht

56

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Abbildung 19: Exemplarisches RTM Analyzer Dashboard

Beschreibung der Ausgabe und Reportingfunktionen

Daten können an Datenbanken oder externe Anwendungen übergeben wer-den.

2 Marktübersicht

57

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.15 Informatica Rulepoint

Name des Anbieters Informatica

Name des Produktes Rulepoint

Website http://www.informatica.com/de/products_services/rulepoint_operational_intelligence/Pages/index.aspx

Unterstützte Betriebssysteme Windows, Linux, Solaris

Lizenztyp Kommerziell

Softwareart Event Processing Engine

Branchenfokus Keiner, aber Trading, Bezahlsysteme und Verteidigung als Anwendungs-gebiete beispielhaft genannt

Verbreitung K.A.

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

58

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 ge-schrieben werden.

Für die Administration steht eine graphische Konsole zur Verfügung. Die Dar-stellung erfolgt im Webbrowser. Endbenutzer können über die Konsole auch weitere Analysen in den berichteten Events (zum Beispiel Drill-Down) vorneh-men. Historische und Echtzeitdaten können in die Analysen einbezogen wer-den. In Abbildung 2021 ist ein beispielhafter Real-Time Alert Manager darge-stellt. Eine Visualisierungskomponente in Form eines Dashboards ist allerdings nicht vorhanden.

Abbildung 20: Bei-spielhafter Informatica Rulepoint Alert Manager

Beschreibung der Event Processing Language

Die Definition von Event Processing Rules wird entweder mittels einer regelba-sierten 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

2 Marktübersicht

59

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.16 Starview Smart Enterprise Platform

Name des Anbieters Starview Technology

Name des Produktes Smart Enterprise Platform

Website http://www.starviewtechnology.com/starview-products.html

Unterstützte Betriebssysteme Windows, Linux, Solaris

Lizenztyp Kommerziell

Softwareart Event Processing Engine

Branchenfokus Keiner

Verbreitung K.A.

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL Ja

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

60

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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ön-nen parallel geschaltet werden.

Der Simulation Server kann sowohl mit Echtzeitdaten, als auch mit historischen Daten verwendet werden.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

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: Mo-dellierung mit Starview

22 Abbildung entnommen aus http://www.starviewtechnology.com/documents/Starview%20Solutions%20White%20Paper.pdf

2 Marktübersicht

61

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.17 Microsoft StreamInsight

Name des Anbieters Microsoft

Name des Produktes StreamInsight

Website http://www.microsoft.com/sqlserver/2008/en/us/R2-complex-event.aspx

Unterstützte Betriebssysteme Windows

Lizenztyp Kommerziell

Softwareart Event Processing Engine

Branchenfokus Keiner, aber Trading, Energiewirt-schaft, Health Care und Logistik bei-spielhaft genannt

Verbreitung K.A.

Referenzkunden K.A.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Datenstromorientiert

Entwicklungsumgebung für EPL Ja (Visual Studio)

Graphische Modellierungstools für EPL

Nein

Debugging und Simulation Ja

Event Monitor Nein

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank Ja (SQL Server)

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Nein

ESB-Anbindung Nein

2 Marktübersicht

62

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 speziali-sierten Adaptern bei Microsoft-Partnern hingewiesen. Eigene Adapter können mit einem bereitgestellten SDK entwickelt werden, um damit Events aus Da-tenbanken, Webquellen oder anderen Applikationen lesen und absetzen zu können.

StreamInsight lässt die Verarbeitung von mehreren 100.000 Events pro Sekun-de zu.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

Die Abfragesprache LINQ (Language Integrated Query) ist SQL-basiert. Die Ent-wicklung 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: Ent-wicklung mit Micro-soft StreamInsight

23 Abbildung entnommen aus http://channel9.msdn.com/learn/courses/SQL2008R2TrainingKit/SQL10R2UPD05/SQL10R2UPD05_HOL_03/Exercise-1-Working-with-the-StreamInsight-Event-Flow-Debugger/

2 Marktübersicht

63

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.18 Axway Synchrony Sentinel

Name des Anbieters Axway

Name des Produktes Synchrony Sentinel

Website http://www.axway.com/products-solutions/ps-overview/axway-synchrony/sentinel

Unterstützte Betriebssysteme K.A.

Lizenztyp Kommerziell

Softwareart Event Processing Engine

Branchenfokus Keiner, aber Netzwerk- und Ge-schäftsprozessüberwachung als An-wendungsgebiete genannt

Verbreitung K.A.

Referenzkunden Renault, Procter+Gamble, Electrolux, DB Schenker

Event Stream Processing K.A.

Complex Event Processing Ja

EPL Sprachtyp K.A.

Entwicklungsumgebung für EPL K.A.

Graphische Modellierungstools für EPL

K.A.

Debugging und Simulation K.A.

Event Monitor Ja

Dashboard Nein

Graphische Modellierungstools für Dashboard

Nein

Event Datenbank K.A.

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung K.A.

2 Marktübersicht

64

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 Applikatio-nen gesammelt.

Beschreibung des Dashboards

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.

2 Marktübersicht

65

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2.3.19 West Global Vantify

Name des Anbieters West Global

Name des Produktes Vantify

Website http://www.westglobal.com/

Unterstützte Betriebssysteme Windows, Linux, Unix, Solaris

Lizenztyp Kommerziell

Softwareart Komplettsystem

Branchenfokus Fokus auf CRM und Netzwerküber-wachung

Verbreitung K.A.

Referenzkunden Vodafone Ireland

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL K.A.

Graphische Modellierungstools für EPL

K.A.

Debugging und Simulation K.A.

Event Monitor Ja

Dashboard Ja

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank K.A.

Export von Events für statistische Zwecke

K.A.

Auswertungs- und Analysetools Ja

ESB-Anbindung K.A.

2 Marktübersicht

66

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 Ver-fügung gestellt, die der Benutzer für Benachrichtigungen und Alarme auf ei-nem 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 Se-kunde angegeben.

Beschreibung des Dashboards

Die Darstellung des konfigurierbaren Dashboards erfolgt in einem Webbrowser. Es stehen verschiedene Diagramme für die Verwendung zur Verfügung. Abbil-dung 2324 zeigt exemplarische Vantify Dashboards. Der Anwender kann mittels Drill-Down eine Ursachenforschung für Events durchführen.

Abbildung 23: Exemplarische West Global Vantify Dash-boards

24 Abbildung entnommen aus http://www.westglobal.com/index.php?option=com_docman&task=doc_download&gid=3&Itemid=69

2 Marktübersicht

67

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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/

Unterstützte Betriebssysteme 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.

Event Stream Processing Ja

Complex Event Processing Ja

EPL Sprachtyp Regelbasiert

Entwicklungsumgebung für EPL Nein

Graphische Modellierungstools für EPL

Ja

Debugging und Simulation Ja

Event Monitor Ja

Dashboard Ja

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Ja

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Nein

ESB-Anbindung Ja

2 Marktübersicht

68

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Beschreibung der Event Processing Engine

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 Ser-vices zur Verfügung. Datenbanken können über JDBC und ODBC angebunden werden. Für das Load Balancing können mehrere Event Processing Engines pa-rallel geschaltet werden. Server Clustering wird ebenfalls unterstützt.

Für die Administration steht eine graphische Konsole zur Verfügung.

Beschreibung der Event Processing Language

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: Ent-wicklung mit IBM WebSphere Business Events

Beschreibung des Dashboards

Die mitgelieferte Komponente für die Visualisierung von Events heißt Business Space. Das Layout der Dashboards wird über Widgets definiert. Für die Gestal-tung 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

2 Marktübersicht

69

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

Abbildung 25: Bei-spielhafte Diagram-me in IBM WebSphere Business Space

Werden weitergehende Visualisierungsmöglichkeiten benötigt, kann alternativ auch eine Integration mit dem WebSphere Business Monitor erfolgen. Die An-zeige eines Dashboards ist auch auf Remotesystemen möglich.

2 Marktübersicht

70

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

2.3.21 SL RTView

Name des Anbieters SL

Name des Produktes RTView

Website http://www.sl.com/products/rtview.shtml

Unterstützte Betriebssysteme Alle mit Java Runtime

Lizenztyp Kommerziell

Softwareart Dashboard

Branchenfokus Keiner

Verbreitung Sehr verbreitet (unter anderem auch lizensiert durch Sybase und Progress)

Referenzkunden Deutsche Bank, Shell, NCR, HSBC, UBS

Event Stream Processing Nein

Complex Event Processing Nein

EPL Sprachtyp keine EPL

Entwicklungsumgebung für EPL Nein

Graphische Modellierungstools für EPL

Nein

Debugging und Simulation Nein

Event Monitor Ja

Dashboard Ja

Graphische Modellierungstools für Dashboard

Ja

Event Datenbank Nur Anbindung

Export von Events für statistische Zwecke

Ja

Auswertungs- und Analysetools Ja

ESB-Anbindung Ja

2 Marktübersicht

71

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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 Ex-cel 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).

Abbildung 26: Mo-dellierung mit dem SL RTView Builder

Es stehen mehrere Diagrammtypen für die graphische Darstellung zur Verfü-gung, beispielsweise Zähler, Fortschrittsbalken, Torten-, Linien- und Balkendia-gramme. 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 wer-den.

RTView ist auch zur Verarbeitung von Alerts in der Lage. Diese können entwe-der 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 expor-tiert werden.

27 Abbildung entnommen aus http://www.sl.com/pdfs/SLRTViewDatasheet-Nov08.pdf

2 Marktübersicht

72

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

2.4 Tabellarische Übersicht

Auf den folgenden Seiten werden die betrachteten Event Processing Tools an-hand des in Abschnitt 2.2 eingeführten Kriterienrasters in einer tabellarischen Übersicht gegenübergestellt.

Nam

e de

s A

nbie

ters

Syba

se

Prog

ress

TI

BCO

ru

leC

ore

Truv

iso

UC

4 So

ftw

are

JBos

s

Nam

e de

s Pr

oduk

tes

Ale

ri St

ream

ing

Plat

form

/ C

EP

Apa

ma

Busi

ness

Even

ts &

Sp

otfir

e C

EP S

erve

r C

ontin

uous

A

naly

tics

UC

4 D

ecis

ion

&

UC

4 In

sigh

t D

rool

s Fu

sion

Unt

erst

ützt

e Be

trie

bssy

stem

e W

indo

ws,

Lin

ux,

Sola

ris

Win

dow

s, L

inux

, So

laris

W

indo

ws,

Lin

ux,

Sola

ris, H

P U

X

Alle

(Sof

twar

e as

a

Serv

ice)

Li

nux

Win

dow

s A

lle m

it Ja

va

Runt

ime

Lize

nzty

p

Kom

mer

ziel

l K

omm

erzi

ell

Kom

mer

ziel

l K

omm

erzi

ell

Kom

mer

ziel

l K

omm

erzi

ell

Ope

n So

urce

Soft

war

eart

K

ompl

etts

yste

m

Kom

plet

tsys

tem

K

ompl

etts

yste

m

Even

t Pr

oces

sing

En

gine

K

ompl

etts

yste

m

Kom

plet

tsys

tem

Ev

ent

Proc

essi

ng

Engi

ne

Even

t St

ream

Pro

cess

ing

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Com

plex

Eve

nt P

roce

ssin

g

Ja

Ja

Ja

Ja

Nei

n Ja

Ja

EPL

Spra

chty

p D

aten

stro

m-

orie

ntie

rt

Impe

rativ

Re

gelb

asie

rt

Rege

lbas

iert

D

aten

stro

m-

orie

ntie

rt

Rege

lbas

iert

Re

gelb

asie

rt

Entw

ickl

ungs

umge

bung

für

EP

L Ja

Ja

Ja

N

ein

Ja

Ja

Ja

Gra

phis

che

Mod

ellie

rung

s-to

ols

für

EPL

Ja (A

leri

Stud

io)

Nei

n (C

EP S

tudi

o)

Ja

Ja

Nei

n K

.A.

Ja

Nei

n

Deb

uggi

ng u

nd S

imul

atio

n

Ja

Ja

K.A

. Ja

K

.A.

Ja

Ja

Even

t M

onito

r

Ja

Ja

Ja

Nei

n K

.A.

Ja

Nei

n

Das

hboa

rd

Ja

(SL

RTV

iew

liz

enzi

ert)

Ja

(SL

RTV

iew

liz

enzi

ert)

Ja

(Spo

tfire

) N

ein

Ja

Ja (U

C4

Insi

ght)

N

ein

Gra

phis

che

Mod

ellie

rung

s-to

ols

für

Das

hboa

rd

Ja

Ja

Ja (S

potf

ire)

Nei

n Ja

Ja

(UC

4 In

sigh

t)

Nei

n

Even

t D

aten

bank

Nei

n Ja

Ja

N

ein

Ja

Ja

Nur

Anb

indu

ng

Expo

rt v

on E

vent

s fü

r st

atis

ti-sc

he Z

wec

ke

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Aus

wer

tung

s- u

nd A

naly

se-

tool

s Ja

Ja

K

.A.

Nei

n Ja

Ja

N

ein

ESB-

Anb

indu

ng

Ja

Ja

Ja

Ja

N

ein

Ja

Ja

73Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

2 Marktübersicht

Nam

e de

s A

nbie

ters

Ora

cle

Espe

rTec

h Ev

ent

Zero

St

ream

Base

O

pen

ESB

(Ora

cle)

V

itria

Re

altim

e M

onito

-rin

g G

mbH

N

ame

des

Prod

ukte

s ED

A S

uite

Es

per

& E

sper

HQ

Ev

ent

Proc

essi

ng

Net

wor

k Ev

ent

Proc

essi

ng

Plat

form

In

telli

gent

Eve

nt

Proc

esso

r (IE

P)

M3O

Ana

lytic

Se

rver

& M

3O

Ope

ratio

ns B

ook

RTM

Ana

lyze

r

Unt

erst

ützt

e Be

trie

bssy

stem

e W

indo

ws,

Lin

ux,

Sola

ris, H

P-U

X, A

IX

Win

dow

s, L

inux

, So

laris

, AIX

A

lle m

it Ja

va

Runt

ime

Win

dow

s, L

inux

A

lle m

it Ja

va

Runt

ime

Win

dow

s, L

inux

, So

laris

, HP-

UX

A

lle m

it Ja

va

Runt

ime

Lize

nzty

p

Kom

mer

ziel

l O

pen

Sour

ce /

Kom

mer

ziel

l K

omm

erzi

ell

Kom

mer

ziel

l O

pen

Sour

ce

Kom

mer

ziel

l K

omm

erzi

ell

Soft

war

eart

K

ompl

etts

yste

m

Kom

plet

tsys

tem

K

ompl

etts

yste

m

Kom

plet

tsys

tem

Ev

ent

Proc

essi

ng

Engi

ne

Kom

plet

tsys

tem

K

ompl

etts

yste

m

Even

t St

ream

Pro

cess

ing

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Com

plex

Eve

nt P

roce

ssin

g

Ja

Ja

Ja

Ja

Ja

Ja

Ja

EPL

Spra

chty

p D

aten

stro

m-

orie

ntie

rt

Dat

enst

rom

-or

ient

iert

K

.A.

Dat

enst

rom

-or

ient

iert

D

aten

stro

m-

orie

ntie

rt

Dat

enst

rom

-or

ient

iert

D

aten

stro

m-

orie

ntie

rt

Entw

ickl

ungs

umge

bung

für

EP

L Ja

Ja

(Ent

erpr

ise

Editi

on)

Nei

n Ja

Ja

(Net

Bean

s ID

E)

Ja

Ja

Gra

phis

che

Mod

ellie

rung

s-to

ols

für

EPL

Ja

Ja (E

nter

pris

e Ed

ition

) Ja

Ja

Ja

(Net

Bean

s ID

E)

Ja

Ja

Deb

uggi

ng u

nd S

imul

atio

n

Ja

Ja (E

nter

pris

e Ed

ition

) Ja

Ja

N

ein

Ja

K.A

.

Even

t M

onito

r

Ja

Ja (E

nter

pris

e Ed

ition

) Ja

Ja

N

ein

Ja

Ja

Das

hboa

rd

Ja

Ja

(Ent

erpr

ise

Editi

on)

Ja

Nei

n N

ein

Ja (M

3O O

pera

-tio

ns B

ook)

Ja

Gra

phis

che

Mod

ellie

rung

s-to

ols

für

Das

hboa

rd

Ja

Ja (E

nter

pris

e Ed

ition

) Ja

N

ein

Nei

n Ja

(M3O

Ope

ra-

tions

Boo

k)

Ja

Even

t D

aten

bank

Ja

Ja (E

nter

pris

e Ed

ition

) Ja

Ja

Ja

(Jav

a D

B)

Ja

Nei

n

Expo

rt v

on E

vent

s fü

r st

atis

ti-sc

he Z

wec

ke

Ja

Ja (E

nter

pris

e Ed

ition

) Ja

Ja

Ja

Ja

Ja

Aus

wer

tung

s- u

nd A

naly

se-

tool

s Ja

N

ein

Ja

Nei

n N

ein

Ja

Ja

ESB-

Anb

indu

ng

Ja

Ja

Ja

Ja

Ja

Ja

Ja

74 Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

2 Marktübersicht

Nam

e de

s A

nbie

ters

Info

rmat

ica

Star

view

Tec

hno-

logy

M

icro

soft

A

xway

W

est

Glo

bal

IBM

SL

Nam

e de

s Pr

oduk

tes

Rule

poin

t Sm

art

Ente

rpris

e Pl

atfo

rm

Stre

amIn

sigh

t Sy

nchr

ony

Sent

inel

V

antif

y W

ebSp

here

Bus

i-ne

ss E

vent

s RT

Vie

w

Unt

erst

ützt

e Be

trie

bssy

stem

e W

indo

ws,

Lin

ux,

Sola

ris

Win

dow

s, L

inux

, So

laris

W

indo

ws

K.A

. W

indo

ws,

Lin

ux,

Uni

x, S

olar

is

Win

dow

s, L

inux

, So

laris

, HP-

UX

, AIX

A

lle m

it Ja

va

Runt

ime

Lize

nzty

p

Kom

mer

ziel

l K

omm

erzi

ell

Kom

mer

ziel

l K

omm

erzi

ell

Kom

mer

ziel

l K

omm

erzi

ell

Kom

mer

ziel

l

Soft

war

eart

Ev

ent

Proc

essi

ng

Engi

ne

Even

t Pr

oces

sing

En

gine

Ev

ent

Proc

essi

ng

Engi

ne

Even

t Pr

oces

sing

En

gine

K

ompl

etts

yste

m

Kom

plet

tsys

tem

D

ashb

oard

Even

t St

ream

Pro

cess

ing

Ja

Ja

Ja

K

.A.

Ja

Ja

Nei

n

Com

plex

Eve

nt P

roce

ssin

g

Ja

Ja

Ja

Ja

Ja

Ja

Nei

n

EPL

Spra

chty

p Re

gelb

asie

rt

Rege

lbas

iert

D

aten

stro

m-

orie

ntie

rt

K.A

. Re

gelb

asie

rt

Rege

lbas

iert

ke

ine

EPL

Entw

ickl

ungs

umge

bung

für

EP

L Ja

Ja

Ja

(Vis

ual S

tudi

o)

K.A

. K

.A.

Nei

n N

ein

Gra

phis

che

Mod

ellie

rung

s-to

ols

für

EPL

Ja

Ja

Nei

n K

.A.

K.A

. Ja

N

ein

Deb

uggi

ng u

nd S

imul

atio

n

Ja

Ja

Ja

K.A

. K

.A.

Ja

Nei

n

Even

t M

onito

r

Ja

Ja

Nei

n Ja

Ja

Ja

Ja

Das

hboa

rd

N

ein

Nei

n N

ein

Nei

n Ja

Ja

Ja

Gra

phis

che

Mod

ellie

rung

s-to

ols

für

Das

hboa

rd

Nei

n N

ein

Nei

n N

ein

Ja

Ja

Ja

Even

t D

aten

bank

Ja

Ja

Ja (S

QL

Serv

er)

K.A

. K

.A.

Ja

Nur

Anb

indu

ng

Expo

rt v

on E

vent

s fü

r st

atis

ti-sc

he Z

wec

ke

Ja

Ja

Ja

Ja

K.A

. Ja

Ja

Aus

wer

tung

s- u

nd A

naly

se-

tool

s Ja

Ja

N

ein

Ja

Ja

Nei

n Ja

ESB-

Anb

indu

ng

Ja

Ja

N

ein

K.A

. K

.A.

Ja

Ja

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

75

2 Marktübersicht

76

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

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 meis-ten Produkte setzen dabei auf der Java Plattform auf.

Allerdings existieren auch große Unterschiede:

• Umfang der mitgelieferten Adapter: Manche Produkte bieten eine breite Palette an Anbindungen, von den verschiedensten ESB-Implementa-tionen, ü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 Eigenar-beit bei der Entwicklung eigener Adapter (beispielsweise Beispiel Micro-soft StreamInsight).

• Art und Umfang der mitgelieferten Werkzeuge: Viele Produkte enthal-ten 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 Datenban-ken, ESB-Implementationen, Application Server etc. Der Anwender übernimmt die Integration der Event Processing Engine in die vorhande-ne 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 Regelmo-dellierung 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 Kernfunktionali-tät des Event Processing und überlassen die Visualisierung einer entspre-chenden 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

3 Fazit

77

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

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 wer-den 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 lizen-siert 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 Entwick-lung 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 Program-mierung in einer EPL unterstützen (zum Beispiel Assistenten zur Regel-generierung) 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 dessel-ben 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 Anwen-dungsgebiet für Event Processing Software ist der automatisierte Handel mit Wertpapieren (Algorithmic Trading). Dabei kommt es auf eine be-sonders hohe Verarbeitungsgeschwindigkeit an, da nur dann die Reali-sierung 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 ge-dacht sind, nur relativ wenige Daten pro Zeiteinheit verarbeiten müssen und daher weniger Augenmerk auf die Skalierbarkeit richten (beispiels-weise UC4 Decision).

78

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Abkürzungen

API Application Programming Interface ASL Apache Software License BAM Business Activity Monitoring BPMS Business Process Management Suite BPEL Business Process Execution Language CDDL Common Development and Distribution License CEP Complex Event Processing CORBA Common Object Request Broker Architecture CRM Customer Relationship Management CSV Comma-Separated Values DB Database DCOM Distributed Component Object Model EDA Event-Driven Architecture EJB Enterprise JavaBeans EPL Event Processing Language ESB Enterprise Service Bus ESP Event Stream Processing FTP File Transfer Protocol GPL General Public License HTML HyperText Markup Language HTTP HyperText Transfer Protocol IDE Integrated Development Environment IMAP Internet Message Access Protocol IP Internet Protocol IT Information Technology JAXB Java Architecture for XML Binding JBI Java Business Integration JCA Java EE Connector Architecture JDBC Java Database Connectivity JMS Java Message Service JMX Java Management Extensions JSON JavaScript Object Notation K.A. Keine Angabe ODBC Open Database Connectivity OPC DA OPC Data Access PDF Portable Document Format POP3 Post Office Protocol, Version 3 REST REpresentational State Transfer RFID Radio Frequency IDentification RMI Remote Method Invocation RSS Really Simple Syndication SDK Software Development Kit

Abkürzungen

79

Fraunhofer IAOMarktübersicht Real-Time Monitoring Software

SQL Structured Query Language SMS Short Message Service SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SOA Service-Oriented Architecture TCP Transmission Control Protocol UDP User Datagram Protocol XML eXtensible Markup Language

80

Fraunhofer IAO Marktübersicht Real-Time Monitoring Software

Referenzen

[1] B. Seeger: Kontinuierliche Kontrolle - Complex Event Processing: Auswer-tung 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: Informatik-Spektrum, 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.ep-ts.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_processing_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_Processing_Wares, 2008.

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

Marktübersicht real-tiMe Monitoring softwareEvENT PROcESSINg TOOlS Im ÜbERblIck

Krešimir Vidačković, Thomas Renner, Sascha Rex

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.

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.

FRAUNHOFER vERlAg

ISBN 978-3-8396-0185-3

9 783839 601853

mA

Rk

bE

RS

IcH

T R

EA

l-T

ImE

mO

NIT

OR

INg

SO

FTw

AR

E