Ein  ESB  ist ein wesentlicher Bestandteil der SOA oder  der serviceorientierten Architektur, eine Software architektur, die in den späten 1990er Jahren entstanden ist. SOA  definiert einen Weg, Softwarekomponenten über Service-Schnittstellen wiederverwendbar zu machen. Diese Services verwenden in der Regel Standardschnittstellen (d.h.  Web-Services), so dass sie schnell in neue Anwendungen integriert werden können, ohne dass die vom Service ausgeführte Funktionalität  in neuen Anwendungen dupliziert werden muss.

Jeder Service in einer  SOA  enthält den Code und die  Daten, die zur Ausführung einer vollständigen, diskreten Geschäftsfunktion erforderlich sind (z. B. Prüfung der Kreditwürdigkeit eines Kunden, Berechnung einer monatlichen Kreditrate oder 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 der Service  darunter implementiert ist, wodurch die Abhängigkeiten zwischen den Anwendungen verringert werden. Anwendungen hinter der Serviceschnittstelle können in  Java, Microsoft ,Net, Cobol oder anderen Programmiersprachen geschrieben werden und werden durch einen Anbieter (z. B. SAP),  SaaS -Anwendungen (z. B. Salesforce  CRM) als gepackte Softwareanwendungen bereitgestellt oder als  Open-Source -Anwendungen bezogen.  

Serviceschnittstellen werden häufig mithilfe der  Web-Service  Definition Language (WSDL) definiert, einer Standard-Tag-Struktur auf der Grundlage von  XML  (Extensible Markup Language).  Die Services werden über Standard- Netzwerk protokolle – wie SOAP (Simple Object Access Protocol)/HTTP oder  JSON/HTTP – bereitgestellt, um Anfragen zum Lesen oder Ändern von Daten zu senden. Die Service-Governance steuert den Lebenszyklus der Entwicklung, und in der entsprechenden Phase werden die Services in einer Registry  veröffentlicht, die es den Entwicklern ermöglicht, sie schnell zu finden und für die Zusammenstellung neuer Anwendungen oder  Geschäftsprozesse wiederzuverwenden.

Services können von Grund auf neu entwickelt werden, werden aber oft durch die Offenlegung von Funktionen aus  Legacy-Systemen  erstellt. Unternehmen können wählen, ob sie eine auf Standards basierende Serviceschnittstelle vor den  Legacy-Systemen bereitstellen, den ESB nutzen, um sich über einen  Adapter oder Konnektor direkt mit dem  Legacy-System  zu verbinden, oder ob die Anwendung ihre eigene API  bereitstellt. In jedem Fall  schirmt der Enterprise Service Bus die neue Anwendung von der Legacy-Schnittstelle ab. Ein  ESB  führt die notwendige Transformation und das Routing durch, um eine Verbindung zum Service des  Legacy-Systems  herzustellen.

Es ist möglich, eine  SOA ohne eine ESB -Architektur zu implementieren, doch wäre dies gleichbedeutend mit einer bloßen Ansammlung von Services. Jeder Anwendungseigner müsste eine direkte Verbindung zu jedem von ihm benötigten Service herstellen und die erforderlichen Datentransformationen vornehmen, um jede der  Serviceschnittstellen zu erfüllen. Dies ist viel Arbeit (selbst wenn die Schnittstellen wiederverwendbar sind) und schafft ein erhebliches Wartungsproblem in der Zukunft, da jede Verbindung von Punkt zu Punkt geht.

In der Theorie bietet ein zentralisiertes  ESB  das Potenzial, die Kommunikation,  Messaging und Integration von Services im gesamten Unternehmen zu standardisieren - und drastisch zu vereinfachen. Die Hardware- und Softwarekosten können geteilt werden, indem die Server je nach Bedarf für die kombinierte Nutzung bereitgestellt werden, wodurch eine skalierbare, zentralisierte Lösung entsteht.  Ein Team von Spezialisten kann mit der Entwicklung und Pflege der Integrationen beauftragt (und gegebenenfalls geschult) werden.

Softwareanwendungen  stellen einfach eine Verbindung zum  ESB  her und überlassen es dem  ESB , die Protokolle umzuwandeln, die Nachrichten weiterzuleiten und in die erforderlichen  Datenformate  umzuwandeln, um die Interoperabilität für die Ausführung der Transaktionen sicherzustellen. Der Architekturansatz des  Enterprise Service Bus  unterstützt Szenarien für die Anwendungsintegration, die  Datenintegration und die Automatisierung von Geschäftsprozessen mittels  Serviceorchestrierung .  Auf diese Weise müssen Entwickler deutlich weniger Zeit für die Integration aufwenden und  können sich viel mehr auf die Bereitstellung  und Verbesserung ihrer Anwendungen konzentrieren. 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 angesehen. Änderungen oder Erweiterungen an einer Integration könnten andere,  die dieselbe Integration verwenden, beeinträchtigen. 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, 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".

Durch die Architektur von Microservices 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 wurden mit dem Aufkommen von  Virtualisierung , Cloud Computing, agilen Entwicklungspraktiken und DevOps eingeführt und haben an Bedeutung gewonnen. In diesen Kontexten bieten Microservices  Folgendes:

• Verbesserte Agilität und Produktivität von Entwicklern , da diese neue Technologien in einen Teil einer Anwendung integrieren können, ohne den Rest der Anwendung zu verändern. 
• 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 Resilienz , 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 differenzierte, dezentrale Integrationskomponenten ohne Abhängigkeiten aufbricht, die die einzelnen Anwendungsteams selbst besitzen und verwalten können.

Für einen tieferen Einblick in Microservices lesen Sie den “Leitfaden zu Microservices,” "SOA vs. Microservices: Was ist der Differenz ?“ und schauen Sie sich Dan Bettingers Video zu „Microservices" an:

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 erforderlichen Anwendungsmodernisierung,  wobei sich die Nachfrage nach besseren Kundenerlebnissen und mehr Anwendungen auf Ihre Geschäfts- und IT-Abläufe auswirkt. Wenn es darum geht, diese Anforderungen zu erfüllen, wird ein Wechsel zu mehr Automation helfen. Im Idealfall sollte eine stärkere Automatisierung mit kleineren Projekten mit messbarem Erfolg beginnen, die Sie dann skalieren und für andere Prozesse und in anderen Teilen Ihres Unternehmens optimieren können.

Durch die Zusammenarbeit mit IBM erhalten Sie Zugriff auf KI-gestützte Automatisierungsfunktionen, einschließlich vordefinierter Workflows, um die Innovation durch intelligentere Prozesse zu beschleunigen.

Machen Sie den nächsten Schritt:

• Informieren Sie sich darüber, wie Sie Ihre Middleware-Investitionen mit IBM Cloud  Pak for Integration, einer hybriden Integrationslösung, die einen automatisierten und geschlossenen Lebenszyklus für verschiedene Arten der Unternehmensintegration bietet, nutzen, erweitern und modernisieren können.
• Erfahren Sie, wie Sie alle Ihre Anwendungen und Daten über mehrere  Private  und Public Clouds hinweg miteinander verbinden können, um personalisierte Kundenerlebnisse zu schaffen, indem Sie IBM Cloud Integration-Lösungen besuchen.
• Nutzen Sie den IBM Application Modernization Field Guide, um zu erfahren, wie Sie die Modernisierung beschleunigen, die Entwicklerproduktivität verbessern und die betriebliche Effizienz und Standardisierung voranbringen können.
• Nehmen Sie an unserer Bewertung der Integrationsfähigkeit teil, um Ihre Integrationsfähigkeit  in kritischen Dimensionen zu evaluieren und die Aktionen zu ermitteln, die Sie durchführen können, um  auf die nächste Stufe zu kommen.
• Laden Sie unser Handbuch für agile Integration herunter, das die Vorzüge eines containerbasierten, dezentral organisierten, auf Microservices ausgerichteten Konzepts zur Integration von Lösungen untersucht. 
• Erfahren Sie mehr über die fünf Grundvoraussetzungen für erfolgreiche Automatisierung (der Link führt zu einer Website außerhalb von ibm.com)  in diesem HFS Research-Bericht.

Machen Sie noch heute die ersten Schritte mit einem  IBM Cloudkonto.