A Platform for Complex Event Processing (Wintersemester 2013/2014)

Dozent: Prof. Dr. Mathias Weske (Business Process Technology)

Allgemeine Information

• Semesterwochenstunden: 4
• ECTS: 6
• Benotet: Ja
• Einschreibefrist: 1.10.2013 - 31.10.2013
• Lehrform: Seminar
• Belegungsart: Wahlpflichtmodul
• Maximale Teilnehmerzahl: 12

Studiengänge, Modulgruppen & Module

Beschreibung

Die Informationen und Folien aus der Einführungsveranstaltung zu diesem Seminar sind hier zu finden.

---

In Unternehmen werden tagtäglich vielfältige, wertschöpfende Aufgaben, beschrieben in Geschäftsprozessen, bearbeitet. Bei der Ausführung dieser Prozesse treten Ereignisse auf, welche den Bearbeitungsfortschritt aufzeigen.

Momentan werden diese oftmals nicht von IT-Systemen erfasst. Selbst in Anwendungssystemen gespeicherte Ereignisse, sog. Events, lassen sich meist nicht sinnvoll nutzen, da der Zusammenhang der einzelnen Events untereinander und zum Geschäftsprozess fehlt.

Um diese Eventinformationen bspw. für Prozess-Monitoring und -Analyse nutzbar zu machen, wurden im Fachgebiet Business Process Technology Methoden und Techniken erforscht, die in der Entwicklung einer Event Processing Plattform mündeten. Diese Plattform kann aus verschiedenen Quellen Events entgegennehmen, diese normalisieren und in Prozesskontext setzen. Darauf aufbauend können die Events bspw. durch Transformation und Aggregation weiterverarbeitet und entsprechend zur Verfügung gestellt werden.

Diese Plattform soll im Zuge des Bachelorseminars weiterentwickelt und erweitert werden. Dafür haben wir vier Schwerpunkte identifiziert, die jeweils durch zwei bis drei Studenten bearbeitet werden sollen.

1. Refactoring der Architektur
   Aktuell ist die Anwendungslogik der Plattform mit der Benutzeroberfläche (umgesetzt mit dem Framework Wicket) eng verknüpft, was den Einsatz und die Weiterentwicklung der Plattform erschwert. Getreu dem Konzept "Separation of Duties", sollen Anwendungslogik von der Benutzeroberfläche getrennt werden, damit sie von alternativen Frontends oder auch als Web Service angesprochen werden kann. Dazu müssen Abhängigkeiten identifiziert und durch neue Schnittstellen aufgelöst werden, was eine gründliche Analyse der bestehenden Codebasis erfordert. Darauf basierend, soll die Architektur derart verändert werden, dass die Anwendungslogik unabhängig von der Benutzeroberfläche funktioniert.
   Bestandteil der Aufgabe ist sowohl die Konzeption, als auch die Umsetzung der Architekturänderungen.
   
   
2. Etablierung eines Berechtigungskonzepts
   Um die Plattform produktiv einsetzen zu können, ist es nötig verschiedene Inhalte nur bestimmten Nutzern zur Verfügung zu stellen, um unternehmensinterne Informationen zu schützen. Dazu ist es notwendig, Benutzer zu authentifizieren (Anmeldung) und den Zugriff auf Inhalte zu autorisieren.
   Die Plattform besitzt bereits ein grundlegendes Berechtigungskonzept, welches nun auf Events und Prozessmodelle erweitert werden soll. Die Erweiterung ist notwendig, um sicherzustellen, dass nicht alle Nutzer alle Events bzw. alle Prozessmodelle einsehen können. Zu diesem Zweck muss geprüft werden, inwieweit das existierende Berechtigungskonzept geeignet ist, und wie es, auch konzeptionell, auf Events und Prozessmodelle angewendet werden kann.
   Bestandteil der Aufgabe ist sowohl die Konzeption, als auch die Umsetzung der Erweiterung des Berechtigungskonzepts.
   
   
