SlideShare una empresa de Scribd logo
1 de 79
Descargar para leer sin conexión
F R A U N H O F E R - I N S T I T U T F Ü R A R b E I T S w I R T S c H A F T U N d O R g A N I S AT I O N I A O



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




Marktübersicht
real-tiMe Monitoring software




                                                                                           n
                                                                               io
EvENT PROcESSINg TOOlS Im ÜbERblIck


                                                                             rs
                                                                    Ve
                                                             e
                                                      ig
                                               uf
                                     rlä
                           Vo
Krešimir Vidačković
                                           Thomas Renner
                                                Sascha Rex




Marktübersicht Real-Time Monitoring Software




                                      n
                                      io
Event Processing Tools im Überblick

                                  rs
                            Ve
                         e
                     ig
                uf
           rlä
     Vo
Autoren
    Krešimir Vidačković
    Thomas Renner
    Sascha Rex

    Kontaktadresse
    Fraunhofer-Institut für Arbeitswirtschaft und Organisation
    Nobelstraße 12
    70569 Stuttgart
    Telefon: +49 (0) 711/970-51 20
    Telefax: +49 (0) 711/970-51 11
    E-Mail: XXX
    Web-Adresse: XXX

    Hinweis auf das Forschungsprojekt iC-RFID
    Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums




                                                                         n
    für Wirtschaft und Technologie (BMWi) unter dem Förderkennzeichen 01MT06006 gefördert.
    Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren.




                                                                   io
    Bibliografische Information der Deutschen Nationalbibliothek

                                                             rs
    Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibli-
    ografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
    ISBN: XXX-X-XXXX-XXXX-X
                                                    Ve
    Druck und Weiterverarbeitung
    IRB Mediendienstleistungen
                                              e

    Fraunhofer-Informationszentrum Raum und Bau IRB, Stuttgart
                                        ig


    Verlag und Druck
    Fraunhofer Verlag, Fraunhofer-Informationszentrum Raum und Bau IRB
                                uf




    Postfach 800469, 70504 Stuttgart
    Nobelstraße 12, 70569 Stuttgart
    Telefon: +49 (0) 711/970-25 00
                          rlä




    Telefax: +49 (0) 711/970-25 08
    E-Mail: verlag@fraunhofer.de
    Web-Adresse: http://verlag.fraunhofer.de
               Vo




    Für den Druck des Buches wurde chlor- und säurefreies Papier verwendet.

    Copyright Fraunhofer IAO, 2010

    Alle Rechte vorbehalten

    Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Verwertung,
    die über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zu-
    stimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen,
    Übersetzungen, Mikroverfilmungen sowie die Speicherung in elektronischen Systemen. Die
    Wiedergabe von Warenbezeichnungen und Handelsnamen in diesem Buch berechtigt nicht zu
    der Annahme, dass solche Bezeichnungen im Sinne der Warenzeichen- und Markenschutz-
    Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürf-
    ten. Soweit in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z.B.
    DIN, VDI) Bezug genommen oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr
    für Richtigkeit, Vollständigkeit oder Aktualität übernehmen.




2
Inhalt




           Abbildungen                                                     4

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




                                               n
           2        Marktübersicht                                         14




                                          io
           2.1      Vorgehensweise bei der Erstellung der Marktübersicht   14
           2.2      Kriterienraster                                        14
           2.3
           2.3.1
                                     rs
                    Produktbeschreibungen
                    Sybase Aleri Streaming Platform / CEP
                                                                           16
                                                                           18
                             Ve
           2.3.2    Progress Apama                                         21
           2.3.3    TIBCO BusinessEvents & Spotfire                        24
           2.3.4    ruleCore CEP Server                                    27
                        e

           2.3.5    Truviso Continuous Analytics                           29
           2.3.6    UC4 Decision & Insight                                 31
                    ig



           2.3.7    JBoss Drools Fusion                                    34
           2.3.8    Oracle EDA Suite                                       36
               uf




           2.3.9    EsperTech Esper                                        39
           2.3.10   Event Zero Event Processing Network                    41
          rlä




           2.3.11   StreamBase Event Processing Platform                   44
           2.3.12   Open ESB Intelligent Event Processor (IEP)             46
           2.3.13   Vitria M3O Analytic Server & M3O Operations Book       48
         Vo




           2.3.14   Realtime Monitoring RTM Analyzer                       51
           2.3.15   Informatica Rulepoint                                  54
           2.3.16   Starview Smart Enterprise Platform                     56
           2.3.17   Microsoft StreamInsight                                58
           2.3.18   Axway Synchrony Sentinel                               60
           2.3.19   West Global Vantify Experience Center                  62
           2.3.20   IBM WebSphere Business Events                          64
           2.3.21   SL RTView                                              67
           2.4      Tabellarische Übersicht                                69

           3        Fazit                                                  73

           Abkürzungen                                                     75

           Referenzen                                                      77




                                                                            3
Abbildungen

              Abbildung 1: Grundkomponenten eines Event Processing Systems            11
              Abbildung 2: Modellierung mit dem Sybase Aleri Studio                   20
              Abbildung 3: Entwicklung mit dem Progress Apama Studio                  22
              Abbildung 4: Modellierung mit dem Progress Apama Dashboard Builder      23
              Abbildung 5: Exemplarisches TIBCO Spotfire Dashboard                    25
              Abbildung 6: Beispielhafte Diagramme mit UC4 Insight                    33
              Abbildung 7: Entwicklung mit JBoss Drools                               35




                                                         n
              Abbildung 8: Modellierung mit der Oracle EDA Suite                      37
              Abbildung 9: Exemplarisches Oracle BAM Dashboard                        38




                                                    io
              Abbildung 10: Event Zero Administrations- und Entwicklungstool          42
              Abbildung 11: Beispielhaftes Event Zero Dashboard                       43
                                               rs
              Abbildung 12: Modellierung mit dem StreamBase Studio
              Abbildung 13: Elemente für die Entwicklung mit Open ESB IEP
                                                                                      45
                                                                                      47
                                        Ve
              Abbildung 14: Modellierung mit dem Vitria M3O Query Modeler             49
              Abbildung 15: Beispielhafte Vitria M3O Operations Book Dashboards       50
              Abbildung 16: Entwicklung mit dem RTM Analyzer                          52
                                   e

              Abbildung 17: Exemplarisches RTM Analyzer Dashboard                     53
                              ig


              Abbildung 18: Beispielhafter Informatica Rulepoint Alert Manager        55
              Abbildung 19: Modellierung mit Starview                                 57
                        uf




              Abbildung 20: Entwicklung mit Microsoft StreamInsight                   59
              Abbildung 21: Exemplarische West Global Vantify Dashboards              63
              Abbildung 22: Entwicklung mit IBM WebSphere Business Events             65
                 rlä




              Abbildung 23: Beispielhafte Diagramme in IBM WebSphere Business Space   66
              Abbildung 24: Modellierung mit dem SL RTView Builder                    68
        Vo




4
1           Einführung

                          Die klassische Analyse von Unternehmensdaten erfolgt in der Regel rückwir-
                          kend. In der Vergangenheit aufgelaufene Daten werden zum Beispiel aus ei-
                          nem Data Warehouse selektiert und auf die gewünschten Fragestellungen hin
                          untersucht. Anhand der Ergebnisse können dann entsprechende Konsequen-
                          zen gezogen werden (vgl. [1]).

                          Aufgrund seiner Vergangenheitsbezogenheit ist dieses Vorgehen oft unbefrie-




                                                                                         n
                          digend, da eine zeitnahe Reaktion auf aktuelle Begebenheiten meistens un-
                          möglich ist. In vielen Anwendungsfällen ist es allerdings erforderlich, zeitkriti-




                                                                                  io
                          sche Daten in Echtzeit zu verarbeiten, um so auf Ereignisse im Unternehmen
                          und in der Umwelt rasch reagieren zu können. Beispiele hierfür sind Aktien-
                                                                           rs
                          handel, Betrugserkennung, zeitkritische Überwachungssysteme oder Sensor-
                          netzwerke mit RFID (vgl. [2]).
                                                                Ve
                          Die Echtzeitverarbeitung von relevanten Ereignissen, das so genannte Event
                          Processing1, wird zwar schon seit Jahrzehnten praktiziert, allerdings wurden
                                                         e

                          hierfür häufig selbst entwickelte Skripte eingesetzt, denen es an Flexibilität und
                                                  ig


                          Standardisierung mangelte (vgl. [1] und [2]). Demgegenüber zielt das in den
                          letzten Jahren entstandene und stetig wachsende Fachgebiet des Complex
                                         uf




                          Event Processing (vgl. insbesondere [3]) auf eine kontinuierliche und unmittel-
                          bare Verarbeitung einer Vielzahl an Ereignissen ab, die methodisch und tech-
                          nologisch sowie durch den Einsatz dedizierter Softwaretools unterstützt wird,
                               rlä




                          so dass die notwendige Systematik im Einsatz möglich wird (vgl. [4]). Im Zuge
                          der Digitalisierung und Vernetzung in der heutigen Zeit sowie einer einherge-
                    Vo




                          henden Explosion von in Echtzeit zu verarbeitenden Datenmengen spielen sol-
                          che Softwaresysteme eine immer wichtigere Rolle (vgl. [5]). Dies unterstreicht
                          nicht zuletzt die Gründung der Event Processing Technical Society (EPTS)2 zu
                          Beginn des Jahres 2008, der die meisten Anbieter von Event Processing Tools
                          sowie Einzelpersonen aus dem Forschungsumfeld angehören und die sich für
                          ein gemeinsames Verständnis, die Entwicklung von Standards und für den Wis-
                          senstransfer in diesem Fachgebiet einsetzt (vgl. [6]).

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




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




                                                                                                               5
