Was ist ein Enterprise Service Bus (ESB)?

Ein ESB transformiert Datenmodelle, organisiert die Konnektivität, routet Nachrichten, konvertiert Kommunikationsprotokolle und kann die Zusammenstellung mehrerer Anfragen organisieren. ESBs können diese Integrationen und Transformationen in Form einer Serviceschnittstelle bereitstellen, sodass sie von neuen Anwendungen wiederverwendet werden können.

Die ESB-Struktur wird in der Regel mithilfe 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.

Service-Schnittstellen 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 Enterprise Service Bus-Ansatz unterstützt Szenarien für die Anwendungsintegration, Datenintegration und Automatisierung von Geschäftsprozessen im Stil der Dienstorchestrierung. 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.

In Fällen, die dem Beschriebenen ähneln, sind die Herausforderungen der Wartung, Aktualisierung und Skalierung eines zentralisierten ESB so überwältigend und kostspielig, dass er oft genau die Produktivitätsverbesserungen verzögert, die er und die SOA bewirken sollten. Dies frustriert wiederum die Geschäftsteams, die ein höheres Innovationstempo erwarteten. Daher sollten Unternehmen dringend überlegen, ob ein ESB basierend auf der vorhandenen IT-Infrastruktur eines Unternehmens die richtige Wahl darstellt oder ob stattdessen nicht eher modernere und flexiblere Alternativen genutzt werden sollten.

Mehr zum 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, Verfahren zur agilen Entwicklung und DevOps entstanden und haben seither zunehmend an Bedeutung gewonnen. In diesen Kontexten bieten Microservices folgende Vorteile:

• Erhöhte Entwickleragilität und Produktivität durch die Möglichkeit für Entwickler, neue Technologien in einen Teil einer Anwendung zu integrieren, ohne den Rest der Anwendung ändern oder anpassen zu müssen.
• 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. Diese Effizienz macht den IT-Betrieb deutlich flexibler und kann schnell und präzise auf steigende Anforderungen reagieren. Im Vergleich dazu ist die Skalierung bei einem ESB deutlich weniger flexibel, da dieser in der Regel eine größere Einheit ausmacht.
• 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. Bei einem ESB müssen sämtliche Anwendungen stets verfügbar sein – fällt eine einzelne Anwendung innerhalb eines komplexen Konstrukts aus, hat dies potenziell schwerwiegende Auswirkungen auf die anderen. Dieser Unterschied macht Microservices deutlich ausfallsicherer.

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.