3. Erweiterung des Query-Editors für Monitoring
   Event-Queries (ähnlich zu SQL) erlauben es, Abfragen über zusammenhängende Events, die von der Plattform erfasst wurden zu stellen. So lassen sich komplexe Anfragen stellen, um Abläufe zu steuern. Z.B.: Sind zwei Pakete mit identischer Lieferadresse im selben Logistikzentrum innerhalb eines Zeitraums von 24h eingegangen, so sollen diese konsolidiert und gemeinsam statt separat ausgeliefert werden.
   Aktuell lassen sich Events nur über Queries, die aus einen Prozessmodell generiert wurden, oder durch explizit erstellte Queries abfragen. Speziell letzteres ist nicht benutzerfreundlich und fehleranfällig. Daher soll eine einfache Möglichkeit gefunden werden, wie sich Event-Queries ohne Prozessmodell generieren lassen. Dies beinhaltet auch deren Speicherung und Ausführung.
   Des Weiteren sind Möglichkeiten zu entwickeln, wie sich solche Queries für das Monitoring von Prozessen einsetzen lassen. Für den korrekten Ablauf muss sichergestellt werden, dass die Queries korrekt sind. Die Änderungen sollen kompatibel zu der angepassten Architektur (siehe Aufgabe 1) entwickelt werden.
   Bestandteil der Aufgabe ist sowohl die Konzeption, als auch die Umsetzung des Query-Editors ohne Prozessmodell.
   
   
4. Performance Analyse
   Die Plattform wurde vor dem Hintergrund entworfen, eine große Menge von Events, die ständig aus verschiedenen Quellen generiert werden, zu erfassen und miteinander und mit Geschäftsprozessen zu verknüpfen. Die tatsächliche Leistungsfähigkeit wurde jedoch noch nicht überprüft.
   Ziel dieser Aufgabe ist es daher, einen Lasttest der Event Processing Plattform durchzuführen und die Ergebnisse zu analysieren. Aus den Analyseergebnissen sollen dann entsprechende Verbesserungsvorschläge erarbeitet, gewichtet und ggf. umgesetzt werden.  Der Lasttest soll Hand in Hand mit dem Refactoring der Architektur (siehe Aufgabe 1) einhergehen und ist genau zu dokumentieren.
   Bestandteil der Aufgabe ist sowohl die Konzeption des Lasttests und dessen Auswertung, als auch die Erarbeitung und Umsetzung von Verbesserungsvorschläge.

Leistungserfassung

Der Leistungserfassungsprozess für das Seminar umfasst die folgenden Leistungen:

• regelmäßige und aktive Teilnahme am Seminar
• Zwischen- und Abschlusspräsentationen
• Implementierung samt Quellcodedokumentation (JavaDoc)
• Verfassen einer Entwicklerdokumentation (ca 5 Seiten)

Termine

Dienstag, 11:00-12:30 Uhr, Raum H-2.57

 

Die einzelnen Themen werden in der ersten Veranstaltung im Semester detailliert vorgestellt. Danach können interessierte Studenten für das zu bearbeitende Thema stimmen.

Nachdem die einzelnen Projektgruppen festgelegt wurden, trifft sich das Seminar wöchentlich, um den aktuellen Fortschritt der einzelnen Gruppen zu besprechen. Dies ist insbesondere nötig, da sich die einzelnen Aufgaben gegenseitig bedingen, und nur durch regelmäßige Treffen eine konsistente Entwicklung sichergestellt werden kann.

• Nach ca. fünf Wochen erfolgt eine Präsentation der Analyseergebnisse und des weiten Vorgehens.
• Nach ca. 10 Wochen eine Zwischenpräsentation zu ersten Implementierungsergebnissen.
• Am Ende des Seminars soll die Implementierung insgesamt präsentiert werden.

Zurück