Was ist ein ESB?

Ein Enterprise Service Bus (ESB) ist im Wesentlichen eine Architektur. Es handelt sich um eine Reihe von Regeln und Prinzipien für die gemeinsame Integration mehrerer Anwendungen über eine Bus-artige Infrastruktur. ESB-Produkte ermöglichen es Benutzern, diese Art von Architektur zu entwickeln. Die einzelnen Produkte umfassen jedoch verschiedene Methoden und Fähigkeiten. Das Hauptkonzept der ESB-Architektur besteht darin, dass Sie verschiedene Anwendungen integrieren, indem Sie einen Kommunikationsbus einsetzen und dann jede Anwendung befähigen, mit dem Bus zu kommunizieren. Auf diese Weise sind die Systeme voneinander entkoppelt. So können sie ganz ohne Abhängigkeit von oder Kenntnis der anderen an den Bus angeschlossenen Systeme miteinander kommunizieren. Das ESB-Konzept entstand aufgrund der Notwendigkeit, eine Alternative für die inflexible und auf lange Sicht schwer verwaltbare Punkt-zu-Punkt-Integration zu finden. Punkt-zu-Punkt-Integration führt dazu, dass benutzerdefinierter Integrationscode ohne Möglichkeiten zur zentralen Überwachung oder Fehlerbehebung unter Anwendungen verteilt wird. Dies wird oft als „Spaghetti-Code“ bezeichnet. Aufgrund enger Abhängigkeiten zwischen den Anwendungen sind Skalierungen nicht möglich.

Einer der häufigsten Gründe für die Implementierung eines ESB als Rückgrat der IT-Infrastruktur ist die Notwendigkeit, die Unternehmensagilität durch eine kürzere Markteinführungszeit für neue Initiativen zu steigern. Eine ESB-Architektur ermöglicht dies, da ein einfaches, gut definiertes, „zuschaltbares“ System bereitgestellt wird, das sich ausgezeichnet skalieren lässt. Darüber hinaus besteht in Verbindung mit einem ESB die Möglichkeit, Ihre vorhandenen Systeme zu nutzen und dank der Kommunikations- und Transformationsfähigkeiten für neue Anwendungen zugänglich zu machen.

Die Grundprinzipien der ESB-Architektur sind auf geschäftliche Agilität und Skalierung ausgelegt. Der Schwerpunkt liegt darauf, dass die Systeme voneinander entkoppelt werden und auf konsistente und verwaltbare Art miteinander kommunizieren können.

• Durch das „Bus“-artige Konzept werden die Anwendungen voneinander entkoppelt. Dies erfolgt in der Regel über einen Messaging-Server wie zum Beispiel JMS oder AMQP.
• Die Daten, die über den Bus übertragen werden, haben ein kanonisches Format. Dabei handelt es sich meistens um XML.
• Zwischen den Anwendungen und dem Bus befindet sich ein „Adapter“, der Daten zwischen den zwei Parteien überträgt.
• Der Adapter ist für die Kommunikation mit der Backend-Anwendung und die Umwandlung der Daten aus dem Anwendungsformat in das Bus-Format verantwortlich. Darüber hinaus kann der Adapter viele andere Aufgaben durchführen, zum Beispiel Transaktionsverwaltung beim Nachrichtenrouting, Sicherheit, Überwachung und Fehlerbehandlung.
• ESBs sind in der Regel zustandslos; der Zustand ist in den Nachrichten eingebettet, die den Bus durchlaufen.
• Das kanonische Nachrichtenformat ist der Vertrag zwischen den Systemen. Aufgrund des kanonischen Formats wird über den Bus ein einheitliches Nachrichtenformat übertragen. Daher können alle mit dem Bus verbundenen Anwendungen miteinander kommunizieren.

Schauen wir uns nun an, wie eine ESB-Architektur zu unseren fünf grundlegenden Integrationsprinzipien passt.

• Orchestrierung: Eine Reihe von granularen Komponenten wird auf höherer Ebene zu einem einzelnen Service zusammengefasst, um eine angemessene Service-Granularität zu erreichen sowie die Wiederverwendung und Handhabbarkeit der zugrunde liegenden Komponenten zu verbessern.
• Transformation: Datenumwandlung zwischen kanonischen Datenformaten und spezifischen, für die einzelnen ESB-Konnektoren erforderlichen Datenformaten. Beispiele hierfür sind die Umwandlung von CSV-, COBOL-Copybook- oder EDI-Formaten in SOAP/XML oder JSON. Kanonische Datenformate können die Transformationsanforderungen bei einer großen ESB-Implementierung mit vielen Benutzern und Anbietern, die jeweils ihre eigenen Datenformate und Definitionen aufweisen, enorm vereinfachen.
• Transport: Aushandlung von Transportprotokollen zwischen mehreren Formaten (zum Beispiel HTTP, JMS, JDBC). Hinweis: Mule behandelt Datenbanken wie einen anderen „Service“, indem JDBC zu einem weiteren Transportpunkt (oder Endpunkt) wird, an dem der Datenzugriff erfolgen kann.
• Vermittlung: Bereitstellung für mehrere Schnittstellen, um a) mehrere Versionen eines Services zur Gewährleistung von Abwärtskompatibilität zu unterstützen oder b) verschiedene Kanäle für den Zugriff auf dieselbe zugrunde liegende Komponentenimplementierung bereitzustellen. Bei der zweiten Anforderung müssen möglicherweise mehrere Schnittstellen für dieselbe Komponente bereitgestellt werden – eine Legacy-Schnittstelle (Flatfile) und eine standardkonforme Schnittstelle (SOAP/XML).
• Nicht-funktionale Konsistenz: Bei einer typischen ESB-Initiative kann dies Konsistenz bei der Implementierung und Umsetzung der Sicherheits- und Überwachungsrichtlinien umfassen. Darüber hinaus können die Skalierbarkeits- und Verfügbarkeitsziele erreicht werden, indem mehrere Instanzen eines ESB verwendet werden, um Single Points of Failure (Ausfallpunkte) zu vermeiden, denn dies ist das Hauptziel bei hochverfügbaren Systemen.

