1 / 35

AMIT- active middleware technology

Seminar zum Thema „Aktive Datenbanken“ des Lehrstuhls Praktische Informatik der Friedrich-Schiller-Universität Jena. AMIT- active middleware technology. Gliederung. 1. Einleitung 2. Ziele 3. Eigenschaften 4. Architektur 5. Situationskonzept 6. AMIT in der Praxis 7. Literatur

sally
Download Presentation

AMIT- active middleware technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Seminar zum Thema „Aktive Datenbanken“ des Lehrstuhls Praktische Informatik der Friedrich-Schiller-Universität Jena (c) Julia Hillebrandt

  2. AMIT- active middleware technology

  3. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  4. Einleitung • Kundenwunsch als Motivation • Projekt of IBM Forschungslabor Labor Haifa 1999 • Aufgabe AMIT: aus einzelne Events eine Situation erfassen • überbrücken mit einem „Situationsmanagers“ (c) Julia Hillebrandt

  5. Einleitung Runtime- AMIT (c) Julia Hillebrandt

  6. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  7. Ziele • reactive systems: • auf etwas reagieren, was im System stattfindet • proactive systems: • prognostizieren von Umweltveränderungen • überbrücken Differenz vom Event zur Situation • Anwendungsentwicklungswerkzeug passt sich an die damals schnelle Entwicklung von aktiven Datenbanken an • benutzerdefinierte Situationen erkennen • unterschiedliche Inhalte unterstützen • es kann mehr als ein Kontext nötig sein, um eine spezifische Situation zu erkennen (c) Julia Hillebrandt

  8. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  9. Eigenschaften • externe Quellen  Events erfassen • verarbeiten externer Metadaten • modellieren aller Unternehmensaktivitäten und Komponenten • Überwachung aller Events • Plattform unabhängig • Unterstützung lokal- basierte Entscheidungsunterstützungssysteme (c) Julia Hillebrandt

  10. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  11. Architektur (c) Julia Hillebrandt

  12. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  13. Situationskonzept (c) Julia Hillebrandt

  14. Beispiele für mögliche Situationen • Ein Chef möchte eine Meldung bekommen, wenn ein Mitarbeiter eine bestimmte Anzahl an Verträgen innerhalb von 2 Tagen abgeschlossen hat • (Vorschlag für Gehaltserhöhung ) (c) Julia Hillebrandt

  15. e2 e1 e3 Situationskonzept-Event Events • signifikanter, augenblicklicher und atomarer Vorfall • löst eine Aktion und damit meistens eine Zustandsveränderung aus • concrete und inferred events • concrete passieren in der Realität Zustandsänderung • inferred events • logische Folgerungen (c) Julia Hillebrandt

  16. e2 e1 e3 Situationskonzept-Event Events • 2 Eventklassen • external Events • konkrete Events  kommen in den Situationsmanager • von externen Quellen während der Laufzeit • internal events • inferred events welche signalisiert  Situation entdeckt • Event Event instance • Infos über Event • event class attribute und methods • class name, a set of a attributes

  17. e2 e1 e3 Attributes Situationskonzept-Attribute • Event ist eine strukturierte Menge von Attributen • Attributname, attribute type und default type Events Beispiel: <event name=“Abschluss“> <attribute name=“Name“ type=“string“> <attribute name=“Anzahl “ type=“number“> <attribute name=“Differenz “ type=“number“> </event> (c) Julia Hillebrandt

  18. e2 e1 e3 Attributes Repeat Mode (always, once) (immediate, delayed, deferred) Detection Mode Context e5 e8 Terminator Initiator Situationskonzept-Lifespan • Lifespan • während der Situationserkennung relevant • begrenzt zwischen zwei Ereignissen den • Initiator und den Terminator • Initiator und den Terminator können externe, interne oder Systemereignisse sein • lifespan class beinhaltet Eigenschaften • Anzahl/Bedingung, welche einen Lifespan initiieren/beenden • maximale Länge Events

  19. Initiator e5 Situationskonzept-Lifespan-Initiator • lifespan  durch einen Initiator • Aufkommen eines Events oder starten Situationsmanager • beinhaltet durch was initiiert und unter • welchen Bedingungen • Bedingung,Event Name,Correlation code • Correlation code 2 Möglichkeiten • add und ignore • ignore = neuer lifespan initiiert, nur wenn ein lifespan selben Types nicht schon offen ist • add= ein neuer lifespan während alle anderen lifespans ebenfalls offen <lifespan name = „Anzahl“> <initiator name= „Berechnen“ Condition=“Mitarbeiterabschluß>30“ Correlate = “add“/> </lifespan> (c) Julia Hillebrandt

  20. Terminator e8 Situationskonzept-Lifespan- Terminator • lifespan Terminator • lifespan beendet durch Terminator • lifespan Type definiert nach einer Zeitperiode oder auftreten eines Ereignisses • beinhaltet die Bedingungen  bevor Laufzeit beendet • 3 Bedingungen first, last, each • first  älteste lifespan beendet • last  neueste lifespan beendet • each  alle beendet (c) Julia Hillebrandt

  21. e2 e1 e3 Attributes Repeat Mode (always, once) (immediate, delayed, deferred) Detection Mode Context e5 e8 Terminator Initiator Situationskonzept-Modi Events

  22. Situationskonzept-Modi • detection mode • Immediate • Situationserkennung wenn neues Event • berichtet wenn entdeckt wird • Delayed • Situationserkennung wenn neues Event • Ende der Laufzeit berichtet • Deferred • Situationserkennung am Ende der Laufzeit • berichtet wenn entdeckt wird • Repeat mode • Always • wiederholt • Once • einmal beachtet (c) Julia Hillebrandt

  23. JOINING (all, sequence) e2 COUNTING (atleast, atmost, nth) Operators Events e1 TEMPORAL (every, after, at) (not, unless) ABSENCE e3 Attributes Repeat Mode (always, once) (immediate, delayed, deferred) Detection Mode Context e5 e8 Terminator Initiator Situationskonzept-Operators

  24. Situationskonzept-Operators • Joining Operators: • All  Verknüpfung von Events ohne Anordnung • Sequences  Verknüpfung von Events Anordnung • Counting operatorsVerknüpfung von n gewichteten Events triggered wenn gesamte Gewicht Operator keine Anordnung • Atleast  Anzahl muss größer einer vom Benutzer definierten Größe sein • Atmost Anzahl muss kleiner  einer vom Benutzer definierten Größe sein • nth Anzahl muss gleich  einer vom Benutzer definierten Größe sein • Absence operator • Not keins der Ereignisse mit der Laufzeit auftritt • Unless  nur Ereignis beim 1. Operator nicht 2. (c) Julia Hillebrandt

  25. Situationskonzept-Operators- Beispiel operator = "atleast 10" detection mode = "immediate" first operand = event: “Abschluss" threshold: “differenz <0” weight: “1” quantifier: "each" second operand = event: “Abschluss" threshold: “differenz >0” weight: “-1” quantifier: "each" (c) Julia Hillebrandt

  26. JOINING (all, sequence) e2 COUNTING (atleast, atmost, nth) Operators Events e1 TEMPORAL (every, after, at) (not, unless) ABSENCE e3 Attributes Conditions (where...) e1.id Key e2.name e3.key Repeat Mode (always, once) (immediate, delayed, deferred) Detection Mode Context e5 e8 Terminator Initiator Situationskonzept-Conditons und key

  27. Situationskonzept-Conditons und key • Condition • kontrolliert, ob die Condition durch den Operator angewandt, sowie „where“ Klausel erfüllt wurde • key definition • semantische Übereinstimmung bei verschiedenen Events aufgrund gleicher Attributwerte • Vgl. equi join in relationale DBs (c) Julia Hillebrandt

  28. JOINING (all, sequence) e2 COUNTING (atleast, atmost, nth) Operators Events e1 TEMPORAL (every, after, at) (not, unless) ABSENCE e3 Attributes Conditions (where...) e1.id Key e2.name e3.key Situation Repeat Mode (always, once) (immediate, delayed, deferred) Detection Mode Context e5 e8 Terminator Initiator Situationskonzept !!! !!!

  29. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  30. AMIT Werkzeuge (c) Julia Hillebrandt

  31. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  32. Literatur • http://www.cse.ust.hk/db/index_files/dbseminar/archives/fall04/amit_vldbj04.pdf • http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-60/adi.pdf • http://cep.weblogger.com/stories/storyReader$157 • http://www.haifa.il.ibm.com/dept/services/soms_ebs_tech.html • http://www.computerwoche.de/bizone/579005/ (c) Julia Hillebrandt

  33. Gliederung • 1. Einleitung • 2. Ziele • 3. Eigenschaften • 4. Architektur • 5. Situationskonzept • 6. AMIT in der Praxis • 7. Literatur • 8. Ausblick (c) Julia Hillebrandt

  34. Ausblick • basierend auf AMIT  Complex Event Processing Technolgy (CEP) • überwacht Business Prozesse • Ziel ist eine Art Radarsystem  schneller auf Veränderungen reagieren  Ereignismuster unmittelbar erkennen und Reaktionen anstoßen • bessere Ergebnisse in Echtzeit • Neuerung: erkennen von komplexen Situation  verschiedene Eventquellen mit unterschiedlichen Zusammenhängen (c) Julia Hillebrandt

  35. Ausblick • Funktionsweise: • kleine Programme, die kontinuierlich Anfragen gegen Daten aus Ereignisströmen fahren • nutzen Regeln, um Ereignisse zu filtern, zu korrelieren und zu komplexeren Ereignissen (Complex Events) zu aggregieren • Events mit vorher definierten Mustern  identifizieren Ereigniskonstellationen  die vorgegebene Restriktionen verletzen (c) Julia Hillebrandt

More Related