Nutzung im Markt attestiert. Die vorliegende Marktübersicht liefert einen Ein-
              blick in die Funktionalitäten dieser Produkte.

              Die Marktübersicht entstand im Rahmen des vom Bundesministerium für Wirt-
              schaft und Technologie (BMWi) geförderten Verbundprojekts iC-RFID (»Intelli-
              gentes Catering mittels Radio Frequency IDentification«), dessen Forschungs-
              gegenstand die Integration und Echtzeitsteuerung einer unternehmensüber-
              greifenden Prozesskette am Beispiel Luftfahrtcatering mit Hilfe der RFID-
              Technologie umfasste. Ein wesentlicher Bestandteil war die Konzeption und
              Realisierung eines Real-Time Dashboards, welches den Prozessfluss von mit
              RFID-Tags ausgerüsteten Flugzeugtrolleys visualisiert und bei Engpässen auto-
              matisierte Benachrichtigungen in Echtzeit erzeugt.




                                                               n
                                                         io
              Die folgenden Abschnitte dieses Kapitels behandeln die Grundlagen von Event
              Processing und die wesentlichen Komponenten von Event Processing Tools, um
                                                   rs
              das Verständnis für die zugrundeliegende Thematik zu vertiefen.
                                           Ve
              Im zweiten Kapitel wird zunächst die Methodik bei der Erstellung der Markt-
              übersicht erläutert und das verwendete Kriterienraster definiert. Dieses wird
              anschließend herangezogen, um die derzeit auf dem Markt befindlichen Pro-
                                      e

              dukte einzeln und im Detail zu beschreiben. Als Abschluss folgt eine Zusam-
              menfassung dieser Produkte und ihrer Funktionalitäten in tabellarischer Form.
                                ig



              Das letzte Kapitel enthält schließlich ein Fazit mit einer Darstellung der wesent-
                         uf




              lichen Erkenntnisse der vorliegenden Marktübersicht.
                   rlä




1.1   Grundlagen
          Vo




              Ein Softwaresystem mit einer ereignisgesteuerten Architektur (Event-Driven
              Architecture, EDA) unterliegt einem Softwarearchitekturmuster mit lose ge-
              koppelten Komponenten, die lediglich mit Hilfe von Ereignissen (Events) in ei-
              ner einfachgerichteten Weise miteinander kommunizieren, ohne dabei Wissen
              über das Gesamtsystem zu besitzen (vgl. [5]). Ein Event bezeichnet hierbei alles,
              was passiert oder von dem erwartet wird, dass es passiert. Für eine automati-
              sierte Verarbeitung muss ein Event in Form eines Eventobjekts vorliegen, durch
              welches es in elektronischer Form repräsentiert wird. Beispiele hierfür sind ein
              Bestellungseingang, eine Aktienwertänderung oder der Eingang eines Lesevor-
              gangs eines RFID-Sensors (vgl. [8]).

              Auf der Grundlage vordefinierter Regeln (Event Processing Rules) können ein-
              gehende Events ausgewertet und weiterverarbeitet werden, so dass entweder
              mit einer deduktiven Regel ein neues Event generiert wird oder mit einer reak-
              tiven Regel eine direkte Reaktion ausgelöst wird. Beispiele für letztere sind et-
              wa der Kauf einer bestimmten Anzahl Aktien, sobald der Kurs den gewünsch-
              ten Kaufpreis unterschritten hat oder die sofortige Benachrichtigung eines Ver-



6
antwortlichen bei einem Transportfehler eines mit einem RFID-Tag ausgerüste-
ten Containers. Als weitere typische Reaktion kann die unmittelbare Interaktion
mit Geschäftsprozessen genannt werden (vgl. [4]).

Der grundlegende Unterschied zu traditionellen Analysesystemen aus dem Da-
tenbankumfeld ist hierbei die Tatsache, dass eingehende Events während ihres
Passierens kontinuierlich anhand der Event Processing Rules ausgewertet wer-
den und Reaktionen unmittelbar in Echtzeit angestoßen werden können (Push-
Prinzip). Somit werden anstatt einmaliger Anfragen zu diskreten Zeitpunkten
gegen eine endliche Datenmenge hier durchgehende Anfragen gegen eine
(konzeptionell) unbegrenzte Eventmenge ausgeführt (vgl. [4]).




                                                n
Man unterscheidet grundsätzlich drei verschiedene Arten von Event Processing




                                          io
(vgl. [9]):

   •
                                    rs
       Simple Event Processing: Hierbei wird auf ein bestimmtes Einzelevent
       eine vordefinierte Reaktion direkt ausgelöst, um Verzögerungszeiten zu
                            Ve
       vermeiden. Wenn beispielsweise ein Lagerverwaltungssystem bei zu
       niedrigem Bestand eines Artikels ein entsprechendes Event versendet,
       kann darauf unmittelbar mit der Initiierung eines zugehörigen Bestel-
                       e

       lungsprozesses und mit einer Nachricht an einen Verantwortlichen rea-
       giert werden.
                 ig



   •   Event Stream Processing (ESP): Das System analysiert einen oder mehre-
           uf




       re zeitlich geordnete Ereignisströme (Event Streams) im Zeitablauf und
       versucht dabei, bedeutsame Events und Relationen zwischen Events in
   rlä




       diesen zu identifizieren und darauf zu reagieren. Klassische Beispiele für
       ESP sind etwa der automatisierte Handel mit Wertpapieren, bei dem ein
       Handelssystem die Aktienkurse im Zeitablauf analysiert und gegebenen-
Vo




       falls automatisierte Kauf- oder Verkaufsorders platziert, sowie die Ana-
       lyse von RFID Event Streams, bei der als Reaktion auf falsche Transport-
       wege beispielsweise entsprechende Alarme versendet werden können.

   •   Complex Event Processing (CEP): Komplexe Ereignisse (Complex Events)
       sind Mengen von Events, die in einem meist temporalen, kausalen oder
       räumlichen Zusammenhang stehen, aber nicht zwingend vom gleichen
       Ereignistyp sein müssen. Das System analysiert eine so genannte Ereig-
       niswolke (Event Cloud), die aus ungeordneten Events besteht, im Hin-
       blick auf bestimmte Ereignismuster (Event Patterns) und löst gegebe-
       nenfalls Reaktionen aus. Ein Beispiel für CEP ist ein Intrusion Detection
       System, das auf Unstimmigkeiten in laufenden Netzwerkzugriffen rea-
       gieren kann, indem es Events an verschiedenen Stellen im Netzwerk re-
       gistriert und untereinander in Beziehung setzt. Ein weiteres Beispiel ist
       die Betrugserkennung bei Kreditkartenbuchungen.




                                                                                7
Event Stream Processing (ESP) und Complex Event Processing (CEP) bauen bei
              der Analyse von eingehenden Events im Hinblick auf Event Patterns auf ähnli-
              chen Konzepten auf, wobei ESP stärker auf kontinuierliche und (meist zeitlich)
              geordnete Ereignisströme abzielt, während CEP eher komplexe Operationen
              über mehrere Events und Eventtypen im Fokus hat. Eine klare konzeptionelle
              Abgrenzung ist hierbei allerdings kaum möglich (vgl. [6]). Eine nähere Be-
              schreibung der Funktionalitäten von Event Processing Systemen und der Erken-
              nung von Event Patterns erfolgt in Abschnitt 1.2.

              Nach [7] lässt sich die Motivation für die Nutzung von Event Processing Syste-
              men grob in folgende Kategorien einordnen:




                                                             n
                 •   Überwachung: Feststellung von unerwünschtem Verhalten von Syste-




                                                       io
                     men oder Prozessen und sofortiges Auslösen von Benachrichtigungen,
                     wobei die Reaktionen den Nachrichtenempfängern überlassen werden

                 •
                                                  rs
                     Informationsbereitstellung: personalisierte Übermittlung von Informati-
                                          Ve
                     onen, d.h. die richtige Information zur richtigen Zeit in der richtigen
                     Granularität an den richtigen Abnehmer
                                     e

                 •   Dynamisches Betriebsverhalten: sofortiges Auslösen von Geschäfts-
                               ig


                     transaktionen auf Basis von eingehenden Events

                 •
                         uf




                     Aktive Diagnostik: Problemdiagnose durch Auswertung von Symptomen
                     als eingehende Events
                 rlä




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




              Häufig bestehen die Anforderungen der zu lösenden Geschäftsprobleme in ei-
              ner komplexen Fachlogik, großen Datenvolumina, geringen Latenzzeiten, ho-
              her Skalierbarkeit und erforderlicher Agilität bzw. einfacher Änderbarkeit der
              Anwendung (vgl. [6]). Bei Vorliegen eines oder mehrerer dieser Beweggründe
              lohnt sich möglicherweise der Einsatz von Event Processing Tools, deren Kom-
              ponenten nachfolgend allgemein beleuchtet werden.

