Architektur con CEP-Engines
CEP-Engines in verteilten Anwendungen
An dieser Stelle wird das Zusammenspiel von CEP-Engines, Datenquellen und Datensenken mit einer Anwendung näher erläutert. Die innere Architektur von CEP-Engines kann nicht allgemein betrachtet werden. Daher werden lediglich die von außen sichtbaren Merkmale vorgestellt, die die meisten CEP-Engines gemein haben. Darauf aufbauend wird eine Einsatzarchitektur in einem verteilten Umfeld erläutert.
Das Complex Event Processing (CEP) hat eine klar definierte Aufgabe: die unverzügliche Analyse von eintretenden Events und Event-Mustern (Pattern). Dies unterscheidet CEP von herkömmlichen Datenverarbeitungssystemen, die auf Datenbanktechniken basierend einen Datenbestand nach Bedarf auswerten. Häufig wird daher auch von einem Push-Konzept bei CEP-Anwendungen und Pull-Konzepten bei Datenbank-Anwendungen gesprochen.
Bei Pull-Konzepten gibt es einen Initiator, z.B. einen Benutzer, der einer Anwendung eine Suchanfrage übergibt. Bei CEP-Systemen initiiert meist ein Event die weiteren Auswertungen.
CEP-Systeme verfügen über Input- und Output-Adapter. Die Input-Adapter können Events empfangen und haben die Aufgabe, das jeweilige Datenformat der Datenquelle auf ein für die CEP-Engine geeignetes Datenformat abzubilden. Output-Adapter haben im Wesentlichen die umgekehrte Aufgabe. Für die Zustellung von Events in einem verteilten System kann es von großem Vorteil sein, sog. Enterprise Service Buses (ESBs) einzusetzen.
Zusammenspiel mit einem ESB und BPM
Mit einem ESB ist bereits der Informationsfluss vieler verteilter Systeme gebündelt, die an einer verteilten Geschäftsanwendung partizipieren. Diese Systeme umfassen häufig mehrere Webservices und möglicherweise eine Business Process Management (BPM)-Engine, die diese Dienste orchestriert. Darüber hinaus kann noch eine Vielzahl weiterer Systeme wie ERP-Systeme, Rule-Engines oder Datenbanken angegliedert sein. Die verschiedenen Events all dieser Systeme werden vom Event-Produzenten zu den Event-Konsumenten bereits über den ESB verteilt. Der Event-Stream ist also bereits an einer Stelle verfügbar. An diese Stelle wird folglich auch die CEP-Engine angegliedert. Alternativ müssten die Input-Adapter diese Aufgabe für alle denkbaren Datenquellen übernehmen bzw. das CEP müsste verteilt stattfinden.
Werden relevante Events bzw. Event-Pattern gefunden, so können wiederum über den ESB oder über externe Systeme Ergebnisse an die entsprechenden Empfänger verteilt werden. Natürlich sind auch weitergehende Reaktionen spezifizierbar. Diese Architektur eröffnet viele Möglichkeiten, insbesondere im Zusammenspiel von CEP mit Geschäftsprozessen. In Geschäftsprozessen können beispielsweise Punkte definiert werden, an welchen auf das Auftreten eines Events gewartet wird. Dieses Event kann vom CEP als Ergebnis einer Event-Kombination im ESB erzeugt werden. Als Folge reagiert ein Prozess automatisiert auf komplexe Ausnahmefälle. Darüber hinaus kann mit einem ähnlichen Vorgehen das Auftreten komplexer Event-Bedingungen auch direkt in einen Prozessablauf integriert werden.
Beispielszenario
In einem Beispielszenario „Druckerei“ könnten drei Druckmaschinen an den ESB angeschlossen sein. Jeder Druckauftrag wird über einen Prozess durchgeführt. Der Prozess sendet dabei den Druckauftrag an den ESB und der ESB verteilt die Druckaufträge auf die Druckmaschinen. Wenn nun innerhalb kurzer Zeit mehrmals das Event auftritt, dass alle Druckmaschinen ausgelastet sind, dann kann durch die externe Vergabe von Druckaufträgen reagiert werden. Dies benötigt jedoch ein Genehmigungsverfahren, welches direkt durch einen eigenen Prozess bei Auftreten der Events gestartet wird. Auf diese Weise wird eine zeitnahe Reaktion durch das Zusammenspiel aller Komponenten ermöglicht. Der zeitlich begrenzte Engpass an Druckmaschinen wird ohne großen Verwaltungsaufwand überbrückt. Ein solches Szenario zeigt die Mächtigkeit, die in der Kombination der Bestandteile liegt und Menschen von zeit- und kostenintensiven Überwachungsaufgaben befreit.
