Der ESB ist ein wesentlicher Bestandteil von SOA (serviceorientierte Architektur), einer Softwarestruktur, die Ende der 1990er Jahre entstand. SOA definiert eine Möglichkeit, um Softwarekomponenten über Serviceschnittstellen wiederverwendbar zu machen. Diese Services nutzen in der Regel Standardschnittstellen (z. B. Web-Services), weshalb sie zügig in neue Anwendungen integrierbar sind, 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 zur 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 sind lose gekoppelt, d. h. sie lassen sich mit wenig oder ganz ohne Kenntnis über die Art und Weise der Implementierung des darunter liegenden Service aufrufen. 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 als Paketanwendungen für Unternehmen 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 auf XML-Basis (Extensible Markup Language). Die Dienste sind mithilfe von Standardnetzwerkprotokollen wie SOAP (Simple Object Access Protocol)/HTTP oder JSON/HTTP nutzbar, um Anforderungen zum Lesen oder Ändern von Daten zu senden. Die Service-Governance steuert den Entwicklungslebenszyklus und in der passenden 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 lassen sich von Grund auf neu entwickeln, entstehen jedoch häufig durch das Ausführen von Funktionen aus Legacy-Aufzeichnungssystemen. Unternehmen können wählen, ob sie eine auf Standards basierende Serviceschnittstelle vor den traditionellen Systemen bereitstellen oder mit dem ESB über einen Adapter oder Konnektor eine direkte Verbindung zum traditionellen System herstellen. Alternativ kann die Anwendung auch eine eigene API bereitstellen. Der Enterprise Service Bus schirmt die neue Anwendung in jedem Fall von der Legacy-Schnittstelle ab und führt die erforderliche Transformation und das Routing durch, um eine Verbindung zum Service des Legacy-Systems herzustellen.

Eine SOA kann zwar auch ohne ESB-Architektur implementiert werden, wäre dann aber einfach nur eine beliebige Ansammlung von Services. Jeder Anwendungsbesitzer müsste eine direkte Verbindung zu jedem benötigten Service herstellen und die erforderlichen Datentransformationen für jede Serviceschnittstelle durchführen. Das ist viel Arbeit (selbst wenn die Schnittstellen wiederverwendbar sind) und bedeutet eine ernsthafte Herausforderung für die zukünftige Wartung, da jede Verbindung Punkt-zu-Punkt ist.

Theoretisch kann ein zentraler ESB die Kommunikation, das Messaging und die Integration zwischen Services im gesamten Unternehmen standardisieren und erheblich vereinfachen. Hardware- und Softwarekosten können geteilt werden, wenn die Server je nach Bedarf zur kombinierten 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.

Software verbindet sich einfach mit dem ESB („spricht“ mit dem ESB) und lässt ihn dann die Protokolle transformieren, die Nachrichten weiterleiten und in die erforderlichen Datenformate umwandeln, um die Interoperabilität für die Transaktionen zu gewährleisten. Der architektonische Ansatz des Enterprise Service Bus unterstützt Szenarien zur Anwendungsintegration, Datenintegration und Automatisierung von Geschäftsprozessen im Stil der Service-Orchestrierung. Entwickler brauchen deutlich weniger Zeit für die Integration und können sich stattdessen auf die Bereitstellung und Verbesserung ihrer Anwendungen konzentrieren. Und durch die Wiederverwendung dieser Integrationen von einem Projekt zum nächsten sind im weiteren Verlauf noch größere Produktivitätsverbesserungen und Einsparungen möglich.

ESBs wurden in vielen Unternehmen erfolgreich bereitgestellt, doch manchmal erwiesen sie sich auch als Engpass. Änderungen oder Verbesserungen an einer Integration destabilisierten andere, die dieselbe Integration verwendeten. Aktualisierungen der ESB-Middleware beeinträchtigten häufig bestehende Integrationen, 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 eine unternehmensübergreifende Architektur handelte, erwies sich die Finanzierung des ESB als schwierig und somit als zusätzliches Hindernis bei der Bewältigung dieser technischen Herausforderungen.

Letztendlich waren die Herausforderungen der Wartung, Aktualisierung und Skalierung eines zentralisierten ESB so überwältigend und kostspielig, dass er oft genau die Produktivitätsverbesserungen verzögerte, die er und die SOA bewirken sollten. Dies frustrierte wiederum die Geschäftsteams, die ein höheres Innovationstempo erwarteten.

Mehr zum Aufstieg und Fall des ESB finden Sie in diesem Artikel: „The fate of the ESB“ (Das Schicksal des ESB).

Mit der Microservices-Architektur können die einzelnen Bestandteile einer Anwendung in kleine Teile aufgelöst werden, um sie unabhängig voneinander zu ändern, zu skalieren und zu administrieren. 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 so effizient wie möglich zu nutzen.
• Höhere Resilienz, da sich der Ausfall einer Komponente nicht auf die anderen auswirkt und jeder Microservice eigene 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.