1.2   Komponenten von Event Processing Tools

              Im engeren Sinn besteht ein System für das Event Processing aus drei Kompo-
              nenten: Ereignisquelle (Event Source), Ereignisverarbeitungskomponente (Event




8
Processing Agent) und Ereignissenke (Event Sink), die jeweils durch einen Er-
                          eigniskanal (Event Channel) miteinander verbunden sind.3 Diese werden im
                          Folgenden näher beschrieben (vgl. etwa [1], [6] oder [7]):

                               •    Ereignisquelle (Event Source): Jedes Event wird durch eine Ereignis-
                                    quelle generiert und in das System eingebracht. Hierbei kann es sich
                                    beispielsweise um eine Anwendung, verschiedene Sensoren, ein Daten-
                                    banksystem oder einen Geschäftsprozess handeln. Für die Übergabe
                                    über einen Event Channel an einen Event Processing Agent muss das
                                    Event dabei lediglich in eine für diesen verarbeitbare Form gebracht
                                    werden. Die Umwandlung in ein entsprechendes Format übernimmt ein




                                                                                         n
                                    Adapter. Viele Event Processing Tools liefern bereits eine unterschiedli-
                                    che Anzahl an vorgefertigten Adaptern mit oder bieten zumindest die




                                                                                 io
                                    Möglichkeit, eigene Adapter mittels einer Programmierschnittstelle
                                    (Application Programming Interface, API) selbst zu entwickeln.

                               •
                                                                          rs
                                    Event Processing Agent: Ein Event Processing Agent ist der Kern jedes
                                                                Ve
                                    Event Processing Tools, in dem das Eventmodell der zu verarbeitenden
                                    Events, die Event Processing Rules sowie die Event Processing Engine
                                    zur kontinuierlichen Interpretation dieser Regeln enthalten sind. Hier
                                                         e

                                    werden die übergebenen Events z.B. durch Filterung oder Transformati-
                                                  ig


                                    on weiterverarbeitet und im Hinblick auf vordefinierte Event Patterns
                                    analysiert (vgl. [6]).
                                         uf




                                    Event Patterns beinhalten beispielsweise logische Operationen (Kon-
                                    junktionen, Disjunktionen oder Negationen), Kardinalitäten, fachliche
                               rlä




                                    Korrelationen oder zeitliche Beziehungen zwischen verschiedenen
                                    Events. Um endliche Eventmengen analysieren zu können, werden zeit-
                                    liche oder logische Fenster über den eingehenden Events definiert, z.B.
                    Vo




                                    Events der letzten 2 Minuten oder die letzten 20 Events, und nur die ak-
                                    tuell in einem solchen Fenster befindlichen Events in die Auswertung
                                    einbezogen (vgl. [4], [6] und [10]). Bei der Verarbeitung können aus
                                    einzelnen atomaren Events (Raw Events) abgeleitete Events (Derived
                                    Events) erzeugt werden. Durch Abstraktionen mit Hilfe verschiedener
                                    Operationen, z.B. Durchschnittsberechnungen, können aggregierte
                                    Events (Composite Events) entstehen, welche die zugrundeliegenden
                                    Raw Events zusammenfassen, oder auch komplexe Events (Complex
                                    Events), welche die zugrundeliegenden Raw Events nicht beinhalten,




3   Im englischen Sprachgebrauch werden verschiedene Synonyme für diese Komponenten benutzt, etwa Event Emitter oder Event
    Producer für eine Ereignisquelle, Event Processing Component oder Event Mediator für eine Ereignisverarbeitungskomponente,
    Event Consumer für eine Ereignissenke sowie Event Connection, Event Pathway oder Event Topic für einen Ereigniskanal. Bei den
    englischen Begriffen beziehen wir uns auf das herausgegebene Glossar der EPTS (vgl. [8]) und deren jeweils erste Nennungen.




                                                                                                                                    9
sondern anhand von komplexeren Operationen neue Erkenntnisse aus
          diesen ziehen (vgl. [6]).

          Sobald eine Event Processing Rule im Hinblick auf ein vorliegendes
          Event Pattern greift, können vordefinierte Reaktionen ausgelöst wer-
          den, wobei es sich neben dem Senden eines neuen Events auch um
          konkrete Aktionen, wie etwa das Versenden von Warnungen, das Aus-
          lösen von Alarmen oder den direkten Aufruf von Diensten, handeln
          kann.

          Die Modellierung der entsprechenden Regeln wird mittels einer Event
          Processing Language (EPL) vorgenommen. Bisher hat sich hierfür aller-




                                                  n
          dings noch kein Standard herausgebildet, so dass jede Engine eine spe-




                                            io
          zifische EPL verwendet (vgl. [2]). Grob lassen sich die verschiedenen
          Event Processing Languages zumindest in drei Gruppen kategorisieren
          (vgl. [4] und [7]):
                                       rs
                               Ve
            -   Datenstromorientierte Sprachen: Diese Sprachen basieren auf der
                bekannten Datenbankanfragesprache SQL (Structured Query Lan-
                guage) und verfolgen das Prinzip, dass Datenströme, in denen
                          e

                Events als Datensätze enthalten sind, in Relationen transformiert
                werden, auf denen dann Anfragen zu jedem Zeitpunkt einer dis-
                    ig



                kreten Zeitachse ausgeführt werden. Die Anfrageergebnisse wer-
                den anschließend wieder in einen Datenstrom überführt.
                uf




            -   Regelbasierte Sprachen: Der Ursprung dieser Sprachen liegt in
      rlä




                Systemen für das Business Rule Management. Sie arbeiten meist
                nach dem Prinzip »Event – Condition – Action«, d.h. es wird ein
                Event spezifiziert, das die Ausführung der Regel triggert, welche
     Vo




                bei Vorliegen einer wahren Bedingung eine vordefinierte Aktion
                unmittelbar auslöst.

            -   Imperative Sprachen: Hierbei handelt es sich um spezifische
                Skriptsprachen, die eigens für das Event Processing entwickelt
                wurden.

      •   Ereignissenke (Event Sink): Die vom Event Processing Agent über ei-
          nen Event Channel emittierten Events werden von Ereignissenken emp-
          fangen. Hierfür sind wiederum Adapter notwendig, um die Nachrichten
          in ein für die Ereignissenke verarbeitbares Format zu übersetzen. Bei-
          spiele für Ereignissenken, die allerdings nicht Teil des Event Processing
          Tools sein müssen, sind:

            -   Event Monitor Software: Anzeige der derzeit ablaufenden Events
                (zum Beispiel in Form eines Logs)




10
-   Dashboards: graphische Visualisierung von Events oder Zustän-
                                   den, zum Beispiel mit Hilfe verschiedener Diagramme

                               -   Benachrichtigungsdienste: E-Mail- oder SMS-Nachrichten, die Per-
                                   sonen über bestimmte Events informieren (Notifications bzw.
                                   Alerts)

                               -   Beliebige Dritt-Applikationen: Auslösen von unmittelbaren Reakti-
                                   onen auf relevante Events (zum Beispiel Handelsplattformen, die
                                   basierend auf Kursveränderungen bestimmte automatische
                                   Transaktionen auslösen oder Systeme für die automatisierte Aus-
                                   führung von Geschäftsprozessen)




                                                                     n
                                                                io
                               -   Datenbanken: Speicherung von relevanten Ereignissen für die spä-
                                   tere Auswertung
                                                          rs
                             Häufig werden diese ausgehenden Events von der Event Processing En-
                                                  Ve
                             gine in ein Event Topic auf einem Event Bus veröffentlicht (Publish), für
                             das sich verschiedene Ereignissenken anmelden können (Subscribe), so
                             dass durch eine solch lose Kopplung alle relevanten Ereignissenken
                                             e

                             gleichzeitig über das erkannte Event Pattern informiert werden.
                                       ig



                      Ein beispielhaftes System für das Event Processing, welches diese Grundkom-
                      ponenten enthält, wird in Abbildung 1 veranschaulicht (in Anlehnung an [1],
                                   uf




                      [6] und [7]):
                         rlä




Abbildung 1: Grund-
komponenten eines
Event Processing
                 Vo




Systems




                      Im Kern besteht ein Event Processing Tool aus dem Event Processing Agent und
                      meist aus verfügbaren Adaptern zu bestimmten Ereignisquellen und -senken.
                      Daneben bieten die meisten dedizierten Event Processing Tools noch verschie-
                      dene weitere Komponenten und Funktionalitäten, um ihren Einsatz möglichst
                      benutzerfreundlich zu gestalten. Die wichtigsten zusätzlichen Komponenten
                      werden im Folgenden erläutert:



                                                                                                    11
•   Dashboard: Mit Hilfe von Visualisierungsanwendungen können Events
          graphisch oder textuell dargestellt werden. Dafür stehen bei den meis-
          ten Event Processing Tools in der Regel eine Vielzahl an unterschiedli-
          chen Diagrammtypen zur Verfügung, die mit Events verknüpft werden
          können und zur Laufzeit per Push-Prinzip aktualisiert werden. Ge-
          bräuchlich sind unter anderem Zähler, Torten-, Balken- und Liniendia-
          gramme sowie Fortschrittsbalken. Der Benutzer kann sich auf diese
          Weise schnell eine Übersicht über das derzeit ablaufende Geschehen
          verschaffen. Oft kann der aktuelle Status mit historischen Daten aus Da-
          tenbanken angereichert werden, um zusätzliche Informationen zu ge-
          winnen. Allerdings enthalten nicht alle Event Processing Tools derartige




                                                 n
          Visualisierungskomponenten. In diesen Fällen kann eventuell eine vor-
          gefertigte Dashboardapplikation eines anderen Anbieters eingesetzt




                                            io
          werden, oder die Events werden an eigenentwickelte Lösungen zur Vi-
          sualisierung übergeben.

      •
                                      rs
          Entwicklungs- und/oder Modellierungsumgebung: Viele auf dem
                               Ve
          Markt angebotenen Event Processing Tools enthalten Entwicklungsum-
          gebungen für die Formulierung der Event Processing Rules in der jewei-
          ligen Event Processing Language (EPL) der verwendeten Laufzeitumge-
                         e

          bung. Teilweise können Regeln sogar graphisch modelliert werden,
                    ig


          welche dann intern in die EPL überführt werden. Einige Lösungen set-
          zen ausschließlich auf die Code-basierte Definition von Regeln mittels
              uf




          einer EPL, einige bieten nur ein graphisches Interface für diesen Zweck
          an, manche Produkte beides. Auch für die Gestaltung von Dashboards
          werden zum Teil Modellierungstools bereitgestellt, mit denen die Plat-
      rlä




          zierung der Visualisierungselemente und die Verknüpfung ihrer Werte
          mit den entsprechenden Events und deren Attributen benutzerfreund-
          lich durchgeführt werden können.
     Vo




      •   Analysetools: Mit Hilfe von Reportgeneratoren können Auswertungen
          von Events erzeugt werden. Teilweise sehen Event Processing Tools
          auch entsprechende Event Datenbanken vor, in denen eine Historie re-
          levanter Events abgelegt werden kann. Erzeugte Reports können zum
          Teil auf Remotesystemen oder als Dokument im PDF- oder HTML-
          Format exportiert werden. Nicht alle Lösungen bieten diese Komponen-
          te an, so dass die Events vom Event Processing Agent an externe Appli-
          kationen übergeben werden müssen, wenn derartige Analysen durch-
          geführt werden sollen.

      •   Enterprise Service Bus (ESB): Mit Hilfe eines Enterprise Service Bus
          (ESB) können Nachrichten zwischen Quelle und Ziel transportiert, trans-
          formiert und geroutet werden. Dies können innerhalb einer EDA bei-
          spielsweise Events oder vom Event Processing Agent ausgelöste Reakti-
          onen sein, aber auch Web Service Aufrufe aus einem automatisierten



