Dies lösen wir – oh, Gott, Hypeattacke – über eine SOA-Architektur mit einem Enterprise Service Bus (ESB) im Zentrum. Dieser spielt den großen Mediator zwischen Automaten, eigenen Services und externen Schnittstellen.

Ändert man jedoch nur einen Buchstaben, wechselt man vom ESB zu ESP, ergibt sich eine weit aus größere Veränderung: ESP steht für Event Stream Processor. ESP-Applikationen sind darauf ausgelegt, Unmengen an Nachrichten verarbeiten zu können. Allerdings zumeist nicht auf per message Basis. ESP schauen sich den Nachrichtenstrom an und erkennen im Fluß Muster. Die einzelne Nachricht ist egal, wichtig ist, die Masse an Informationen zu betrachen und Korrelationen zu erkennen. Gibt es eine Übereinstimmung, kann ein Service (oder ein ESB) angestoßen werden, der eine entsprechende Aktion auflöst.

Übertragen auf unseren Anwendungsfall (was hier ein wenig an den Haaren herbeigezogen ist, aber ich bin heute nur bedingt kreativ) könnte ein Beispiel lauten:

“Musterdefinition: wenn ein Automat nicht innerhalb von einer halben Stunde eine Nachricht schickt, dann triggere MachineOfflineStrategy”

Natürlich gibt es für diesen Fall bessere Lösungen, es zeigt aber einen sehr interessanten Aspekt an einem ESP auf: die Definition von “Zeit-basierenden Sichtfenstern”: man lege eine Schablone über den Nachrichtenfluss und prüfe für diesen Ausschnitt nach Musterübereinstimmungen.

Feine Sache. Und, uhm, ja, das “ESP vs. ESB” habe ich nur sprachklanglichen Gründen eingefügt. Genau genommen sind ESP und ESB ein hervorragendes Tandem.

Dazu später mehr.