ESB (Enterprise Service Bus)

menu icon

ESB (Enterprise Service Bus)

In diesem Leitfaden erfahren Sie mehr über den ESB (eine wesentliche Komponente von SOA), die Vorteile, die er bietet, und wie er mit der Microservices-Architektur zusammenhängt.

Was ist ein ESB (Enterprise Service Bus)?

Ein ESB oder Enterprise-Service-Bus ist ein Muster, bei dem eine zentrale Softwarekomponente Integrationen auf Back-End-Systeme (und Übersetzungen von Datenmodellen, tiefe Konnektivität, Routing und Anforderungen) ausführt und diese Integrationen und Übersetzungen als Serviceschnittstellen zur Wiederverwendung durch neue Anwendungen bereitstellt. Das ESB-Muster wird in der Regel mit einer speziell konzipierten Integrationslaufzeit und einem Toolset implementiert, die die bestmögliche Produktivität gewährleisten.

ESB und SOA

Ein ESB ist ein wesentlicher Bestandteil der SOA oder der serviceorientierten Architektur, eine Architektur, die in den späten 1990er Jahren entstanden ist. SOA definiert einen Weg, Softwarekomponenten über Service-Schnittstellen wiederverwendbar zu machen. Diese Schnittstellen nutzen gemeinsame Kommunikationsstandards so, dass sie schnell in neue Anwendungen integriert werden können, ohne dass sie jedes Mal eine tiefe Integration durchführen müssen.

Jeder Service in einer SOA verkörpert die Code- und Datenintegrationen, die erforderlich sind, um eine vollständige, diskrete Geschäftsfunktion auszuführen (z. B. das Prüfen eines Kundenkredits, die Berechnung einer monatlichen Darlehenszahlung oder die Bearbeitung eines Hypothekenantrags). Die Serviceschnittstellen bieten eine lose Kopplung, d. h., sie können mit wenig oder gar keinem Wissen darüber aufgerufen werden, wie die Integration darunter implementiert ist. Die Services werden mithilfe von Standard-Netzprotokollen - z. B. SOAP (Simple Object Access Protocol)/HTTP oder JSON/HTTP - zum Senden von Anforderungen zum Lesen oder Ändern von Daten bereitgestellt. Die Services werden so veröffentlicht, dass Entwickler sie schnell finden und wiederverwenden können, um neue Anwendungen zusammenzustellen.

Diese Services können von Grund auf neu erstellt werden, werden jedoch häufig durch die Bereitstellung von Funktionen aus traditionellen Systemen des Datensatzes als Serviceschnittstellen erstellt. An dieser Stelle entsteht der Bedarf für einen ESB. Traditionelle Systeme und Systeme von Datensätzen verwenden in der Regel alte Protokolle und proprietäre Datenformate, die übersetzt und in die Arbeit mit den SOA-Netzwerkprotokollen integriert werden müssen. Ein ESB führt diese Übersetzungen und Integrationen im laufenden Betrieb durch. Sie könnten eine SOA ohne ESB implementieren, aber Anwendungseigner müssten jeweils einen eigenen Weg finden, um Serviceschnittstellen verfügbar zu machen. Dies bedeutet eine Menge Arbeit (selbst wenn die Schnittstellen letztendlich wiederverwendbar sind) und stellt eine erhebliche Herausforderung für die Wartung in der Zukunft dar.

Weitere Informationen zu SOA  und der Rolle eines ESB darin finden Sie unter "Einführung in SOA (Serviceorientierte Architektur)".

Vorteile

In der Theorie bietet ein zentralisiertes ESB das Potenzial, die Kommunikation und Integration von Dienstleistungen im gesamten Unternehmen zu standardisieren - und drastisch zu vereinfachen. Hardware- und Softwarekosten können geteilt werden, die Bereitstellung der Server muss nur einmal erfolgen, und ein einziges Team von Spezialisten kann mit der Entwicklung und Wartung der Integrationen beauftragt (und gegebenenfalls geschult) werden.

Entwickler können ein einzelnes Protokoll verwenden, um mit dem ESB zu "sprechen" und Befehle auszugeben, die Interaktionen zwischen Services lenken und es dem ESB überlassen, die Befehle zu übersetzen, die Nachrichten weiterzuleiten und die Daten nach Bedarf umzuwandeln, damit die Befehle ausgeführt werden. Dies würde es Entwicklern ermöglichen, erheblich weniger Zeit mit der Integration und viel mehr Zeit mit der Konfiguration und Verbesserung ihrer Anwendungen zu verbringen. Und die Möglichkeit, diese Integrationen von einem Projekt zum nächsten wiederzuverwenden, bot das Potenzial für noch größere Produktivitätssteigerungen und Einsparungen im weiteren Verlauf.