12
Geschäftsprozess heraus. Viele Event Processing Tools sehen zumindest
       die Anbindung an einen ESB vor, um Ereignisse zu lesen und abzuset-
       zen. Manche Lösungen bieten sogar eine ESB-Implementation im Rah-
       men des Produktes mit an bzw. offerieren diese in ihrer Produktpalette.
       Die Anbindung an einen ESB ist für das Event Processing jedoch nicht
       zwingend notwendig, Events können auch direkt (zum Beispiel mittels
       eines selbstentwickelten Adapters) an den Event Processing Agent oder
       eine Ereignissenke gesendet werden.

Je nach Produkt sind mehr oder weniger dieser zusätzlichen Komponenten in
verschiedenen Ausprägungen vorhanden. Die Marktübersicht im nächsten Ka-
pitel liefert einen Überblick über die Funktionalitäten der zur Zeit am Markt be-




                                                n
findlichen Event Processing Tools. Dabei werden sowohl kommerzielle Produk-




                                          io
te betrachtet, als auch konkurrenzfähige Open Source Produkte.


                                     rs
                             Ve
                       e
                  ig
           uf
   rlä
Vo




                                                                               13
2     Marktübersicht

                In diesem Kapitel werden die derzeit bedeutsamsten Event Processing Tools in
                einer Marktübersicht gegenübergestellt. Zunächst wird die Vorgehensweise bei
                der Erstellung der Marktübersicht erläutert und das verwendete Kriterienraster
                definiert. Anschließend werden die am Markt verfügbaren Produkte einzeln im
                Detail beschrieben und zum Abschluss des Kapitels in einer tabellarischen
                Übersicht zusammengefasst.




                                                               n
2.1   Vorgehensweise bei der Erstellung der Marktübersicht




                                                         io
                Die verfügbaren Produkte für das Event Processing wurden durch Online-
                Recherche und durch das Studium einschlägiger Fachliteratur identifiziert. An-
                                                    rs
                schließend wurden diese bezüglich der in Abschnitt 1.2 behandelten Kompo-
                nenten und insbesondere des im folgenden Abschnitt spezifizierten
                                            Ve
                Kriterienrasters untersucht. Die Informationen wurden im Wesentlichen mittels
                Online-Recherche auf den Webseiten der Anbieter zusammengetragen und
                zum Teil durch das Studium der verfügbaren Dokumentation ergänzt.
                                       e
                                 ig


                Eine detaillierte Evaluation der Produkte mittels Testinstallationen oder Befra-
                gungen der Anbieter war im Rahmen dieser Betrachtung nicht vorgesehen und
                              uf




                wurde daher auch ausdrücklich nicht durchgeführt. Informationen, die nach in-
                tensiver Online-Recherche nicht verfügbar waren, bleiben somit auch unbe-
                rücksichtigt.
                   rlä




                Die Erstellung der Marktübersicht erfolgte im Zeitraum von Anfang Januar bis
                Ende März 2010. Im August 2010 wurde die Marktübersicht überarbeitet.
           Vo




2.2   Kriterienraster

                Die Darstellung orientiert sich an folgendem Kriterienraster, das größtenteils
                auf den in Abschnitt 1.2 prinzipiell erläuterten Komponenten von Event Proces-
                sing Tools basiert:

                   •    Allgemeine Daten zum Anbieter und Produkt:

                          -   Name des Anbieters
                          -   Name des Produktes
                          -   Website

                   •    Vom Produkt unterstützte Betriebssysteme




14
•   Art von Softwarelizenz, der das Produkt unterliegt (kommerziell oder
     Open Source)

 •   Softwareart des Produktes mit der Unterscheidung in Event Processing
     Agent und Komplettsystem, wobei sich letzteres auf das Vorhandensein
     zusätzlicher Komponenten über die reine Eventverarbeitung hinaus be-
     zieht (siehe auch Abschnitt 1.2)

 •   Branchenfokus, sofern ein solcher explizit genannt wird

 •   Verbreitung des Produktes, sofern dazu eine Angabe gemacht werden




                                            n
     kann




                                       io
 •   Referenzkunden, sofern diese genannt werden (gegebenenfalls aus-
     zugsweise), wobei vorrangig Unternehmen im deutschsprachigen Raum
     aufgeführt werden            rs
                          Ve
 •   Vorhandensein einer Engine für Event Stream Processing und/oder
     Complex Event Processing: in der textuellen Beschreibung werden diese
     Engines meist im Detail beschrieben, wobei auch Angaben zur Skalier-
                    e

     barkeit und Verarbeitungsgeschwindigkeit gemacht werden, falls dies
               ig


     möglich ist; ein besonderer Augenmerk wurde auch auf Art und Um-
     fang der mitgelieferten Adapter gelegt, von denen die Wichtigsten auf-
           uf




     geführt werden

 •   Sprachtyp der Event Processing Language (EPL), nach den im vorherge-
 rlä




     henden Abschnitt genannten drei Kategorien:
Vo




       -   Datenstromorientiert
       -   Regelbasiert
       -   Imperativ

 •   Vorhandensein einer mit den üblichen Funktionalitäten ausgestatteten
     integrierten Entwicklungsumgebung (Integrated Development Environ-
     ment, IDE) für die Entwicklung von Event Processing Rules in einer EPL

 •   Vorhandensein einer Möglichkeit für die graphische Modellierung von
     Event Processing Rules: das Kriterium gilt als erfüllt, wenn mindestens
     entsprechende Assistenten zur Regelerstellung vorhanden sind; manche
     Produkte sehen aber auch ausgereifte graphische Modellierungstools
     (beispielsweise mit Drag-and-Drop-Funktionalität) vor, was entspre-
     chend in der textuellen Beschreibung erwähnt wird

 •   Möglichkeiten für Debugging oder Simulation: das Kriterium gilt als er-
     füllt, wenn mindestens die Möglichkeit vorhanden ist, EPL Code in der



                                                                            15
IDE zu debuggen und/oder Testanfragen an den Event Processing Agent
                     zu senden; manche Lösungen sehen aber auch sehr komplexe Mecha-
                     nismen zur Durchführung von Simulationen vor, was entsprechend im
                     Text vermerkt wird

                 •   Vorhandensein einer Konsole (Event Monitor) zur textuellen Darstellung
                     der vom Event Processing Agent registrierten Events

                 •   Vorhandensein eines Dashboards zur graphischen Visualisierung von
                     Events in Echtzeit, gegebenenfalls mit der Möglichkeit zur Durchfüh-
                     rung weiterführender Analysen (zum Beispiel mittels Drill-Down-




                                                             n
                     Funktionalität); sofern angegeben, werden die wichtigsten zur Verfü-
                     gung gestellten Diagrammtypen in der textuellen Beschreibung aufge-




                                                       io
                     führt

                 •
                                                  rs
                     Möglichkeit, das Layout und/oder das Verhalten von Dashboards über
                     eine graphische Benutzeroberfläche zu gestalten, zum Beispiel mittels
                                          Ve
                     Widgets

                 •   Vorhandensein einer Event Datenbank, in der Events und/oder Alerts
                                     e

                     gespeichert werden können, zum Beispiel für die spätere Durchführung
                               ig


                     von Auswertungen
                         uf




                 •   Möglichkeit, Events zum Zwecke der Weiterverarbeitung zu exportier-
                     ten: das Kriterium gilt als erfüllt, wenn mindestens der Export in eine
                     externe Datenbank oder in eine Datei (zum Beispiel CSV) möglich ist
                 rlä




                 •   Vorhandensein von Werkzeugen für die Generierung von Reports oder
           Vo




                     Auswertungen: sofern angegeben, werden die zur Verfügung gestellten
                     Exportmöglichkeiten für die generierten Reports (zum Beispiel PDF,
                     HTML, Microsoft Word) in der textuellen Beschreibung angeführt

                 •   Vorhandensein einer Anbindung an einen Enterprise Service Bus (ESB):
                     das Kriterium gilt als erfüllt, wenn mindestens eine bedeutsame ESB-
                     Implementation unterstützt wird

2.3   Produktbeschreibungen

              Insgesamt wurden 20 Lösungen betrachtet, die als Mindestanforderung einen
              Event Processing Agent enthalten müssen. Aufgrund des Umstands, dass eini-
              ge Produkte keine Visualisierungskomponente enthalten, wurde zusätzlich die
              Dashboardsoftware RTView in die Betrachtung aufgenommen, da sich in Ver-
              bindung mit einem reinen Event Processing Agent damit ein vollständiges Real-
              Time Monitoring System realisieren lässt.




