Ein ESB (Enterprise Service Bus) ist ein Architekturmuster, bei dem eine zentralisierte Softwarekomponente die Integration zwischen Anwendungen durchführt. Ein ESB führt Transformationen von Datenmodellen durch, verwaltet die Konnektivität, führt das Nachrichtenrouting durch, konvertiert Kommunikationsprotokolle und verwaltet gegebenenfalls die Zusammenstellung mehrerer Anfragen. Der ESB kann diese Integrationen und Transformationen als Serviceschnittstelle zur Wiederverwendung durch neue Anwendungen bereitstellen.

Das ESB-Muster wird in der Regel mit einer speziell entwickelten Integrationslaufzeit und einem Toolset (d. h. einem ESB-Produkt) implementiert, das die bestmögliche Produktivität gewährleistet.

Ein ESB ist ein wesentlicher Bestandteil von SOA oder serviceorientierter Architektur, einer Softwarearchitektur, die Ende der 1990er Jahre entstand. SOA definiert eine Möglichkeit, Softwarekomponenten über Serviceschnittstellen wiederverwendbar zu machen. Diese Services verwenden in der Regel Standardschnittstellen (z. B. Web-Services), sodass sie schnell in neue Anwendungen integriert werden können, ohne dass die vom Service ausgeführten Funktionen in neuen Anwendungen dupliziert werden müssen.

Jeder Service in einer SOA verkörpert den Code und die Daten, die für die Ausführung einer vollständigen, diskreten Geschäftsfunktion erforderlich sind (z. B. die Bonitätsprüfung eines Kunden, die Berechnung einer monatlichen Kreditrate oder die Bearbeitung eines Hypothekenantrags). Die Serviceschnittstellen bieten eine lose Kopplung, d. h. sie können mit wenig oder gar keiner Kenntnis über die Art und Weise der Implementierung des darunter liegenden Service aufgerufen werden. So können die Abhängigkeiten zwischen den Anwendungen reduziert werden. Anwendungen hinter der Serviceschnittstelle können in Java, Microsoft .Net, Cobol oder einer anderen Programmiersprache geschrieben werden, die für Unternehmen als Paketanwendungen von einem Anbieter (z. B. SAP), SaaS-Anwendungen (z. B. Salesforce CRM) oder als Open-Source-Anwendungen bereitgestellt werden.

Serviceschnittstellen werden häufig anhand der Web Service Definition Language (WSDL) definiert, einer standardmäßigen Tag-Struktur, die auf XML (Extensible Markup Language) basiert. Die Dienste werden mithilfe von Standardnetzwerkprotokollen wie SOAP (Simple Object Access Protocol)/HTTP oder JSON/HTTP zugänglich gemacht, um Anforderungen zum Lesen oder Ändern von Daten zu senden. Die Service-Governance steuert den Lebenszyklus für die Entwicklung, und in der entsprechenden Phase werden die Services in einer Registrierung veröffentlicht. Dadurch können Entwicklungsteams sie schnell finden und wiederverwenden, um neue Anwendungen oder Geschäftsprozesse zusammenzustellen.

Services können völlig neu aufgebaut werden, werden jedoch häufig durch die Bereitstellung von Funktionen aus traditionellen Aufzeichnungssystemen erstellt. Unternehmen können wählen, ob sie eine auf Standards basierende Serviceschnittstelle vor den traditionellen Systemen bereitstellen oder den ESB verwenden, um über einen Adapter oder Connector eine direkte Verbindung zum traditionellen System herzustellen. Alternativ kann die Anwendung auch ihre eigene API bereitstellen. In jedem Fall schirmt der Enterprise Service Bus die neue Anwendung von der traditionellen Schnittstelle ab. Ein ESB führt die erforderliche Transformation und das Routing durch, um eine Verbindung mit dem Service des traditionellen Systems herzustellen.

Eine SOA kann auch ohne ESB-Architektur implementiert werden, das würde jedoch einfach nur eine Ansammlung von Services bedeuten. Jeder Anwendungseigner müsste eine direkte Verbindung zu jedem benötigten Service herstellen und die erforderlichen Datentransformationen für jede Serviceschnittstelle durchführen. Dies ist eine Menge Arbeit (selbst wenn die Schnittstellen wiederverwendbar sind) und schafft eine ernsthafte Herausforderung für die zukünftige Wartung, da jede Verbindung Punkt-zu-Punkt ist.