Aber während ESBs in vielen Organisationen erfolgreich eingesetzt wurden, wurde der ESB in vielen anderen Organisationen als Engpass bei der SOA-Einführung angesehen. Änderungen oder Erweiterungen an einer Integration destabilisierten oft andere. Updates der ESB-Middleware wirkten sich oft auf bestehende Integrationen aus. Da der ESB zentral verwaltet wurde, standen die Anwendungsteams bald Schlange für ihre Integrationen. Da das Volumen der Integrationen wuchs, wurde die Implementierung von Hochverfügbarkeit und Disaster-Recovery für die ESB-Server teurer. Und da es sich um ein unternehmensübergreifendes Projekt handelte, erwies sich die Finanzierung des ESB als schwierig, was die Lösung dieser technischen Herausforderungen noch schwieriger machte.

Letztendlich erwiesen sich die Herausforderungen bei der Wartung, Aktualisierung und Skalierung eines zentralisierten ESB als so überwältigend und teuer, dass der ESB oft genau die Produktivitätsgewinne verzögerte, die er und die SOA bringen sollten, was die Teams in den Geschäftsbereichen frustrierte, die ein höheres Innovationstempo erwarteten.

Für einen tieferen Einblick in den Aufstieg und Fall des ESB, lesen Sie "Das Schicksal des ESB".

ESB im Vergleich zu Microservices

Durch die Architektur von Mikroservices können die Einbauten einer einzelnen Anwendung in kleine Teile zerlegt werden, die unabhängig voneinander geändert, skaliert und verwaltet werden können. Microservices kamen mit dem Aufstieg von Virtualisierung, Cloud-Computing, Agile Development Practices und DevOps auf. In diesen Kontexten bieten Microservices Folgendes:

  • Verbesserte Agilität und Produktivität durch die Möglichkeit, neue Technologien in einen Teil einer Anwendung einzubinden, ohne den Rest der Anwendung zu berühren oder "nachzuholen".
  • Einfachere, kosteneffizientere Skalierbarkeit durch die Möglichkeit, jede Komponente unabhängig von anderen zu skalieren, um schnellstmöglich auf Workload-Anforderungen zu reagieren und die Rechenressourcen möglichst effizient zu nutzen.
  • Höhere Ausfallsicherheit, da der Ausfall einer Komponente sich nicht auf die anderen auswirkt und jeder Microservice seine eigenen Verfügbarkeitsanforderungen erfüllen kann, ohne dass die anderen Komponenten einer "größten gemeinsamen Verfügbarkeitsanforderung" unterworfen sind.

Die gleiche Granularität, die Microservices für das Anwendungsdesign mit sich bringen, kann auch für die Integration genutzt werden - mit ähnlichen Vorteilen. Dies ist die Idee hinter der agilen Integration, die den ESB in feinkörnige, dezentrale Integrationskomponenten ohne Abhängigkeiten aufbricht, die die einzelnen Anwendungsteams selbst besitzen und verwalten können.

Für einen tieferen Einblick in alle Themen rund um Microservices lesen Sie "Microservices: Ein umfassender Überblick", "SOA im Vergleich zu Microservices: Was ist der Unterschied?"  und sehen Sie sich das Video von Dan Bettinger an: “Was sind Microservices?”:

ESB und IBM Cloud

Wenn Ihr Unternehmen seine IT-Infrastruktur auf einen  Hybrid-Cloud-Ansatz umstellt, ist die Wahrscheinlichkeit groß, dass Sie eine Vielzahl von Workloads, einschließlich solcher, die auf SOA- und ESB-Mustern basieren, auf leichtere und flexiblere Bereitstellungsmodelle umstellen. Solche Transformationen sind  nur ein Teil  der  Anwendungsmodernisierung  eines jeden Unternehmens auf dem  Weg zur Cloud.  

Machen Sie den nächsten Schritt:

  • Sehen Sie, wie Sie Ihre Middlewareinvestitionen mit IBM Cloud  Pak for Integration nutzen, erweitern und modernisieren können.
  • Erfahren Sie, wie Sie alle Ihre Anwendungen und Daten über mehrere  private  und öffentliche Clouds für personalisierte Kundenerlebnisse durch den Besuch von  IBM Cloud Integration verbinden können.

Starten Sie noch heute mit einem  IBM Cloud-Konto.