16
Folgende Produkte wurden untersucht, wobei sich die Reihenfolge aus einer
                          alphabetischen Sortierung nach den Produktnamen ergibt und die reine
                          Dashboardlösung RTView den Abschluss der Betrachtung bildet:

                              •    Sybase Aleri Streaming Platform / CEP
                              •    Progress Apama
                              •    TIBCO BusinessEvents & Spotfire
                              •    ruleCore CEP Server
                              •    Truviso Continuous Analytics
                              •    UC4 Decision & Insight
                              •    JBoss Drools Fusion




                                                                                       n
                              •    Oracle EDA Suite
                              •




                                                                                io
                                   EsperTech Esper
                              •    Event Zero Event Processing Network
                              •
                              •
                                   StreamBase Event Processing Platform
                                                                         rs
                                   Open ESB Intelligent Event Processor (IEP)
                                                               Ve
                              •    Vitria M3O Analytic Server & M3O Operations Book
                              •    Realtime Monitoring RTM Analyzer
                              •    Informatica Rulepoint
                                                        e

                              •    Starview Smart Enterprise Platform
                              •    Microsoft StreamInsight
                                                 ig



                              •    Axway Synchrony Sentinel
                              •    West Global Vantify Experience Center
                                         uf




                              •    IBM WebSphere Business Events
                              •    SL RTView
                              rlä




                          Das im Forschungsumfeld häufig erwähnte Event Processing Tool AMiT (Active
                          Middleware Technology)4 von IBM wird in dieser Marktübersicht nicht unter-
                    Vo




                          sucht, da es sich hierbei um ein Forschungsprodukt handelt, zu dem kein Pro-
                          duktblatt und nur wenig Informationen verfügbar sind.




4   Weitere Informationen unter https://www.research.ibm.com/haifa/dept/services/soms_ebs.html




                                                                                                      17
2.3.1 Sybase Aleri Streaming Platform / CEP

                Name des Anbieters                     Sybase
                Name des Produktes                     Aleri Streaming Platform / CEP
                Website             http://www.aleri.com/products
                Unterstützte Betriebssysteme           Windows, Linux, Solaris
                Lizenztyp                              Kommerziell
                Softwareart                            Komplettsystem




                                                              n
                Branchenfokus                          Keiner, aber Trading, RFID und Cus-
                                                       tomer Relationship Management




                                                       io
                                                       (CRM) explizit genannt
                Verbreitung
                                                     rsStark verbreitet (vgl. [11] - gemein-
                                                       sam mit Coral8, das mittlerweile in
                                            Ve
                                                       Sybase CEP übergegangen ist)
                Referenzkunden                         Commerzbank, Barclays, ING
                Event Stream Processing                Ja
                                       e


                Complex Event Processing               Ja
                                 ig



                EPL Sprachtyp                          Datenstromorientiert
                            uf




                Entwicklungsumgebung für EPL           Ja
                  rlä




                Graphische Modellierungstools für      Ja (Aleri Studio) /
                EPL                                    Nein (CEP Studio)
                Debugging und Simulation               Ja
           Vo




                Event Monitor                          Ja
                Dashboard                              Ja
                Graphische Modellierungstools für      Ja
                Dashboard
                Event Datenbank                        Nein
                Export von Events für statistische     Ja
                Zwecke
                Auswertungs- und Analysetools          Ja
                ESB-Anbindung                          Ja




18
Beschreibung des Event Processing Agents

                         Sybase hat neben der Aleri Streaming Platform die ehemalige Coral8 CEP-
                         Engine (unter dem Namen Sybase CEP) in ihre Produktpalette integriert, die
                         früher als eigenständige Produkte auf dem Markt angeboten wurden.

                         Bei der Aleri Streaming Platform stehen Adapter für verschiedene Messaging-
                         systeme (z.B. TIBCO Rendezvous, IBM WebSphere MQ und JMS), Datenbanken
                         (via ODBC und JDBC), Sockets, Dateien, SMTP, XML, CSV und weitere zur Ver-
                         fügung, insbesondere auch spezielle Adapter für Finanzmarktdaten. Mittels
                         APIs für C++, Java und .NET können auch eigene Adapter entwickelt werden.




                                                                                    n
                         Auch Sybase CEP stellt ähnlich viele Adapter zur Verfügung wie die Aleri




                                                                             io
                         Streaming Platform. Zudem können ebenfalls eigene Adapter mit C/C++, C#,
                         Java, Perl und Python entwickelt werden.
                                                                       rs
                         Die Verarbeitungsgeschwindigkeit wird mit einigen 100.000 Events (Aleri
                                                             Ve
                         Streaming Platform) bis zu einer Million Events (Sybase CEP) pro Sekunde an-
                         gegeben. Die Reaktionszeit soll dabei im Millisekundenbereich liegen.
                                                      e

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



                         Beschreibung der Event Processing Language
                                       uf




                         Für die Aleri Streaming Engine kommt die sogenannte Aleri SQL zum Einsatz,
                              rlä




                         die eine Real-Time Erweiterung für SQL zur Verfügung stellt. Daneben kann die
                         Skriptsprache Aleri SPLASH verwendet werden, die eine Java-ähnliche Syntax
                         besitzt. Im Aleri Studio können Event Processing Rules zudem auch graphisch
                   Vo




                         modelliert werden (vgl. Abbildung 25).

                         Die für die Sybase CEP Engine verwendete Continuous Computation Language
                         (CCL) ist ebenfalls SQL-basiert mit den erforderlichen Erweiterungen für konti-
                         nuierliche Datenanfragen. Ein BPEL-to-CCL-Compiler wird für die Verarbeitung
                         von in BPEL dargestellten Geschäftsprozessen eingesetzt. Für die Entwicklung
                         steht eine Eclipse-basierte IDE zur Verfügung (Sybase CEP Studio), die aller-
                         dings keine graphische Modellierung zulässt.




5   Abbildung entnommen aus http://www.sybase.com/files/Data_Sheets/Sybase_Aleri_StreamingPlatform_ds.pdf




                                                                                                            19
Abbildung 2: Model-
lierung mit dem
Sybase Aleri Studio




                                                                   n
                                                              io
                      Beschreibung des Dashboards
                                                         rs
                                                 Ve
                      Mit Sybase Dashboard, einer auf SL RTView (siehe Abschnitt 2.3.21) basieren-
                      den Komponente, können individuelle Dashboards graphisch modelliert wer-
                      den. Es steht eine Vielzahl von verschiedenen graphischen und textuellen Dar-
                                            e

                      stellungskomponenten zur Verfügung, unter anderem Torten-, Balken- und Li-
                      niendiagramme. Die Selektion und Filterung von Daten durch den Endbenutzer
                                       ig



                      ist innerhalb der Anwendung möglich.
                                uf
                         rlä
                 Vo




20
2.3.2 Progress Apama

               Name des Anbieters                     Progress
               Name des Produktes                     Apama
               Website             http://web.progress.com/en-gb/apama/index.html
               Unterstützte Betriebssysteme           Windows, Linux, Solaris
               Lizenztyp                              Kommerziell
               Softwareart                            Komplettsystem




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




                                                      io
                                                      Logistik geeignet
               Verbreitung
                                                    rsSehr stark verbreitet, ca. 20% Markt-
                                                      anteil bei CEP Software im Jahr 2008
                                           Ve
                                                      (vgl. [12])
               Referenzkunden                         Deutsche Bank, ABN Amro, SEB
               Event Stream Processing                Ja
                                      e


               Complex Event Processing               Ja
                                ig



               EPL Sprachtyp                          Imperativ
                           uf




               Entwicklungsumgebung für EPL           Ja
                 rlä




               Graphische Modellierungstools für      Ja
               EPL
               Debugging und Simulation               Ja
          Vo




               Event Monitor                          Ja
               Dashboard                              Ja
               Graphische Modellierungstools für      Ja
               Dashboard
               Event Datenbank                        Ja
               Export von Events für statistische     Ja
               Zwecke
               Auswertungs- und Analysetools          Ja
               ESB-Anbindung                          Ja




                                                                                         21
Beschreibung des Event Processing Agents

                        Die Event Processing Engine wird vom Anbieter als Correlator bezeichnet. Das
                        Apama Integration Adapter Framework (IAF) stellt die Anbindung der Architek-
                        tur an Ereignisquellen und -senken sicher. Neben einigen finanzmarktspezifi-
                        schen Datenformaten kann IAF auch mit ODBC/JDBC- und KDB+-
                        Datenbankanbindungen sowie RFID-Signalen umgehen und beherrscht auch
                        verschiedene Nachrichtentransportprotokolle wie TCP, UDP, CORBA, Java RMI
                        und ESB-Anbindungen (JMS und TIBCO Rendezvous). Sollte dies nicht ausrei-
                        chen, können mittels einer API auch individuelle Adapter in Java, C oder C++
                        entwickelt werden.




                                                                                  n
                        Die Verarbeitungsgeschwindigkeit des Correlators wird mit mehreren 10.000




                                                                           io
                        Events pro Sekunde angegeben, während die Reaktionszeit im Sub-Milli-
                        sekundenbereich liegen soll. Eine Steigerung der Skalierung ist durch Parallel-
                        schaltung möglich.
                                                                     rs
                                                           Ve
                        Für die Administration steht eine graphische Konsole zur Verfügung.
                                                     e

                        Beschreibung der Event Processing Language
                                              ig



                        Für die Definition von Event Processing Rules wird die imperative Skriptsprache
                        MonitorScript genutzt. Daneben kann alternativ auch Java verwendet werden.
                                      uf




                        Mit dem Apama Studio steht eine Eclipse-basierte Entwicklungsumgebung zur
                        Verfügung, mit der auch eine graphische Modellierung möglich ist (vgl. Abbil-
                             rlä




                        dung 36), wobei eine interne Transformation in MonitorScript vorgenommen
                        wird. Auch werden Debugging- und Profiling-Funktionalitäten bereitgestellt.
                    Vo