Theoretisch hat ein zentralisierter ESB das Potenzial, die Kommunikation, das Messaging und die Integration zwischen Services im gesamten Unternehmen zu standardisieren und erheblich zu vereinfachen. Hardware- und Softwarekosten können geteilt werden, indem die Server je nach Bedarf für die kombinierte Nutzung bereitgestellt werden, sodass eine skalierbare, zentralisierte Lösung entsteht. Ein einzelnes Spezialistenteam kann mit der Entwicklung und Wartung der Integrationen beauftragt (und bei Bedarf geschult) werden.

Softwareanwendungen stellen einfach eine Verbindung zum ESB her („sprechen“ mit dem ESB) und überlassen es diesem, die Protokolle umzuwandeln und die Nachrichten weiterzuleiten sowie in die erforderlichen Datenformate umzuwandeln, um die Interoperabilität für die Transaktionen zu gewährleisten.Der architektonische Ansatz des Enterprise Service Bus unterstützt Szenarien für die Anwendungsintegration, die Datenintegration und die Automatisierung von Geschäftsprozessen im Stil der Service-Orchestrierung. So müssen Entwicklungsteams deutlich weniger Zeit für die Integration aufwenden und können sich viel mehr auf die Bereitstellung und Verbesserung ihrer Anwendungen konzentrieren. Zudem bietet die Möglichkeit, diese Integrationen von einem Projekt zum nächsten wiederzuverwenden, das Potenzial für noch größere Produktivitätsverbesserungen und Einsparungen im weiteren Verlauf.

Während ESBs in vielen Unternehmen erfolgreich bereitgestellt wurden, sah man sie in vielen anderen Unternehmen eher als Nadelöhr. Änderungen oder Verbesserungen an einer Integration könnten andere, die dieselbe Integration verwenden, destabilisieren. Aktualisierungen der ESB-Middleware wirkten sich häufig auf bestehende Integrationen aus, sodass für jede Aktualisierung umfangreiche Tests erforderlich waren. Da der ESB zentral verwaltet wurde, mussten Anwendungsteams plötzlich auf ihre Integrationen warten. Mit zunehmendem Integrationsvolumen wurde die Implementierung von Hochverfügbarkeit und Disaster-Recovery für die ESB-Server immer kostspieliger. Und da es sich um ein unternehmensübergreifendes Projekt handelte, erwies sich die Finanzierung des ESB als schwierig und somit als zusätzliches Hindernis bei der Bewältigung dieser technischen Herausforderungen.

Letztendlich erwiesen sich die Herausforderungen der Wartung, Aktualisierung und Skalierung eines zentralisierten ESB als so überwältigend und kostspielig, dass der ESB oft genau jene Produktivitätsverbesserungen verzögerte, die er und die SOA bewirken sollten. Dies führte wiederum zu Frust unter den Teams in den Geschäftszweigen, die ein höheres Innovationstempo erwarteten.

Einen tiefgreifenderen Einblick in den Aufstieg und Fall des ESB finden Sie in diesem Artikel: „The fate of the ESB“ (Das Schicksal des ESB).

Die Microservices-Architektur ermöglicht die Aufteilung der Interna einer einzelnen Anwendung in kleine Teile, die unabhängig voneinander geändert, skaliert und verwaltet werden können. Microservices sind mit dem Aufkommen von Virtualisierung, Cloud-Computing, Praktiken zur agilen Entwicklung und DevOps entstanden und haben seither zunehmend an Bedeutung gewonnen. In diesen Kontexten bieten Microservices folgende Vorteile:

• Verbesserte Agilität und Produktivität von Entwicklungsteams, die neue Technologien in einen Teil einer Anwendung integrieren können, ohne den Rest der Anwendung zu berühren oder „nachzurüsten“.
• Einfachere, kosteneffizientere Skalierbarkeit durch die Möglichkeit, jede Komponente unabhängig von den anderen zu skalieren, um schnellstmöglich auf Workload-Anforderungen zu reagieren und die IT-Ressourcen möglichst effizient zu nutzen.
• Höhere Ausfallsicherheit, da sich der Ausfall einer Komponente nicht auf die anderen auswirkt und jeder Microservice seine eigenen Verfügbarkeitsanforderungen erfüllen kann, ohne dass die anderen Komponenten an die Anforderung einer „größten gemeinsamen Verfügbarkeit“ gebunden sind.

Die gleiche Granularität, die Microservices in das Anwendungsdesign einbringen, kann mit ähnlichen Vorteilen auch auf die Integration übertragen werden. Dies ist die Idee hinter der agilen Integration, die den ESB in differenzierte, dezentrale Integrationskomponenten ohne gegenseitige Abhängigkeiten aufteilt, die einzelne Anwendungsteams selbst besitzen und verwalten können.