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.

Ich bin ein wenig empört, dass meine Einleitung nicht übernommen wurde. Sie hätte das ganze doch noch ein wenig aufpoliert. Auszüge:

“Wer Service Orientierte Architekturen, wer einen Enterprise Service Bus für die Mutter aller Softwarearchitekturen hält, zeugt von einer gewissen Intelligenzferne. Wer umgekehrt jedoch diese Begriffe und die dazugehörigen Wölkchengrafiken für ein Sexsurrogat midlife-crisis-geplagter Informatiker hält, verkennt den wahren Wert von SOA und ESB.

Was also ist ein ESB? Was ist SOA? Sind es Lösungen auf der Suche nach einem Problem? Bei jedem Hype der letzten Jahre ist genau dies eingetreten: ohne Sinn und Verstand wurde die neue Lösung gegen alle Probleme eingesetzt, die sich nicht schnell genug verstecken konnten. Erstaunt mussten viele IT-Manager sich später eingestehen lassen, nur neue Probleme geschaffen zu haben. Plötzlich wimmelte es von Applikationsservern, Webservices unterhielten sich untereinander und zum Erstaunen der Security Manager mit völlig fremden Systemen – jeder Arbeitsschritt – ob stimmig oder nicht – wurde dokumentiert und CMMI-konform abgeheftet. Nur selten jedoch wurde die Arbeit weniger, die Probleme geringer. SOA und ESB versprechen viel, können aber auch nur dort etwas halten, wo sie zu Recht eingesetzt werden.
Gut. Doch wo nun sollte auf Services gesetzt werden? In jedem Unternehmen, das etwas auf sich hält und schon einige Jahre und Jahrzehnte IT-Projekte betreibt, gibt es Unaussprechliches. Software, die funktioniert oder zumindest verlässlich arbeitet, ohne dass sie jemand noch erklären und verstehen könnte. Software, die vor IT-Äonen entwickelt wurde, deren ursprüngliche Programmierer längst verschwunden oder frühverrentet wurden. Software also, die man in Präsentationen verschämt als Legacy-Systeme beschreibt. Man würde sie ja gerne ersetzen, aber das Risiko ist zu hoch. Wie aber können diese Systeme wiederbelebt werden? Wie können sie in aktuelle Projekte integriert werden? Hier kommen SOA und ESB ins Spiel.”

Ich glaube, bei Sexsurrogat war das Ende dieser Einleitung besiegelt. Es hat dem Buch effektiv auf inhaltlicher Ebene gut getan, darauf zu verzichten. Es wäre aber noch einen Hauch unterhaltsamer geworden :)