Abbildung 3: Ent-
wicklung mit dem
Progress Apama
Studio




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




22
Beschreibung des Dashboards

                         Mit Hilfe des Apama Dashboard Builders, der auf SL RTView (siehe Abschnitt
                         2.3.21) basiert, können individuelle Dashboards graphisch modelliert werden.
                         Es stehen etwa 120 verschiedene Komponenten (zum Beispiel Zähler oder viel-
                         fältige Diagrammtypen) zur Verfügung, die von der Event Processing Engine
                         übergebene Events in Echtzeit darstellen können. Daten können dabei auch
                         gefiltert, aggregiert und konvertiert werden. Die Anzeige ist sowohl im Client
                         als auch online über einen Webbrowser möglich. Ein beispielhaftes Apama
                         Dashboard ist in Abbildung 47 dargestellt.

Abbildung 4: Model-




                                                                                      n
lierung mit dem




                                                                            io
Progress Apama
Dashboard Builder


                                                                      rs
                                                            Ve
                                                      e
                                               ig
                                       uf




                         Beschreibung der Ausgabe und Reportingfunktionen
                             rlä




                         Events können in der Datenbank, dem so genannten Event Store, abgelegt und
                         mit Hilfe der im Research Studio enthaltenen Analysewerkzeuge ausgewertet
                   Vo




                         werden.




7   Abbildung entnommen aus http://web.progress.com/en/apama/dashboard-builder.html




                                                                                                     23
2.3.3 TIBCO BusinessEvents & Spotfire

                Name des Anbieters                     TIBCO
                Name des Produktes                     BusinessEvents (Event Processing
                                                       Agent) & Spotfire (Dashboard)
                Website             http://www.tibco.com/software/complex-event-
                                    processing/businessevents/default.jsp
                Unterstützte Betriebssysteme           Windows, Linux, Solaris, HP UX
                Lizenztyp                              Kommerziell




                                                              n
                Softwareart                            Komplettsystem




                                                       io
                Branchenfokus                          Keiner, aber Produktion, Verkauf,
                                                       Verteidigung und Gesundheit explizit
                                                     rsgenannt
                                            Ve
                Verbreitung                            Sehr stark verbreitet, ca. 40% Markt-
                                                       anteil bei CEP Software im Jahr 2008
                                                       (vgl. [12])
                                       e

                Referenzkunden                         Air France, Vodafone, Markant
                                 ig


                Event Stream Processing                Ja
                Complex Event Processing               Ja
                            uf




                EPL Sprachtyp                          Regelbasiert
                  rlä




                Entwicklungsumgebung für EPL           Ja
                Graphische Modellierungstools für      Ja
           Vo




                EPL
                Debugging und Simulation               K.A.
                Event Monitor                          Ja
                Dashboard                              Ja (Spotfire)
                Graphische Modellierungstools für      Ja (Spotfire)
                Dashboard
                Event Datenbank                        Ja
                Export von Events für statistische     Ja
                Zwecke
                Auswertungs- und Analysetools          K.A.
                ESB-Anbindung                          Ja




24
Beschreibung des Event Processing Agents

                           Als Adapter werden Web Services und ESB-Implementationen wie JMS und
                           TIBCO Rendezvous unterstützt. Ferner stehen Datenbankanbindungen über
                           JDBC zur Verfügung.

                           Mehrere Event Processing Engines können zur Erhöhung der Verarbeitungsge-
                           schwindigkeit parallel geschaltet werden.

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




                                                                                          n
                           Beschreibung der Event Processing Language




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

                           Mit Hilfe der TIBCO Spotfire Komponente können Events visualisiert werden. Es
                           handelt sich dabei um eine eigene Analyse- und Visualisierungskomponente,
                                                  ig



                           die allerdings an TIBCO BusinessEvents angebunden werden kann. Es kann da-
                           bei auf eine Vielzahl an unterschiedlichen Diagrammtypen zurückgegriffen
                                          uf




                           werden, unter anderem Graphen, Torten-, Balken- und Liniendiagramme, Kar-
                           ten usw. Die Dashboards können graphisch modelliert werden. Abbildung 58
                               rlä




                           zeigt ein exemplarisches TIBCO Spotfire Dashboard.

Abbildung 5: Exemp-
                     Vo




larisches TIBCO
Spotfire Dashboard




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




                                                                                                                      25
Beschreibung der Ausgabe und Reportingfunktionen

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




                                                 n
                                            io
                                       rs
                               Ve
                          e
                     ig
               uf
        rlä
     Vo




26
2.3.4 ruleCore CEP Server

                Name des Anbieters                     ruleCore
                Name des Produktes                     CEP Server
                Website             http://www.rulecore.com/
                Unterstützte Betriebssysteme           K.A.
                Lizenztyp                              Kommerziell
                Softwareart                            Event Processing Agent




                                                               n
                Branchenfokus                          Keiner, aber RFID-Anwendungen und
                                                       Netzwerküberwachung als mögliche




                                                       io
                                                       Anwendungsgebiete genannt
                Verbreitung
                Referenzkunden
                                                     rsK.A.
                                                       K.A.
                                            Ve
                Event Stream Processing                Ja
                Complex Event Processing               Ja
                                       e

                EPL Sprachtyp                          Regelbasiert
                                 ig



                Entwicklungsumgebung für EPL           Nein
                            uf




                Graphische Modellierungstools für      Nein
                EPL
                  rlä




                Debugging und Simulation               Nein
                Event Monitor                          Nein
           Vo




                Dashboard                              Nein
                Graphische Modellierungstools für      Nein
                Dashboard
                Event Datenbank                        Nein
                Export von Events für statistische     Ja
                Zwecke
                Auswertungs- und Analysetools          Nein
                ESB-Anbindung                          Ja




                                                                                      27
Beschreibung des Event Processing Agents

     Adapter sind unter anderem für JMS, Web Services und REST vorhanden.
     Sämtliche ein- und ausgehenden Events werden in XML dargestellt. Das Modul
     für die Aufnahme und Ausgabe von Events basiert auf dem Open Source En-
     terprise Service Bus Mule ESB. Die Event Processing Engine kann auf mehrere
     Server verteilt werden, so dass eine skalierbare Anwendung möglich ist.


     Beschreibung der Event Processing Language

     Die von ruleCore verwendete deklarative Abfragesprache Reakt ist eine regel-




                                                   n
     basierte EPL, die auf XML basiert.




                                             io
                                        rs
                                Ve
                           e
                      ig
                uf
        rlä
     Vo




28
2.3.5 Truviso Continuous Analytics

                Name des Anbieters                      Truviso
                Name des Produktes                      Continuous Analytics
                Website             http://www.truviso.com/continuous-analytics-
                                    technology.php
                Unterstützte Betriebssysteme            Linux
                Lizenztyp                               Kommerziell
                Softwareart                             Komplettsystem




                                                                n
                Branchenfokus                           Keiner, aber Web Analytics,




                                                        io
                                                        Advertizing Analytics, Video Analytics
                                                        sowie Trading explizit genannt
                Verbreitung                          rs K.A.
                                            Ve
                Referenzkunden                          K.A.
                Event Stream Processing                 Ja
                                       e

                Complex Event Processing                Nein
                                 ig


                EPL Sprachtyp                           Datenstromorientiert
                Entwicklungsumgebung für EPL            Ja
                            uf




                Graphische Modellierungstools für       K.A.
                  rlä




                EPL
                Debugging und Simulation                K.A.
           Vo




                Event Monitor                           K.A.
                Dashboard                               Ja
                Graphische Modellierungstools für       Ja
                Dashboard
                Event Datenbank                         Ja
                Export von Events für statistische      Ja
                Zwecke
                Auswertungs- und Analysetools           Ja
                ESB-Anbindung                           Nein




                                                                                            29
Beschreibung des Event Processing Agents

     Als Adapter werden JMS, SOAP, REST, XML, CSV und Textdateien mit Rohda-
     ten unterstützt sowie Datenbankanbindungen über JDBC.

     Die so genannte TruSQL Engine verarbeitet sowohl Datenströme in Echtzeit, als
     auch persistierte Daten, so dass sowohl historische als auch vorausschauende
     Analysen ermöglicht werden. Der Hersteller wirbt mit einer Verarbeitungsper-
     formance von 500.000 Datensätzen pro Sekunde.


     Beschreibung der Event Processing Language




                                                    n
                                               io
     Als Event Processing Language kommt SQL zum Einsatz, die für kontinuierliche
     Datenanfragen erweitert wurde, so dass sich Zeit- und Datenfenster auf den
                                         rs
     Eventströmen ausdrücken lassen. Kontinuierliche Datenanfragen erzeugen wei-
     tere auswertbare Datenströme.
                                 Ve
     Beschreibung des Dashboards
                            e


     Das so genannte TruView Framework ermöglicht die Erstellung von anpassba-
                      ig



     ren Dashboards, die als Webanwendungen auf Adobe Flex basieren und an-
     hand der kontinuierlichen Datenanfragen in Echtzeit aktualisiert werden.
                uf
        rlä




     Beschreibung der Ausgabe und Reportingfunktionen

     Neben der Visualisierung von Daten in einem Dashboard sind auch Alarme in
     Vo




     Form von SMS, E-Mail oder per SNMP möglich und es können andere Systeme
     getriggert werden.

     Eine Reportingfunktionalität ist vorhanden, wird allerdings nicht näher be-
     schrieben.




