Mit EAI auf kritische Ereignisse reagieren

Zwei Architekturen für Integrationsplattformen

von - 01.09.2015
Integrationsplattformen lassen sich prinzipiell auf zwei Arten installieren. Die klassische ist die „Nabe-Speiche“-Architektur, Hub and Spoke genannt. Wie beim namensgebenden Rad sitzt die Integrationsanwendung in der Mitte. Alle Applikationen sind über Schnittstellen, die Adapter, an die Zentrale, den Message Broker, angebunden. Dieser verteilt die Daten und Prozesse zwischen den beteiligten Programmen, indem er die Informationen der Quellapplikation in das Format der Zielapplikation umwandelt. Solche Systeme sind leicht zu verwalten. Kommt eine Applikation hinzu, benötigt man nur einen neuen Adapter, bei Updates oder neuen Versionen muss ebenfalls nur ein Adapter aktualisiert werden.
Bei einer Hub-and-Spoke-Architektur sorgt eine zentrale Einheit für die Integration von Applikationen. Bei einer Bus-Architektur dient der Message-Bus nur der Informationsübermittlung, die Integrationsintelligenz ist in die Adapter verteilt.
Bus oder Hub and Spoke: Bei einer Hub-and-Spoke-Architektur sorgt eine zentrale Einheit für die Integration von Applikationen. Bei einer Bus-Architektur dient der Message-Bus nur der Informationsübermittlung, die Integrationsintelligenz ist in die Adapter verteilt.
Durch die zentralisierte Architektur lässt sich das System aber nur schwer skalieren und stellt außerdem einen neural­gischen Punkt für die Ausfallsicherheit der gesamten In­frastruktur dar. Sollte der Message Broker seinen Dienst quittieren, ist schließlich keine Kommunikation zwischen den Applikationen mehr möglich. Abhilfe schafft bis zu einem gewissen Grad ein verteiltes System mit mehreren parallel betriebenen Zentraleinheiten und einem Management. das die Infrastruktur verwaltet. So ein System lässt sich aber nur in groben Schritten skalieren. Man muss immer einen zusätzlichen Message Broker installieren, wenn man mehr Leistung braucht.
Wesentlich flexibler ist das Bus-System. Es besteht aus einer Vermittlungsschicht, dem Messaging Backbone, und Adaptern, die eigenständig die Übersetzung der Daten übernehmen. Mittlerweile kommt fast nur noch eine standardisierte Bus-System-Variante zum Einsatz, die als Enterprise Service Bus (ESB) bezeichnet wird. Diese Architektur wird noch oft eingesetzt, sagt Martin Wroblinski von der Software AG: „In vielen Fällen wird der klassische ESB verwendet, um bestehende Systeme service- beziehungsweise microservicefähig zu machen und homogen in eine moderne Architektur einzubinden.“

Das SOA-Konzept

Die Fähigkeit, IT-Komponenten zu kapseln und als Service standardisiert und plattformunabhängig anzubieten, hat das SOA-Konzept so erfolgreich gemacht. Die Dienste werden häufig als Webservices über Protokolle wie SOAP, REST oder XML-RPC angeboten. SOA wird oft als Allheilmittel für alle Inte­grationsprobleme angepriesen – zu Unrecht, wie Markus Eisele von Red Hat meint: „Wir haben alle schmerzhaft gelernt, dass man nicht überall SOA aus dem Lehrbuch anwenden kann.“ Es seien viele organisatorische Schritte notwendig, um SOA zum Erfolg zu führen, so Eisele weiter, „das lohnt sich für viele Unternehmen einfach nicht“. Viele Applikationen seien zudem unterm Schreibtisch entstanden, skaliert worden und irgendwann in den unternehmensweiten Produktiveinsatz gelangt, „da hat sich beim Design sicher keiner Gedanken um SOA gemacht“.
Laut Eisele könnte ein Refactoring hin zu Microservices diesem Dilemma abhelfen. Das Microservice-Konzept bringt das Service-Paradigma in die Applikationen. Statt aus großen Programmblöcken wie einer Server-Komponente, einer Datenbank und einer Bedienoberfläche bestehen microservicebasierte Anwendungen aus kleinen Einheiten, die separat ausgeliefert werden können und die untereinander über Standardprotokolle wie HTTP kommunizieren. Bei einem Update muss nur der betroffene Service aktualisiert werden, nicht die komplette Applikation. Der Ansatz hat viele Vorteile, macht aber die Kommunikation zwischen Systemen noch komplexer, da nun nicht nur ein Service nach außen kommuniziert, sondern viele kleine Dienste intern und extern Schnittstellen verursachen.
Verwandte Themen