Your SlideShare is downloading. ×
EDA und Complex Event Processing  mit Esper
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

EDA und Complex Event Processing mit Esper

1,690
views

Published on

EDA und Complex Event Processing mit Esper

EDA und Complex Event Processing mit Esper

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,690
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Das Zusammenbringen von komponentenartigen Teilsystemen ist ein Problem, das in sehr unterschiedlichen Bereichen der Softwareentwicklung immer wieder aufgetreten ist. Im Rahmen unternehmenskritischer Anwendungen ist die Kopplung von Systemen innerhalb einer Software- Landschaft eines Unternehmens eine nicht triviale Aufgabe mit der die Softwareindustrie schon lange zu kämpfen hat. \nAlle Integrationsprojekte werden mit folgenden wesentlichen Herausforderungen konfrontiert:\nNetzwerke sind nicht zuverlässigIntegrative Lösungen müssen Daten zwischen einen oder mehrere Systeme transportieren. Diese Systeme sind üblicherweise auf verschiedene Rechner verteilt und miteinander vernetzt. Die zu überwindende Strecke kann sich überschaubar innerhalb  eines Unternehmens befinden, aber sich auch gleich über mehrere Kontinente hinweg erstrecken. Netzwerke sind heterogene Infrastrukturen mit vielen unbekannten beteiligten Systemen. Die möglichen Fehlerursachen steigen mit der Anzahl der beteiligten Netzwerkkomponenten.\nNetzwerke sind langsamNetzwerkverbindungen sind um Magnituden langsamer als lokale Aufrufe. Aus diesem Grund können bisher eigesetzte Architekturen nicht auf stark verteilte Systeme übertragen werden, ohne massive Performance Probleme zu bekommen.\nSysteme sind grundsätzlich verschiedenDie zu integrierenden Systeme haben unterschiedliche Datenstrukturen und setzen oft unterschiedliche Technologien ein. Eine Integration muss diese Hürden effizient lösen.\nÄnderungen sind unvermeidbarAnwendungen werden im Laufe der Zeit verändert. Integrationslösungen müssen mit den Änderungen schritthalten können. Aufgrund der durch Integrationslösungen entstanden Kopplung zwischen ursprünglich autonomen Systemen können Änderungen in einem System Auswirkungen auf das gesamte System haben. Aus diesem Grund dürfen Teilsysteme nur lose miteinander gekoppelt werden.\n
  • Im Laufe der Zeit wurden diese Herausforderungen mit folgenden Ansätzen gelöst:\nDateiübertragungEine Anwendung schreibt eine Datei, die eine andere lesen wird. Anwendungen müssen sich über Ort und Zeitpunkt einig sein, wann diese Dateien geschrieben und gelesen werden. Außerdem muss man sich in Bezug auf die Struktur der Daten in der Datei einigen.\nGemeinsame DatenbankMehrere Anwendungen können sich eine gemeinsame Datenbank teilen. Da keine Daten doppelt gehalten werden, muss auch kein Datentransfer stattfinden. \nEntfernte Methodenaufrufe (Remote Procedure Calls)Eine Anwendung stellt Methoden (bzw. Funktionen) zur Verfügung, die andere Anwendungen aufrufen können. Diese werden auch Dienste bzw. Services genannt. Dienstaufrufe finden in Echtzeit statt und sind synchroner Natur.\nNachrichtendiensteEine Anwendung verschickt Nachrichten in einen gemeinsam verwendeten Nachrichtendienst. Üblicherweise kennt ein Nachrichtendienst mehrere Kanäle (Channels, Destinations). Andere Anwendungen können zu einem späterem Zeitpunkt Nachrichten aus diesem Nachrichten- Kanal abholen. Die Kommunikation zwischen den Systemen findet asynchron statt.\n
  • Im Laufe der Zeit wurden diese Herausforderungen mit folgenden Ansätzen gelöst:\nDateiübertragungEine Anwendung schreibt eine Datei, die eine andere lesen wird. Anwendungen müssen sich über Ort und Zeitpunkt einig sein, wann diese Dateien geschrieben und gelesen werden. Außerdem muss man sich in Bezug auf die Struktur der Daten in der Datei einigen.\nGemeinsame DatenbankMehrere Anwendungen können sich eine gemeinsame Datenbank teilen. Da keine Daten doppelt gehalten werden, muss auch kein Datentransfer stattfinden. \nEntfernte Methodenaufrufe (Remote Procedure Calls)Eine Anwendung stellt Methoden (bzw. Funktionen) zur Verfügung, die andere Anwendungen aufrufen können. Diese werden auch Dienste bzw. Services genannt. Dienstaufrufe finden in Echtzeit statt und sind synchroner Natur.\nNachrichtendiensteEine Anwendung verschickt Nachrichten in einen gemeinsam verwendeten Nachrichtendienst. Üblicherweise kennt ein Nachrichtendienst mehrere Kanäle (Channels, Destinations). Andere Anwendungen können zu einem späterem Zeitpunkt Nachrichten aus diesem Nachrichten- Kanal abholen. Die Kommunikation zwischen den Systemen findet asynchron statt.\n
  • Im Laufe der Zeit wurden diese Herausforderungen mit folgenden Ansätzen gelöst:\nDateiübertragungEine Anwendung schreibt eine Datei, die eine andere lesen wird. Anwendungen müssen sich über Ort und Zeitpunkt einig sein, wann diese Dateien geschrieben und gelesen werden. Außerdem muss man sich in Bezug auf die Struktur der Daten in der Datei einigen.\nGemeinsame DatenbankMehrere Anwendungen können sich eine gemeinsame Datenbank teilen. Da keine Daten doppelt gehalten werden, muss auch kein Datentransfer stattfinden. \nEntfernte Methodenaufrufe (Remote Procedure Calls)Eine Anwendung stellt Methoden (bzw. Funktionen) zur Verfügung, die andere Anwendungen aufrufen können. Diese werden auch Dienste bzw. Services genannt. Dienstaufrufe finden in Echtzeit statt und sind synchroner Natur.\nNachrichtendiensteEine Anwendung verschickt Nachrichten in einen gemeinsam verwendeten Nachrichtendienst. Üblicherweise kennt ein Nachrichtendienst mehrere Kanäle (Channels, Destinations). Andere Anwendungen können zu einem späterem Zeitpunkt Nachrichten aus diesem Nachrichten- Kanal abholen. Die Kommunikation zwischen den Systemen findet asynchron statt.\n
  • Im Laufe der Zeit wurden diese Herausforderungen mit folgenden Ansätzen gelöst:\nDateiübertragungEine Anwendung schreibt eine Datei, die eine andere lesen wird. Anwendungen müssen sich über Ort und Zeitpunkt einig sein, wann diese Dateien geschrieben und gelesen werden. Außerdem muss man sich in Bezug auf die Struktur der Daten in der Datei einigen.\nGemeinsame DatenbankMehrere Anwendungen können sich eine gemeinsame Datenbank teilen. Da keine Daten doppelt gehalten werden, muss auch kein Datentransfer stattfinden. \nEntfernte Methodenaufrufe (Remote Procedure Calls)Eine Anwendung stellt Methoden (bzw. Funktionen) zur Verfügung, die andere Anwendungen aufrufen können. Diese werden auch Dienste bzw. Services genannt. Dienstaufrufe finden in Echtzeit statt und sind synchroner Natur.\nNachrichtendiensteEine Anwendung verschickt Nachrichten in einen gemeinsam verwendeten Nachrichtendienst. Üblicherweise kennt ein Nachrichtendienst mehrere Kanäle (Channels, Destinations). Andere Anwendungen können zu einem späterem Zeitpunkt Nachrichten aus diesem Nachrichten- Kanal abholen. Die Kommunikation zwischen den Systemen findet asynchron statt.\n
  • Im Laufe der Zeit wurden diese Herausforderungen mit folgenden Ansätzen gelöst:\nDateiübertragungEine Anwendung schreibt eine Datei, die eine andere lesen wird. Anwendungen müssen sich über Ort und Zeitpunkt einig sein, wann diese Dateien geschrieben und gelesen werden. Außerdem muss man sich in Bezug auf die Struktur der Daten in der Datei einigen.\nGemeinsame DatenbankMehrere Anwendungen können sich eine gemeinsame Datenbank teilen. Da keine Daten doppelt gehalten werden, muss auch kein Datentransfer stattfinden. \nEntfernte Methodenaufrufe (Remote Procedure Calls)Eine Anwendung stellt Methoden (bzw. Funktionen) zur Verfügung, die andere Anwendungen aufrufen können. Diese werden auch Dienste bzw. Services genannt. Dienstaufrufe finden in Echtzeit statt und sind synchroner Natur.\nNachrichtendiensteEine Anwendung verschickt Nachrichten in einen gemeinsam verwendeten Nachrichtendienst. Üblicherweise kennt ein Nachrichtendienst mehrere Kanäle (Channels, Destinations). Andere Anwendungen können zu einem späterem Zeitpunkt Nachrichten aus diesem Nachrichten- Kanal abholen. Die Kommunikation zwischen den Systemen findet asynchron statt.\n
  • Im Laufe der Zeit wurden diese Herausforderungen mit folgenden Ansätzen gelöst:\nDateiübertragungEine Anwendung schreibt eine Datei, die eine andere lesen wird. Anwendungen müssen sich über Ort und Zeitpunkt einig sein, wann diese Dateien geschrieben und gelesen werden. Außerdem muss man sich in Bezug auf die Struktur der Daten in der Datei einigen.\nGemeinsame DatenbankMehrere Anwendungen können sich eine gemeinsame Datenbank teilen. Da keine Daten doppelt gehalten werden, muss auch kein Datentransfer stattfinden. \nEntfernte Methodenaufrufe (Remote Procedure Calls)Eine Anwendung stellt Methoden (bzw. Funktionen) zur Verfügung, die andere Anwendungen aufrufen können. Diese werden auch Dienste bzw. Services genannt. Dienstaufrufe finden in Echtzeit statt und sind synchroner Natur.\nNachrichtendiensteEine Anwendung verschickt Nachrichten in einen gemeinsam verwendeten Nachrichtendienst. Üblicherweise kennt ein Nachrichtendienst mehrere Kanäle (Channels, Destinations). Andere Anwendungen können zu einem späterem Zeitpunkt Nachrichten aus diesem Nachrichten- Kanal abholen. Die Kommunikation zwischen den Systemen findet asynchron statt.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Die aktuelle Entwicklung im Bereich Vernetzung und Automatisierung von Geschäftsprozessen führen dazu, dass Unternehmen auf immer feinkörnigere Informationen Zugriff haben. Nicht nur die Informationsmenge und Qualität hat sich geändert, auch die Anzahl möglicher elektronischer Reaktionsschnittstellen hat sich erhöht.\nUnter "Real Time Business" versteht man die zeitnahe Auslieferung und Evaluierung von wirtschaftlichen Ereignissen. \nZiel ist es, sehr früh auf Marktbedürfnisse zu reagieren und wirtschaftliche Potentiale zu erkennen. Dieses frühe Erkennen schafft wichtige Wettbewerbsvorteile.\nAlle "Real Time Business Systeme" haben Latenzzeiten: \nInformationslatenz: die benötigte Zeit, Informationen zu sammeln und bereitzustellen.\nAnalyselatenz: die benötigte Zeit, die Informationen zu analysieren und in Aktionen umzuwandeln.\nAktionslatenz: die benötigte Zeit, um Aktionen zu starten.\nHauptziel aller Systeme in Real Time Business ist es, alle 3 beschriebenen Latenzzeiten zu minimieren. Zusätzlich müssen solche Systeme ein sehr hohes Aufkommen an Nachrichten verarbeiten können, üblicherweise sind es mehr als 100.000 Ereignisse pro Sekunde. Aus diesen nicht funktionalen Anforderungen wird deutlich, dass heute üblichen Datenbankorientierte Architekturen nicht der Aufgabe gewachsen sind. Ein Blick in Performancezahlen bei Datenbanken zeigt, dass die Verarbeitung von sehr hohem Aufkommen von Nachrichten problematisch werden könnte. \n
  • Die aktuelle Entwicklung im Bereich Vernetzung und Automatisierung von Geschäftsprozessen führen dazu, dass Unternehmen auf immer feinkörnigere Informationen Zugriff haben. Nicht nur die Informationsmenge und Qualität hat sich geändert, auch die Anzahl möglicher elektronischer Reaktionsschnittstellen hat sich erhöht.\nUnter "Real Time Business" versteht man die zeitnahe Auslieferung und Evaluierung von wirtschaftlichen Ereignissen. \nZiel ist es, sehr früh auf Marktbedürfnisse zu reagieren und wirtschaftliche Potentiale zu erkennen. Dieses frühe Erkennen schafft wichtige Wettbewerbsvorteile.\nAlle "Real Time Business Systeme" haben Latenzzeiten: \nInformationslatenz: die benötigte Zeit, Informationen zu sammeln und bereitzustellen.\nAnalyselatenz: die benötigte Zeit, die Informationen zu analysieren und in Aktionen umzuwandeln.\nAktionslatenz: die benötigte Zeit, um Aktionen zu starten.\nHauptziel aller Systeme in Real Time Business ist es, alle 3 beschriebenen Latenzzeiten zu minimieren. Zusätzlich müssen solche Systeme ein sehr hohes Aufkommen an Nachrichten verarbeiten können, üblicherweise sind es mehr als 100.000 Ereignisse pro Sekunde. Aus diesen nicht funktionalen Anforderungen wird deutlich, dass heute üblichen Datenbankorientierte Architekturen nicht der Aufgabe gewachsen sind. Ein Blick in Performancezahlen bei Datenbanken zeigt, dass die Verarbeitung von sehr hohem Aufkommen von Nachrichten problematisch werden könnte. \n
  • Real Time Business haben viel mehr Daten zur Verfügung\nfeingranularer\nzeitnäher\nsehr haufige Veränderungen der Daten --> die Events\nund schnelle Realtionen gefordert\n\nBy 2008, 67% of new large scale applications will emit business events and 58% of large enterprises will rely on complex event processing. (Gartner, 2005)\n\nFirst among the leading platform vendors, BEA has announced a complex event processing product. This signifies BEA's recognition of the growing importance of event processing in high-end enterprise computing.\n\n\nBsp.\nRFID\nHaussensoren\nmobile Elektronik\nInformation services (ohloh.net/ mechnical turk..\ntheNextBI ?\n\n Also known as „on demand business“\n Real time business (intelligence) is the process of delivering information about business operations without any latency. In this context, real time means delivering information in a range from milliseconds to a few seconds after the business event. \n
  • \n
  • \n
  • \n
  • BAM\nKPI\nReal Time Business\nProzessmonitoring in der Geschäftsprozessebene\n\nRules\nKonfiguratives Regelrepository\nInnerhalb der Prozessschicht der Architektur\n\nCEP\nAnwendungsnahe Ereignisverarbeitung\n
  • \n
  • Oracle:\n\nDatenströme (Streams)\n. kontinuierlich, hochvolumig\n. in zeitlicher Reihung\n. endlos\n. können mit klassischen,\nrelationalen Datenbanksystemen\nnicht analysiert /\nverarbeitet werden\n\nCEP -Die neue Datenmanagement-\nInfrastruktur zur\nDatenstromanalyse in Echtzeit!\n
  • \n
  • Filterung des Datenstroms nach bestimmten\nKriterien, z.B. Kurs > 20¼\n.Rolierende, zeitbasierende Fenstermetriken,\nz.B. durchschnittliches Handelsvolumen der\nletzten Stunde, alle 5 Sekunden\n.Benachrichtigung bei Erkennung von Mustern,\nz.B. Preisänderung X, Y, und Z innerhalb von 9\nMinuten aufgetreten\n
  • Recherche Wikipedia \nvent-driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.\nThis architectural pattern may be applied by the design and implementation of applications and systems which transmit events among loosely coupled software components and services. An event-driven system typically consists of event consumers and event producers. Event consumers subscribe to an intermediary event manager, and event producers publish to this manager. When the event manager receives an event from a producer, the manager forwards the event to the consumer. If the consumer is unavailable, the manager can store the event and try to forward it later. This method of event transmission is referred to in message-based systems as "store and forward" [2]. Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates more responsiveness, because event-driven systems are, by design, more normalized to unpredictable and asynchronous environments[2].\n\nEine ereignisgesteuerte Architektur (von engl. event-driven architecture, EDA) ist eine Softwarearchitektur, in der das Zusammenspiel der Komponenten durch Ereignisse (events) gesteuert wird. Ereignisse können sowohl von außen kommen (z. B. Benutzereingaben) als auch vom System selbst ausgelöst werden (z. B. Änderungsbenachrichtigungen). Sie stoßen eine Ereignisbehandlung (event handling) an, mit der das System auf die erfolgte Eingabe reagiert. Eine ereignisgesteuerte Architektur hat kaum Kontrolle darüber, wann Daten verarbeitet werden. Klassisches Anwendungsszenario ist die grafische Benutzeroberfläche: Hier bestimmt der Benutzer, wann welche Daten verarbeitet werden, indem er Aktionen ausführt und damit Ereignisse auslöst. Ereignisorientierte Simulationen sind ereignisgesteuerte Teilbereiche größerer Softwarearchitekturen.\n\nEin Ereignis umfasst mindestens drei Angaben: Den Erstellungszeitpunkt (Zeitstempel), die auslösende Komponente (Quelle) und die Art des Ereignisses (Typ), die angibt, was im Wesentlichen vorgefallen ist.\n
  • \n Esper solves a complex set of problems that current SOAs do not solve: how to make meanings of all events flowing through your system at the speed of your business? How to preserve flexibility? How to handle massively growing data volumes?\n\nBSP.\nNerven, fünf Sinne , Hirn - EDA des Menschen\n„Wenn heiß an der Hand in der Küche dann Hand wegziehen“\n? Mengendiagramm \n
  • \n Esper solves a complex set of problems that current SOAs do not solve: how to make meanings of all events flowing through your system at the speed of your business? How to preserve flexibility? How to handle massively growing data volumes?\n\nBSP.\nNerven, fünf Sinne , Hirn - EDA des Menschen\n„Wenn heiß an der Hand in der Küche dann Hand wegziehen“\n? Mengendiagramm \n
  • Event ist ein Indikation\nwas passiert\nwann passiert es\n--> erlaubt eine Reaktion\ntypischer weise aus der Beobachtung eines Zustands resultierend\n
  • Beispiel RFID\nRadio Frequency Identification\n Bewegungsprofile von identifizierten(indizierten) Gegenständen\n ID des Gegenstandes\n x-Koordinate\n y-Koordinate\n Zone -aus (x,y) abgeleiteter Wert zur relativen Positionierung\n\nAnwendungsbeispiele\n Monitoring von Produktions/Fertigungsprozessen\n Eigentumsüberwachung\n Verhaltens/marktforschung\nradie ID wird einem Gegenstand zur Identifikation mitgegeben\num seine Bewegungen im Raum zu detektieren\nz.B. in Geschäft, Lagerhaus, Produktionshale werden Sensoren angebracht\nder Sensor ermittelt die ID und den Sensor daraus kann ein Aufenthaltsbereich ermittelt werden\nJe mehr Sensoren je besser kann ein Strom vo n Events über einen Zeitraum ein Bild der Bewegungen der Gegenstände im Raum erzeugen\nUse Case:\nÜberwachung einer Gruppe von immer drei Elementen die im gleichen Bereich sein sollten\nansonstern --> Fehler (Dibstahl oder Havarie ?)\n
  • \n
  • \n
  • \n
  • TODO Grafik\n2 Bereiche in der Forschung der letzten 10 Jahre\nESP Ableitung von Infornation aus Ereignisströmen über Zeiträume durch Analyse und Aggregation\n\nEvent Stream Processing, or ESP, is a set of technologies designed to assist the construction of event-driven information systems. ESP technologies include event visualization, event databases, event-driven middleware, and event processing languages, or complex event processing (CEP). ESP deals with the task of processing multiple streams of event data with the goal of identifying the meaningful events within those streams, employing techniques such as detection of complex patterns of many events, event correlation and abstraction, event hierarchies, and relationships between events such as causality, membership, and timing, and event-driven processes.\n\n\ngeklautes Beispiel\nMittelere Google Preis wir können Handlesentscheidungen darauf basieren\n
  • \n
  • \n
  • \n
  • \n
  • Definition dort\nman nehme EDA und verbinde dies mit Real Time Business Requirements --> Ergebnis XTP\nHauptpunkte:\nGroße Menge an Events gehen ins System\nZiel ist nicht alle diese Events zu publizieren\nstatdessen aggregieren um dem Input eine Bedeutung zu geben/ detektion von complexen Eventmustern\nz.B. zeitverläufe von Druchschnitten berechnen o.ä.\nViel Größerer Input-Stream als der Output-Stream ungefähr 2% werden typischerweise korreliert\n
  • Gartner http://mediaproducts.gartner.com/reprints/azulsystems/146107.html\nMainstream organizations should primarily look at combinations of established platform\nmiddleware and incremental XTP-enabling technologies to address their emerging\ntransaction processing challenges while minimizing technology risks.\n\n\nThe combined effect of 14 major trends will disrupt the apparently static application server and transaction processing markets. Platform middleware users and vendors will be impacted and must delineate proper survival strategies.\n
  • TODO Grafik\n2 Bereiche in der Forschung der letzten 10 Jahre\n\nCEP Wikipedia\ndeals with the task of processing multiple events from an event cloud with the goal of identifying the meaningful events within the event cloud. CEP employs techniques such as detection of complex patterns of many events, event correlation and abstraction, event hierarchies, and relationships between events such as causality, membership, and timing, and event-driven processes.\n\ngeklautes Beispiel\nMittelere Google Preis wir können Handlesentscheidungen darauf basieren\n\nEven though there is no direct measurement that can determine conclusively that the driver was thrown, or that there was an accident, the combination of events allows the situation to be detected and a new event to be created to signify the detected situation. This is the essence of a complex (or composite) event. It is complex because one can not directly detect the situation; one has to infer or deduce that the situation has occurred from a combination of other events.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Esper is a component for CEP and ESP applications, available for Java as Esper, and for .NET as NEsper.\n\nEsper and NEsper enable rapid development of applications that process large volumes of incoming messages or events. Esper and NEsper filter and analyze events in various ways, and respond to conditions of interest in real-time.\n
  • Esper leverages Java 5 enhancements done in the area of concurrency. It also fully supports 32bit and 64bit architectures.\n\nVergleich ESB\n 2600 msg/s auf 4facher HW bei einfachem Pipelining\n 1 Gb network ~ 65 536msg/s (2Ko/msg) ?\n\n\nESP/CEP applications are somewhat complex to benchmark, because the performance figures are highly dependant on the complexity of the situations to detect among the event stream(s) possibly joined together or involved in a causality relationship. There is no industry benchmark available yet that would allow for apple-to-apple comparison. You'll often see some products claim 100 000 events/s, or 500 000 events/s without any information regarding the scenario, the size of each event, the hardware used, the network link etc.\n\nIf performance is a key requirement for you, let us know and we'll show you how we scale. We won't argue with paperwork.\n
  • Absolut andere Bearbeitung als eine DB\nin Esper wird ein Query Statement regisitriert und der Datenfluß wir ddurch dieses geleitet\n\n3 Schlüsselelemente\n\nEngine werden die Statements übergeben\nStatements beschreiben wie wir Ereignisse detektieren/wahrnehmen bzw. konsumieren\nListener können dan an Statements angehängt werden, welche von der Engine immer dann aufgerufen werden wenn eine Statement getroffen oder sein ResultSet verändert wird\nDer Listener erhält dann ein geändertes ResultSet\nStarkes Paradigma\n
  • \n
  • Absolut andere Bearbeitung als eine DB\nin Esper wird ein Query Statement regisitriert und der Datenfluß wir ddurch dieses geleitet\n\n3 Schlüsselelemente\n\nEngine werden die Statements übergeben\nStatements beschreiben wie wir Ereignisse detektieren/wahrnehmen bzw. konsumieren\nListener können dan an Statements angehängt werden, welche von der Engine immer dann aufgerufen werden wenn eine Statement getroffen oder sein ResultSet verändert wird\nDer Listener erhält dann ein geändertes ResultSet\nStarkes Paradigma\n
  • \n
  • \n
  • \n
  • TODO Quellcode 17\n\nEvents können kontinuierlich von einem oder mehreren Threads gleichzeitig in die Engine Instanz gesandt werden\n\n verschiedene Eventrepräsentationen\nPOJO/XML/Maps\n\nEsper erlaubt mit EPL sehr machtvolle Interaktionen(detect/consume) mit solchen Events \nsiehe folgende Folien\n \n
  • TODO Quellcode 17\n\nEvents können kontinuierlich von einem oder mehreren Threads gleichzeitig in die Engine Instanz gesandt werden\n\n verschiedene Eventrepräsentationen\nPOJO/XML/Maps\n\nEsper erlaubt mit EPL sehr machtvolle Interaktionen(detect/consume) mit solchen Events \nsiehe folgende Folien\n \n
  • TODO Quellcode 17\n\nEvents können kontinuierlich von einem oder mehreren Threads gleichzeitig in die Engine Instanz gesandt werden\n\n verschiedene Eventrepräsentationen\nPOJO/XML/Maps\n\nEsper erlaubt mit EPL sehr machtvolle Interaktionen(detect/consume) mit solchen Events \nsiehe folgende Folien\n \n
  • TODO Quellcode 17\n\nEvents können kontinuierlich von einem oder mehreren Threads gleichzeitig in die Engine Instanz gesandt werden\n\n verschiedene Eventrepräsentationen\nPOJO/XML/Maps\n\nEsper erlaubt mit EPL sehr machtvolle Interaktionen(detect/consume) mit solchen Events \nsiehe folgende Folien\n \n
  • TODO Quellcode 17\n\nEvents können kontinuierlich von einem oder mehreren Threads gleichzeitig in die Engine Instanz gesandt werden\n\n verschiedene Eventrepräsentationen\nPOJO/XML/Maps\n\nEsper erlaubt mit EPL sehr machtvolle Interaktionen(detect/consume) mit solchen Events \nsiehe folgende Folien\n \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript

    • 1. EDA und Complex Event Processingmit Esper
    • 2. Papick Garcia Taboada
    • 3. Papick Garcia Taboada
    • 4. developer?
    • 5. Papick Garcia Taboada hacker
    • 6. Papick Garcia Taboada dipl. hacker
    • 7. more magic developer?
    • 8. Papick Garcia Taboadatechnology scout
    • 9. Social Media
    • 10. pgt technology scouting GmbH http://pgt.de
    • 11. http://blog.oio.de
    • 12. Integrationsszenarien mit ereignisgesteuertenArchitekturansätzen in Java umsetzen?Event-driven Architecture (EDA) wird heuteals komplementärer Ansatz zu SOAwahrgenommen.Unter EDA versteht man allerdings mehr als nurEntkopplung mittels "Single Event Processing": DieVerarbeitung von Ereignisströmen und dieKorrelation von Ereignissen gehören auch zudiesem Themenkomplex.Esper ist ein leichtgewichtiges Open-Source-Tool,das die Verarbeitung von Ereignisströmen erlaubt.
    • 13. Integrationsszenarien mit ereignisgesteuertenArchitekturansätzen in Java umsetzen?Event-driven Architecture (EDA) wird heuteals komplementärer Ansatz zu SOAwahrgenommen.Unter EDA versteht man allerdings mehr als nurEntkopplung mittels "Single Event Processing": DieVerarbeitung von Ereignisströmen und dieKorrelation von Ereignissen gehören auch zudiesem Themenkomplex.Esper ist ein leichtgewichtiges Open-Source-Tool,das die Verarbeitung von Ereignisströmen erlaubt.
    • 14. Architektur?
    • 15. Integrationsprojekte als historischer Hintergrund für SOA und EDA
    • 16. Historisches Umfeld-Probleme bei der Integration von Systemen -Netzwerke sind nicht zuverlässig -Netzwerke sind langsam -Systeme sind grundsätzlich verschieden -Änderungen sind unvermeidbar
    • 17. LösungsansätzeDateiübertragungGemeinsame DatenbankEntfernte MethodenaufrufeRemote Procedure Calls...Nachrichtendienste http://www.enterpriseintegrationpatterns.com/toc.html
    • 18. LösungsansätzeDateiübertragungGemeinsame DatenbankEntfernte MethodenaufrufeRemote Procedure Calls... SOANachrichtendienste EDA
    • 19. http://geekandpoke.typepad.com/geekandpoke/2009/12/from-hype-to-hype.html
    • 20. http://geekandpoke.typepad.com/geekandpoke/2009/12/from-hype-to-hype.html
    • 21. http://geekandpoke.typepad.com/geekandpoke/2009/12/from-hype-to-hype.html
    • 22. http://geekandpoke.typepad.com/geekandpoke/2009/12/from-hype-to-hype.html
    • 23. EDA vs. SOA nein. EDA und SOA
    • 24. http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html
    • 25. http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html
    • 26. Ereignisströme? Korrelation? Muster?
    • 27. Business case?real time business anyone?
    • 28. IBM ad,Heatrow Airport, 2008...
    • 29. Real Time BusinessUnter "Real Time Business" versteht man diezeitnahe Auslieferung und Evaluierung vonwirtschaftlichen Ereignissen All real time business intelligence systems have some latency, but the goal is to minimize the time from the business event happening to a corrective action or notification being initiated
    • 30. Zeitnah? -Informationslatenz -Analyselatenz -Aktionslatenz
    • 31. Realtime Business- Wirtschaftliche Potentiale entdecken - Marktbedürfnisse münden in Nachfragen - Früherkennung schafft Wettbewerbsvorteile- unterstützende Trends - zunehmende Verfügbarkeit elektronischer Daten - elektronische Bereitstellung von Detailinformationen - feinkörnige Daten - häufige Updates - zeitnaher Zugriff Reaktionsschnittstellen möglich
    • 32. Business case?business inteligence anyone?
    • 33. Business Inteligence - traditional business intelligence presents historical information to users for analysis - real time business intelligence compares current business events with historical patterns to detect problems or opportunities automatically - enables corrective actions to be initiated and or business rules to be adjusted to optimize business processes
    • 34. Real Time Business PerformanceRequirements - Sehr hohe Anforderungen - Extrem hohe Anzahl an Events (>> 100.000) - OLTP Architekturen können nicht so viele Ereignisse verarbeiten -„High transactions per second“ - 1,000 - 10,000 TPS: eBay, Amazon -„Medium transactions per second“ - 100 - 1,000 TPS: International web application -„Low transactions per second“ - 10 - 100 TPS: Small internal OLTP
    • 35. Abgrenzung-BAM - Deklarativ, 5s Reaktionszeitfenster - 1000 Events/s-Rules - Reichhaltige Konfiguration - 10000-100000 Events/s-CEP - InMemory, Low Latency, „Real Time“ - >100000 Events/s
    • 36. Business case?aber wer, wo, warum?
    • 37. EDA Anwendungsgebiete- Transport & Logistik - gezielte Transportsteuerung- Telekommunikation - Transaktionsverarbeitung- Produktion - Produktionsüberwachung- Finanzdienstleistungen - algorithmischer Aktienhandel- Versicherungen - Risikoerkennung
    • 38. Einsatzszenarien - Business/ System Monitoring - Ausführliche Fallstudie bei Esper zu Terminalüberwachung - Überwachung von Informationen aus Trackingdevices - Echtzeitauswertung von Finanzdaten - Intelligente Steuerungssysteme - Automobil - Haussteuerung/ Hausautomatisierung
    • 39. Adoptionsstatus in der Industrie -Eher exotische Business Cases? -Militär -Casinos -Spekulative Finanzinstrumente -Moralisch bedenklich
    • 40. Event Driven Architecture- Grundprinzipien: - sehr lose Kopplung - basiert vollständig auf Nachrichten - abstrahierter Nachrichtentransport - Unabhängigkeit der Eventbearbeitung von Ort und Weg zwischen den beteiligten Komponenten
    • 41. EDA Paradigma-EDA konzentriert sich auf Anwendungen nach folgendem Muster 1.Events müssen zeitgerecht in Ihrem Eingang erkannt 2.konsumiert 3.und anschließend folgerichtig darauf reagiert werden
    • 42. EDA Paradigma-Event getriebene Anwendungen lassen sich in natürlicher Sprache regelartig komprimieren - „wenn .. dann...“ -When-clause -Handler code
    • 43. Events- Beobachtung einer Zustandsänderung - Quittierung einer Autorisierungsprüfung - Antwortzeit der letzten Anfrage - Messwert eines Sensors im Haus - Aktienpreisänderung- benötigen eine technische Repräsentation - Schlüssel/Wert- Paare - XML - POJO
    • 44. Event Beispiele im EngineeringKFZ-sensoren:Ermittlung von Betriebsgrößen durch verschiedene häufigüber ein Bussystem verbundender Sensoren - Drehgeschwindigkeit des Rades - Beschleunigung in allen drei Raumachsen - Luftdruck der Reifen - Aussenlufttemperatur - Luftfeuchtigkeit Anwendungsbeispiele: ABS, - Sitzbelastung Einspritzsysteme, Airbagabschaltung, Verhaltensforschung? - Lambda-Wert
    • 45. Eventverarbeitung bei EDA-SEP: Simple Event Processing-ESP: Stream Event Processing-CEP: Complex Event Processing
    • 46. Simple Event Processing-Ein Ereignis kann als wichtige Zustandsänderung in einer Nachrichtenquelle angesehen werden.-Diese Ereignisse lösen durch ihr Auftreten Prozesse in den Systemen aus, die die Nachricht empfangen werden.-Das ist Verarbeiten von Nachrichten, wie es in der „Java Messaging Service“ Spezifikation beschrieben ist. 19
    • 47. Event Stream Processing-Unter „Event Stream Processing“ versteht man die flussartige Bearbeitung der eingehenden Nachrichten.-Bei der Abarbeitung der Nachrichten ist nicht jede einzelne Nachricht ausschlaggebend, sondern der Fluss als solches. So wird zum Beispiel erst reagiert, wenn ein Temperatursensor für einen bestimmten Zeitraum durchgehend eine bestimmte Temperatur über- oder unterschritten hat.
    • 48. ESP- Überwachung von Eventstromdaten - Analyse der Events - Reaktion bei bestimmten Gegebenheiten - z.B. Kfz-ABS: - Wenn Drehgeschwindigkeit des Rades beim Auto null während Fahrzeugbeschleunigung negativ dann öffne Bremsdruckventil- Grund-Folge -Modellierung nutzt als Grund ein „When “-clause - wird auch als ESP/ CEP-Statement bezeichnet
    • 49. Complex EventWhat is a complex event?„It is an event that could only happenif lots of other events happend.“ „The Power of Events“ An introduction to complex event processing in distributed enterprise systems by David Luckham
    • 50. CEP simply explained http://soa-eda.blogspot.com/2008/04/cep-simply-explained.html
    • 51. Complex Event ProcessingUnter CEP versteht man die Erkennung vonkomplexen Mustern innerhalb eines oder sogarzwischen verschiedenen Ereignisströmen.So haben eventuell Ereignisse wenig Relevanz imeinzelnen, sind aber in bestimmten ZusammenhängenIndiz eines besonderen Ereignisses.
    • 52. Complex Event ProcessingEreignisse können in -kausaler, -temporaler oder -räumlicherKorrelation auftreten.Die einzelnen Ereignisströme können ein sehrhohes Aufkommen von Ereignissen aufweisen.
    • 53. EDA Infrastruktur-EXtreme Transaction Processing (XTP) -Begriff wurde 2003 durch Gartner erstmals genannt -> 100 000 Events/s -Korrelationsrate < 2% -Kombination von Events mit langlebigen Historiendaten-Event Repositories und Ontologien
    • 54. EDAS Zukunft ? „By 2011, a new generation of application platforms stemming from the convergence of diverse XTP-enabling technologies will supersede Java EE and .NET as the platforms of choice for large- scale, business-critical applications (0.8 probability).“ „By 2010, support for advanced, event-centric programming models will be a standard feature in all application platforms aimed at XTP applications (0.8 probability).“Quelle: Gartner RAS Core Research Note G00146107 Q1/2007
    • 55. automated emergency call wenn Fahrersitzbelastungsän derung auf null innerhalb 200ms mit negativer Beschleunigung > a und Reifendruckabfall dann automatische Anwahl Notrufzentrale
    • 56. Wie?
    • 57. EDA with Java-SEP -Java Messaging Service -Enterprise Service Bus-ESP & CEP -No standard -Only products
    • 58. Java Messaging Service -Well known technology in the Java EE stack -Security, transaction -Many implementations... -JMS specific terms and definitions -Two event processing models -Point-To-Point -Publish-and-Subscribe
    • 59. Point-To-Point
    • 60. Publish-and-Subscribe
    • 61. ESB – Enterprise Service Bus http://servicemix.apache.org/home.html
    • 62. ESP, CEP?
    • 63. Esper- Esper ist ein Softwarebaustein für CEP und ESP Anwendungen, der in Java als Esper und .NET als Nesper bereitgestellt wird.- Esper erlaubt die zeitnahe Entwicklung von Anwendungen mit hohem Aufkommen eingehender Ereignisse bzw. Nachrichten. Dabei können Ereignisse auf verschiedene Arten in Echtzeit analysiert, gefiltert und konsumiert werden. - Esper Homepage: http://esper.codehaus.org - Lizenz: dual licensing, GPL + commercial license through Espertech - Umfangreiche Dokumentation - Viele Beispiele - Abfragemuster auf der Homepage
    • 64. Performance Aspekte-Esper Benchmark -RFID tracking sample -1000 gruppen zu drei Elementen , 20 Zonen -2000 registrierte Statements -~ 110 000 Events/s
    • 65. Big picture © EsperTech
    • 66. Processing Model-Kontinuierliche Bearbeitung-Listener werden benachrichtigt, wenn sich die Ereignismenge verändert-Datenbank „inside-out“ -Nicht Anfragen gegen die Daten ausführen sondern Daten durch die Anfragen schicken.
    • 67. API Overview- EPServiceProvider - Engine Prozessierungseinheit - Threads, Zeit, Streams werden hier verwaltet- EPStatement - Statements / Queries - in EQL (Event Query Language)- UpdateListener - Listener - POJI
    • 68. Events-Sehr flexibler Ansatz-Esper verschickt EventBeans-EventBeans können -POJOs -Java.util.Map -org.w3c.dom.Nodeenthalten.
    • 69. EQL Kurz & Gut-Analogie zu SQL - Ereignisströme sind Tabellen - Ein Ereignis entspring ein Datensatz - Eigenschaften im Ereignis entsprechen Datenfelder-EQL Queries lassen sich grob in - ESP Queries und - CEP Queries einteilen.
    • 70. Esper 1x1
    • 71. EPServiceProvider engine = EPServiceProviderManager.getDefaultProvider();
    • 72. EPServiceProvider engine = EPServiceProviderManager.getDefaultProvider();EPStatement stmt = engine.getEPAdministrator().createEQL(stmtText);
    • 73. EPServiceProvider engine = EPServiceProviderManager.getDefaultProvider();EPStatement stmt = engine.getEPAdministrator().createEQL(stmtText);stmt.addListener(new MyListener());
    • 74. EPServiceProvider engine = EPServiceProviderManager.getDefaultProvider();EPStatement stmt = engine.getEPAdministrator().createEQL(stmtText);stmt.addListener(new MyListener()); while(true) { FeedEvent event; event = new FeedEvent(FeedEnum.FEED_A, "IBM", 70); engine.getEPRuntime().sendEvent(event); event = new FeedEvent(FeedEnum.FEED_B, "IBM", 70); engine.getEPRuntime().sendEvent(event); }
    • 75. String stmtText = "insert into ThroughputPerFeed " + "select feed, count(*) as cnt " + "from " + FeedEvent.class.getName() + ".win:time_batch(1 sec) " + "group by feed";
    • 76. ESP Queries-Abfragen über: -Einzelne Ereignisse -Ereignisse in einem Zeitfenster -Ereignisse in einem Mengen-Fenster
    • 77. select * from Withdrawal
    • 78. select * from Withdrawal.win:length(5)
    • 79. select * fromWithdrawal(amount>=200).win:length(5)
    • 80. CEP Queries-Abfragen über -Muster zwischen Ereignisse/ Ergenissstöme -Verwendeter Begriff: „PATTERN“
    • 81. Event Pattern Überblick- Patterns werden über den Konstrukt „pattern […]“ definiert - Wiederholungsangabe mit „every“ - Logische Operatoren - and, or, not - Zeitliche Operatoren - „->“ (followed-by) - Guards are where-conditions that control the lifecycle of subexpressions. - timer:within - Observers observe time events as well as other events. - timer:interval - timer:at
    • 82. pattern [ every A -> B ]
    • 83. pattern [ every (A -> B) ]
    • 84. pattern [ A every -> B ]
    • 85. pattern [ every A -> every B ]
    • 86. Guards und Observer- ( A or B ) where timer:within (5 sec) - Ein A oder B in den nächsten 5 Sekunden- (every A) where timer:within( 10 sec ) - Alle A Ereignisse in den nächsten 10 Sekunden- A -> timer:interval(10 seconds) - Nach A 10 Sekunden warten- every timer:at(5, *, *, *, *) - Alle 5 Minuten
    • 87. Zeit für eine kleine Demo?
    • 88. Fragen?
    • 89. Danke!