30
2.3.6 UC4 Decision & Insight

                Name des Anbieters                      UC4
                Name des Produktes                      Decision (Event Processing Agent) &
                                                        Insight (Dashboard)
                Website             http://www.uc4.com/uk/products-solutions/predictive-
                                    pattern-engine/uc4-decision.html
                Unterstützte Betriebssysteme            Windows
                Lizenztyp                               Kommerziell




                                                              n
                Softwareart                             Komplettsystem




                                                        io
                Branchenfokus                           Keiner, aber Trading, Produktion,
                                                        Logistik und IT-Netzwerke beispielhaft
                                                     rs als Anwendungsgebiete genannt
                                            Ve
                Verbreitung                             Stark verbreitet (vgl. [11])
                Referenzkunden                          SBB, T-Systems
                Event Stream Processing                 Ja
                                       e


                Complex Event Processing                Ja
                                 ig



                EPL Sprachtyp                           Regelbasiert
                            uf




                Entwicklungsumgebung für EPL            Ja
                  rlä




                Graphische Modellierungstools für       Ja
                EPL
                Debugging und Simulation                Ja
           Vo




                Event Monitor                           Ja
                Dashboard                               Ja (Insight)
                Graphische Modellierungstools für       Ja (Insight)
                Dashboard
                Event Datenbank                         Ja
                Export von Events für statistische      Ja
                Zwecke
                Auswertungs- und Analysetools           Ja
                ESB-Anbindung                           Ja




                                                                                           31
Beschreibung des Event Processing Agents

                         Decision besitzt eine skalierbare Event Processing Engine. Adapter sind für
                         MSMQ (Microsoft Message Queuing Service), IBM WebSphere MQ, TIBCO
                         Rendezvous, JMS, Web Services und Sockets vorgesehen. Zudem können Da-
                         teien, POP3-Nachrichten und RSS-Feeds ausgelesen und als Events genutzt
                         werden. Datenbankanbindungen existieren für Microsoft SQL Server, IBM DB2,
                         Oracle, MySQL und ODBC. Die Entwicklung eigener Adapter ist ebenfalls mög-
                         lich.

                         Die Verarbeitungsgeschwindigkeit wird mit mehreren Tausend Events pro Se-
                         kunde angegeben.




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

                         Das Modelling Studio sieht die graphische Modellierung von Regeln, Event-
                         strukturen und -korrelationen vor. Die Code-basierte Programmierung in einer
                                              ig



                         EPL ist nicht vorgesehen.
                                       uf




                         Beschreibung des Dashboards
                             rlä




                         Mit Insight steht ein Real-Time Dashboard zur Verfügung, welches als eigenes
                         Produkt auch für Business Intelligence und weiterführende Analysen eingesetzt
                   Vo




                         werden kann. Das Dashboard ist ausgerichtet auf die Visualisierung von Events
                         und besitzt somit neben verschiedenen Diagrammtypen wie Punkt-, Linien-
                         oder Treppendiagrammen auch Visualisierungsmöglichkeiten für Event-Cluster
                         und 3D-Event-Tunnel. Beispielhafte Diagramme mit UC4 Insight sind in Abbil-
                         dung 69 dargestellt.




9   Abbildung entnommen aus http://offer.uc4.com/rs/uc4/images/Web_UC4_Insight_WP_us.pdf




32
Abbildung 6: Bei-
spielhafte Diagram-
me mit UC4 Insight




                                 n
                                io
                                rs
                            Ve
                            e
                        ig
                       uf
                      rlä
                  Vo




                                     33
2.3.7 JBoss Drools Fusion

                Name des Anbieters                      JBoss
                Name des Produktes                      Drools Fusion
                Website             http://www.jboss.org/drools/drools-fusion.html
                Unterstützte Betriebssysteme            Alle mit Java Runtime
                Lizenztyp                               Open Source
                Softwareart                             Event Processing Agent




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




                                                        io
                                                        gebiete genannt
                Verbreitung
                Referenzkunden
                                                     rs Drools 5.0 ca. 2.000 Downloads
                                                        K.A.
                                            Ve
                Event Stream Processing                 Ja
                Complex Event Processing                Ja
                                       e

                EPL Sprachtyp                           Regelbasiert
                                 ig



                Entwicklungsumgebung für EPL            Ja
                            uf




                Graphische Modellierungstools für       Nein
                EPL
                  rlä




                Debugging und Simulation                Ja
                Event Monitor                           Nein
           Vo




                Dashboard                               Nein
                Graphische Modellierungstools für       Nein
                Dashboard
                Event Datenbank                         Nur Anbindung
                Export von Events für statistische      Ja
                Zwecke
                Auswertungs- und Analysetools           Nein
                ESB-Anbindung                           Ja




34
Beschreibung des Event Processing Agents

                          Drools ist eine sogenannte Business Logic Integration Plattform, die als Open
                          Source Produkt der Apache Software License (ASL) unterliegt. Sie besteht aus
                          vier Komponeten:

                              •    Guvnor: Knowledge Repository
                              •    Expert: Rule Engine
                              •    Flow: Geschäftsprozessengine
                              •    Fusion: Event Processing Engine




                                                                              n
                          Drools Fusion kann zusammen mit den anderen Komponenten verwendet
                          werden, was allerdings nicht erforderlich ist. Als Adapter steht eine JMS-




                                                                              io
                          Anbindung zur Verfügung.


                          Beschreibung der Event Processing Language
                                                                        rs
                                                              Ve
                          Die verwendete EPL ist eine deklarative Sprache, die Produktionsregeln auf
                          Events anwenden kann. Für die Entwicklung der Regeln steht eine Eclipse-
                                                       e

                          basierte IDE zur Verfügung, die in Abbildung 710 dargestellt ist.
                                                ig



Abbildung 7: Ent-
wicklung mit JBoss
                                        uf




Drools
                              rlä
                     Vo




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




                                                                                                       35
2.3.8 Oracle EDA Suite

                Name des Anbieters                     Oracle
                Name des Produktes                     EDA Suite
                Website             http://www.oracle.com/us/technologies/soa/eda-
                                    suite/index.html
                Unterstützte Betriebssysteme           Windows, Linux
                Lizenztyp                              Kommerziell
                Softwareart                            Komplettsystem




                                                             n
                Branchenfokus                          Keiner, aber Trading, Telekommuni-




                                                       io
                                                       kation, Handel, Produktion und Ver-
                                                       waltung explizit genannt
                Verbreitung                          rsSehr stark verbreitet (vgl. [11])
                                            Ve
                Referenzkunden                         Monster.com, NH Hotels
                Event Stream Processing                Ja
                                       e

                Complex Event Processing               Ja
                                 ig


                EPL Sprachtyp                          Datenstromorientiert
                Entwicklungsumgebung für EPL           Ja
                            uf




                Graphische Modellierungstools für      Ja
                  rlä




                EPL
                Debugging und Simulation               Ja
           Vo




                Event Monitor                          Ja
                Dashboard                              Ja
                Graphische Modellierungstools für      Ja
                Dashboard
                Event Datenbank                        Ja
                Export von Events für statistische     Ja
                Zwecke
                Auswertungs- und Analysetools          Ja
                ESB-Anbindung                          Ja




36
Beschreibung des Event Processing Agents

                      Oracle verwendet die Esper Event Processing Engine. Als Adapter werden JMS
                      und HTTP sowohl für eingehende als auch ausgehende Events unterstützt. Eine
                      Datenbankanbindung kann über JDBC realisiert werden. Für die Entwicklung
                      eigener Adapter werden entsprechende APIs bereitgestellt. Die Antwortzeit
                      gibt Oracle im Mikrosekundenbereich an.

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


                      Beschreibung der Event Processing Language




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

Abbildung 8: Model-
lierung mit der
                                            ig


Oracle EDA Suite
                                    uf
                           rlä
                 Vo




                      Beschreibung des Dashboards

                      Der CEP Visualizer dient zur Anzeige von Events und kann sowohl von Entwick-
                      lern als auch von Administratoren und Endbenutzern verwendet werden. Die
                      Komponente setzt auf Adobe Flex auf und kann damit über das Web genutzt
                      werden.




11Abbildung entnommen aus http://www.oracle.com/products/middleware/docs/microsite09-flashmedia-pdfs/complex-event-
 processing-datasheet.pdf




                                                                                                                      37
Für das Eventmonitoring selbst bietet Oracle eine Business Activity Monitoring
                       (BAM) Komponente an, die über vielfältige Möglichkeiten zur Anzeige von
                       Events verfügt. Sie kann über JMS, JCA oder Web Services angebunden wer-
                       den. Eine Vielzahl von Diagrammtypen wird unterstützt, unter anderem Torten-
                       und Balkendiagramme, sowie Zähler. Oracle BAM ist eine webbasierte Anwen-
                       dung, die Nutzung der BAM-Komponente ist derzeit allerdings nur mit dem
                       Microsoft Internet Explorer möglich. Abbildung 912 zeigt ein exemplarisches
                       Oracle BAM Dashboard.

Abbildung 9: Exemp-
larisches Oracle BAM
Dashboard




                                                                                  n
                                                                          io
                                                                    rs
                                                          Ve
                                                   e
                                            ig



                       Beschreibung der Ausgabe und Reportingfunktionen
                                    uf




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




12Abbildung entnommen aus http://www.oracle.com/products/middleware/docs/microsite09-flashmedia-pdfs/oracle-bam-
 datasheet.pdf




