Der Enterprise Service Bus heute

Inhaltsverzeichnis

Welche Rolle spielt der Enterprise Service Bus heute noch, wo alle Welt nur noch von Microservices redet.

Enterprise Service Bus, kurz ESB, war lange Zeit ausschließlich ein Synonym für komplexe, serviceorientierte Architekturen (SOA) und das zentrale Rückgrat für viele Enterprise-Anwendungen. Man hat die beiden Kürzel auch immer irgendwie gefürchtet. Solche Projekte wurden zumeist stark von den Fachabteilungen getrieben und die wollten lange Zeit auch selbst bei der Modellierung der verschiedenen Prozesse aktiv mithelfen.

Nach etlichen Jahren, in denen alle Beteiligten ihre Erfahrungen sammeln konnten, war das Thema irgendwie nicht mehr so spannend. Lediglich die Seiteneffekte sind geblieben: SOA-Projekte blieben stets komplex und eine Herausforderung.

Microservices = SOA 2.0?

Aber wie ist das denn heute? Sind ESBs und SOA-basierte Anwendungen nicht mehr notwendig? Alle reden doch jetzt von Microservices. Tatsächlich ist das Thema Integration einen weiten Weg gegangen. Von Punkt-zu-Punkt-Verbindungen einzelner Systeme über erste Integrationslösungen, in denen Schnittstellen und Kommunikationswege standardisiert wurden, bis hin zu SOA. Ihnen allen war gemein, dass sie Wiederverwendung und Austauschbarkeit von einzelnen Funktionen versprachen. Und das war zumeist nur möglich als eine zentrale, überwachte Infrastruktur-Komponente.

Mit Microservices wandelt sich das: Es geht immer noch um Wiederverwendung und Austauschbarkeit, aber nun auch um Dinge wie verteilte Anwendungen und Dezentralisierung. Augenscheinlich hat ein ESB in solch einer Welt keinen Platz mehr, oder? Tatsächlich ist der Bedarf, die zunehmende Serviceanzahl zu verwalten, so hoch wie nie. Dazu kommt, dass die Services auch durchaus polyglott sein können und dank Platform as a Service (PaaS) angeboten auch vollständig verteilt betrieben werden.

Nicht nur sauber, sondern rein

Die Hersteller von ESBs haben das natürlich auch erkannt, und tatsächlich finden sich schon die ersten Produkte, die mit dem Beinamen "Microservices" suggerieren, diesen Problemen zu begegnen. Tatsächlich ist der neue Architekturansatz aber einfach zu neu, um sich frühzeitig und unnötig in eine Herstellerbindung zu begeben. Ein großer Vorteil gegenüber SOA ist tatsächlich, dass es keiner herstellerspezifischen Produkte oder Standards bedarf, um eine Microservice-Architektur aufzubauen. Es sind keine komplexen, zentralisierten Produkte notwendig. Was tatsächlich notwendig ist, wird gerne auch mit der sogenannten äußeren Architektur beschrieben.

Am Beispiel einer Java-/-Java-EE-basierten Landschaft lässt sich das am einfachsten kurz umreißen. Neben dem Service selbst werden vor allem eine leichtgewichtige Runtime (bspw. WildFly, WildFly Swarm) sowie eine Registry benötigt, auf der die Services lose gekoppelt werden sollen. Diese muss nicht, wie in diesem Bild dargestellt zentral vorliegen, sondern sollte selbst verteilt arbeiten. Eine weitere wichtige Komponente ist dann das API-Management, inklusive der notwendigen API-Sicherheit. Die im Bild verwendeten Logos geben ein paar Hinweise auf Open-Source-Projekte, mit denen eine solche Microservice-Architektur aufgebaut werden kann.

Aber es kommt noch viel mehr

Und genau darum hab ich auch eine komplette Präsentation mit dem Titel gehalten. Sie ist öffentlich auf Slideshare zugänglich und wurde auf der JavaOne auch aufgezeichnet. Sobald verfügbar, werde ich den Link auf meinem Blog auch entsprechend posten.

Wer schneller noch mehr erfahren will, dem kann ich nochmal mein kleines, kostenloses Mini-Buch ans Herz legen. "Moderne Java EE Design Pattern" geht auf noch mehr Details rund um das Thema Microservices und moderne Architekturen ein. ()