Es gibt zahlreiche ESB-Plattformen, sowohl von großen proprietären Anbietern als auch von Nischen- und Open-Source-Anbietern. Auf dem Papier haben die Plattformen viele Gemeinsamkeiten. Bei der Auswahl eines ESB sollten Sie die folgenden Punkte beachten:

Mule ist mit 40 MB bei vollem Umfang die schlankste Integrationsplattform. Das Design ist modular. Daher können Sie nicht benötigte Module entfernen, wenn Sie den Fußabdruck reduzieren möchten. Wir beziehen „Lightweight“ bzw. „schlank“ nicht nur auf die Größe, sondern berücksichtigen auch den Kosten- und Zeitaufwand, der in Verbindung mit Änderungen an vorhandenen Integrationen anfällt. Mule Runtime bietet Modularisierung und extrem schnelles Hot Deployment sowie ein Konfigurationsmodell, das die Neuanordnung und das Hinzufügen/Ändern von Funktionen vereinfacht.

Die meisten Anbieter sehen ein ESB als reinen Vermittler zwischen Systemen an. Deshalb haben sie separate Produkte für das Hosten von Geschäftslogik und Veröffentlichungsdiensten. Das finden wir unnötig komplex. Mule stellt einen schlanken und skalierbaren Service-Container für die Veröffentlichung von REST- und SOAP-Diensten bereit. Aufgrund der engen Integration von Mule in Spring können Entwickler zudem die Fähigkeiten von Spring zur Implementierung der Geschäftslogik nutzen.

Mule nutzt gängige Tools, mit denen alle Java-Entwickler vertraut sind, zum Beispiel Maven, Eclipse, JUnit und Spring. Für die Definition der Logik verwendet Mule ein XML-Konfigurationsmodell (ähnlich wie Spring). Benutzerdefinierter Code kann in verschiedenen Sprachen geschrieben werden, einschließlich Java, Groovy, JavaScript, Ruby oder Python. Darüber hinaus ermöglicht Anypoint Studio Entwicklern dank einer grafischen Entwicklungsumgebung eine schnelle Einarbeitung.

Mule wurde für die horizontale Skalierung auf Standardhardware konzipiert. Daher sind keine Großrechner erforderlich. Die Runtime von Mule lässt sich einfach in eine Anwendung einbetten. Darüber hinaus kann sie auch in Ihren Anwendungsserver, wie zum Beispiel Tomcat, JBoss oder WAS, oder direkt in Ihre Anwendung eingebettet werden. Noch wichtiger ist, dass Mule Unterstützung für JUnit bereitstellt. Daher ist eine Einbettung in einen JUnit-Testfall möglich. Dies ist eine leistungsstarke Funktion, denn so können Sie wiederholbare Unit-Tests für Integrationen erstellen, die auf einem Entwickler-Laptop ausgeführt und in einen kontinuierlichen Build einbezogen werden können.

Ein besonderes Merkmal von Mule ist der Nachrichten-agnostische Container. Das bedeutet, dass er seinen Benutzern keine XML-Nachrichten aufzwingt. XML ist zwar sehr gebräuchlich, aber in vielen Szenarien bevorzugen Entwickler JSON, Flatfiles, COBOL Copybooks, Binär- und Dateianhänge, Streams und Java-Objekte. Unser grafischer Data Mapper ist gleichermaßen nicht wählerisch bei den Daten, die zugeordnet werden können. Darüber hinaus können Entwickler dank Streaming-Funktionen von Mule große Nachrichten effizient verarbeiten.

Sie überlassen die Anwendungsarchitektur, das Hosting und die Überwachung Ihrer Integration lieber den Integrationsexperten? Dann ist CloudHub™ für Sie genau richtig. CloudHub ist eine Integration Platform as a Service (iPaaS), mit der Sie in wenigen Minuten startklar sind. CloudHub bietet eine Multi-mandantenfähige und elastische Plattform mit Konnektivität zu über 150 SaaS-, Social-Media- und Infrastrukturdiensten. Außerdem können Sie CloudHub mit Ihren lokalen Anwendungen verbinden. CloudHub-Anwendungen werden über Mule ausgeführt und umgekehrt. Somit müssen Sie keine neuen Konzepte lernen, denn die Entwicklererfahrung ist identisch, unabhängig davon, ob Sie lokal oder in der Cloud implementieren. Mit anderen Worten: Der Einarbeitungsaufwand ist gleich null.

Die meisten Unternehmen möchten ihre Agilität steigern, indem sie durch kürzere Markteinführungszeiten mehr Zeit für neue Initiativen gewinnen. ESBs unterstützen dieses Ziel durch die Implementierung eines einfachen, gut definierten, zuschaltbaren Systems mit hoher Skalierbarkeit. Wir bei MuleSoft verstehen, dass eine ESB-Architektur eben eine Architektur ist und nicht lediglich ein Produkt, das Sie von der Stange kaufen können. Eine ESB-Architektur umfasst nicht nur eine Infrastruktur, sondern auch das Anwendungsdesign.Entdecken Sie die flexibelste ESB-Lösung der Welt: Mule, die Runtime Engine der Anypoint Platform. Erfahren Sie mehr darüber, wie Mule Unternehmen dabei helfen kann, eine auf Agilität und Geschwindigkeit basierende Architektur zu entwickeln.