38
2.3.9 EsperTech Esper

               Name des Anbieters                      EsperTech
               Name des Produktes                      Esper (Event Processing Agent) &
                                                       EsperHQ (Dashboard)
               Website             http://esper.codehaus.org/
               Unterstützte Betriebssysteme            Windows, Linux, Solaris, AIX
               Lizenztyp                               Open Source (Event Processing
                                                       Agent) / Kommerziell (Enterprise Edi-




                                                                n
                                                       tion und zusätzliche Komponenten)




                                                       io
               Softwareart                             Komplettsystem
               Branchenfokus                           Keiner, aber Trading, RFID und CRM
                                                    rs explizit genannt
                                           Ve
               Verbreitung                             Stark verbreitet (vgl. [11])
               Referenzkunden                          swisscom, eBay, HypoVereinsbank,
                                                       Raytheon
                                      e


               Event Stream Processing                 Ja
                                ig



               Complex Event Processing                Ja
                           uf




               EPL Sprachtyp                           Datenstromorientiert
               Entwicklungsumgebung für EPL            Ja (Enterprise Edition)
                  rlä




               Graphische Modellierungstools für       Nein
               EPL
           Vo




               Debugging und Simulation                Ja (Enterprise Edition)
               Event Monitor                           Ja (Enterprise Edition)
               Dashboard                               Ja (Enterprise Edition)
               Graphische Modellierungstools für       Ja (Enterprise Edition)
               Dashboard
               Event Datenbank                         Ja (Enterprise Edition)
               Export von Events für statistische      Ja (Enterprise Edition)
               Zwecke
               Auswertungs- und Analysetools           Nein
               ESB-Anbindung                           Ja




                                                                                          39
Beschreibung des Event Processing Agents

     Die Java-basierte Event Processing Engine ist unter einer Open Source Lizenz
     (GPL V2) erhältlich und kann somit frei heruntergeladen und verwendet wer-
     den. Es ist auch eine Enterprise Edition mit erweiterten Funktionalitäten ver-
     fügbar. Mitgelieferte Adapter unterstützen JMS (inbound und outbound), JDBC
     und CSV sowie .NET, XML und Java Beans. Desweiteren können auch Oracle,
     MySQL und Microsoft SQL Datenbanken angebunden werden. Eigene Adapter
     können mit Hilfe eines API selbst erstellt werden.

     Die EsperHA-Komponente erweitert Esper im Hinblick auf Hochverfügbarkeit
     (Caching, Clustering, Hot-Backup).




                                                   n
                                             io
     Beschreibung der Event Processing Language
                                        rs
     Die EPL verwendet eine SQL-ähnliche Syntax. Für die Entwicklung wird eine
                                Ve
     Eclipse Integration bereitgestellt.
                           e

     Beschreibung des Dashboards
                      ig



     Die Dashboardkomponente EsperHQ ist webbasiert und setzt auf Adobe Flex
     auf. Mit Hilfe dieser kostenpflichtigen Applikation können so genannte
                uf




     Eventlets in einer konfigurierbaren Umgebung graphisch dargestellt werden. Es
     werden Torten- und Balkendiagramme sowie Zähler und einige andere Dia-
        rlä




     grammtypen bereitgestellt, die mit Events verbunden werden können. Assis-
     tenten unterstützen auf Wunsch bei der Modellierung von Dashboards. Alter-
     nativ kann auch ein Code-Editor verwendet werden.
     Vo




     Beschreibung der Ausgabe und Reportingfunktionen

     Events können in eine Datenbank exportiert und für Auswertungszwecke wei-
     terverwendet werden.




40
2.3.10 Event Zero Event Processing Network

                Name des Anbieters                     Event Zero
                Name des Produktes                     Event Processing Network
                Website             http://www.eventzero.com/Solutions/EDA.aspx
                Unterstützte Betriebssysteme           Windows mit .NET
                Lizenztyp                              Kommerziell
                Softwareart                            Komplettsystem




                                                              n
                Branchenfokus                          Keiner




                                                       io
                Verbreitung                            K.A.
                Referenzkunden                         K.A.
                Event Stream Processing              rsJa
                                            Ve
                Complex Event Processing               Ja
                EPL Sprachtyp                          K.A.
                                       e

                Entwicklungsumgebung für EPL           Nein
                                 ig


                Graphische Modellierungstools für      Ja
                EPL
                            uf




                Debugging und Simulation               Nein
                  rlä




                Event Monitor                          Ja
                Dashboard                              Ja
           Vo




                Graphische Modellierungstools für      Ja
                Dashboard
                Event Datenbank                        Ja
                Export von Events für statistische     Ja
                Zwecke
                Auswertungs- und Analysetools          Ja
                ESB-Anbindung                          Ja




                                                                                  41
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report
Fraunhofer institute cep report

Más contenido relacionado

Similar a Fraunhofer institute cep report

Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...ArtemEger
 
Digital Retail Vision
Digital Retail VisionDigital Retail Vision
Digital Retail VisionKai Platschke
 
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und SystemenPLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und SystemenIntelliact AG
 
Log4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfLog4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfStephan Kaps
 
IKT-Trends und deren Bedeutung für eHealth
IKT-Trends und deren Bedeutung für eHealthIKT-Trends und deren Bedeutung für eHealth
IKT-Trends und deren Bedeutung für eHealthFraunhofer AISEC
 
Veriso be benutzerhandbuch_v2_5_d_
Veriso be benutzerhandbuch_v2_5_d_Veriso be benutzerhandbuch_v2_5_d_
Veriso be benutzerhandbuch_v2_5_d_NikolausausBern
 
Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...
Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...
Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...Turgut Dogan
 
Top 10 Internet Trends 2006
Top 10 Internet Trends 2006Top 10 Internet Trends 2006
Top 10 Internet Trends 2006Jürg Stuker
 
Echolot digital worx_crm_vergleich
Echolot digital worx_crm_vergleichEcholot digital worx_crm_vergleich
Echolot digital worx_crm_vergleichdigital worx
 
Die Zukunft des Semantic Web
Die Zukunft des Semantic WebDie Zukunft des Semantic Web
Die Zukunft des Semantic WebGábor Molnár
 
Wertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart Factory
Wertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart FactoryWertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart Factory
Wertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart FactoryLean Knowledge Base UG
 
2D-Codes Grundlagen und Anwendungen in Unternehmen
2D-Codes Grundlagen und Anwendungen in Unternehmen2D-Codes Grundlagen und Anwendungen in Unternehmen
2D-Codes Grundlagen und Anwendungen in UnternehmenUniversity St. Gallen
 

Similar a Fraunhofer institute cep report (20)

Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...
 
Digital Retail Vision
Digital Retail VisionDigital Retail Vision
Digital Retail Vision
 
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und SystemenPLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
 
Log4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfLog4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdf
 
mühlnickel beit_PechaKucha
mühlnickel beit_PechaKuchamühlnickel beit_PechaKucha
mühlnickel beit_PechaKucha
 
IKT-Trends und deren Bedeutung für eHealth
IKT-Trends und deren Bedeutung für eHealthIKT-Trends und deren Bedeutung für eHealth
IKT-Trends und deren Bedeutung für eHealth
 
PM 3D-Laserscans in Virtual Reality
PM 3D-Laserscans in Virtual RealityPM 3D-Laserscans in Virtual Reality
PM 3D-Laserscans in Virtual Reality
 
OSG Volume Rendering
OSG Volume RenderingOSG Volume Rendering
OSG Volume Rendering
 
Veriso be benutzerhandbuch_v2_5_d_
Veriso be benutzerhandbuch_v2_5_d_Veriso be benutzerhandbuch_v2_5_d_
Veriso be benutzerhandbuch_v2_5_d_
 
Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...
Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...
Wie beeinflusst Scrum die Prozess- & Softwarequalität? - Praxisbeispiel SIX ...
 
Top 10 Internet Trends 2006
Top 10 Internet Trends 2006Top 10 Internet Trends 2006
Top 10 Internet Trends 2006
 
[DE] Vom Web 2.0 zum Web 42.0 | Ulrich Kampffmeyer
[DE] Vom Web 2.0 zum Web 42.0 | Ulrich Kampffmeyer[DE] Vom Web 2.0 zum Web 42.0 | Ulrich Kampffmeyer
[DE] Vom Web 2.0 zum Web 42.0 | Ulrich Kampffmeyer
 
Echolot digital worx_crm_vergleich
Echolot digital worx_crm_vergleichEcholot digital worx_crm_vergleich
Echolot digital worx_crm_vergleich
 
geo.admin.ch Stand der Arbeiten / nächste Schritte
geo.admin.ch Stand der Arbeiten / nächste Schrittegeo.admin.ch Stand der Arbeiten / nächste Schritte
geo.admin.ch Stand der Arbeiten / nächste Schritte
 
Die Zukunft des Semantic Web
Die Zukunft des Semantic WebDie Zukunft des Semantic Web
Die Zukunft des Semantic Web
 
Trendreport: Die Zukunft des Semantic Web
Trendreport: Die Zukunft des Semantic WebTrendreport: Die Zukunft des Semantic Web
Trendreport: Die Zukunft des Semantic Web
 
Wertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart Factory
Wertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart FactoryWertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart Factory
Wertstromanalyse 4.0 –Startpunkt und Roadmap zur Smart Factory
 
VDC Newsletter 2011-01
VDC Newsletter 2011-01VDC Newsletter 2011-01
VDC Newsletter 2011-01
 
2D-Codes Grundlagen und Anwendungen in Unternehmen
2D-Codes Grundlagen und Anwendungen in Unternehmen2D-Codes Grundlagen und Anwendungen in Unternehmen
2D-Codes Grundlagen und Anwendungen in Unternehmen
 
Abc 19 06-07-ge
Abc 19 06-07-geAbc 19 06-07-ge
Abc 19 06-07-ge
 

Fraunhofer institute cep report

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