EAI Enterprise Application Integration - Warum Anwendungsintegrationen (UAI) für erfolgreiche Unternehmensarchitekturen hoch relevant sind

In modernen Unternehmensarchitekturen und -infrastrukturen ist Systemintegration und Anwendungsintegration in zunehmenden Maße ein erfolgskritisches Anliegen.Dies zeigt sich unter anderem auch daran, dass es eine Vielzahl von Herangehensweisen und Vorstellungen für die Umsetzung für Enterprise Application Integrations (EAI) gibt.Wenn Sie als Unternehmen beginnen, Ihre ersten Nachforschungen hinsichtlich EAI / UAI und Systemintegrations- / Datenintegrationslösungen anzustellen, kann es leicht passieren, dass Sie vor lauter Akronymen, Meinungen und verwirrendem Marketingjargon den Wald vor lauter Bäumen nicht sehen. MuleSoft erklärt Ihnen die Bedeutung von Application Integration / Anwendungsintegration für Ihr Unternehmen und hilft Ihnen zu verstehen, welche Vorteile Ihnen ein ESB Enterprise Service Bus dabei bieten kann.

Um der steigenden Nachfrage nach Integration von Anwendungen im Unternehmen nachzukommen, gibt es rasante Fortschritte bei der EAI-Technologie. Dabei wird oft über die folgenden Fragen diskutiert: Was ist EAI überhaupt beziehungsweise was ist EAI nicht? Und inwiefern bedeuten die kleinen Unterschiede zwischen verschiedenen proprietären Ansätzen, dass es sich bei Enterprise Application Integration um die einzige brauchbare Systemintegrations-Lösung handelt?

In diesem Artikel beseitigen wir alle Unklarheiten mit einem leicht verständlichen, klar strukturierten Überblick über die Entwicklung von EAI Enterprise Application Integration / UAI Unternehmens-Anwendungsintegration.

Zunächst gehen wir kurz auf die Ursprünge von EAI Systemen ein. Danach stellen wir alle Hauptentwicklungen in der EAI-Architektur vor und erklären, wie herkömmliche Broker-basierte „Hub-and-Spoke“-EAI-Systeme jetzt durch agile, verteilte, standardbasierte Enterprise Service Bus (ESB) Architekturen ersetzt werden.

I. Die Ursprünge von EAI Enterprise Application Integration / UAI Unternehmens-Anwendungsintegration

A. Wenn Punkt-zu-Punkt-Integration nicht ausreicht

B. Der EAI-Ansatz

II. Herkömmliche EAI Enterprise Application Integration / Anwendungsintegration

A. Das Broker-Modell in der EAI

B. Vorteile von EAI Enterprise Application Integration / Anwendungsintegration

C. Nachteile von EAI Enterprise Application Integration / Anwendungsintegration

III. ESB Enterprise Service Bus – die Weiterentwicklung der EAI durch Bus-Architekturen

A. Hauptmerkmale

B. Vorteile

C. Wann ist ein ESB nützlich?In diesem Artikel beseitigen wir alle Unklarheiten mit einem leicht verständlichen, klar strukturierten Überblick über die Entwicklung von EAI Enterprise Application Integration / UAI Unternehmens-Anwendungsintegration.

Der technische Begriff Enterprise Application Integration oder kurz EAI wurde zu Beginn des 21. Jahrhunderts geprägt. Das zentrale Problem, das durch EAI gelöst werden soll, ist jedoch sehr viel älter.Generell handelt es sich bei EAI um einen Ansatz oder, genauer gesagt, um eine allgemeine Kategorie von Ansätzen für die Bereitstellung von Interoperabilität zwischen den zahlreichen verteilten Systemen einer typischen Unternehmensinfrastruktur.

Unternehmensarchitekturen umfassen in der Regel viele Systeme und Anwendungen, welche die verschiedenen, für die alltäglichen Abläufe im Unternehmen unverzichtbaren Dienste bereitstellen. Zur Verwaltung von Lieferketten, Kundenbeziehungen, Mitarbeiterinformationen und Geschäftslogik nutzt ein Unternehmen möglicherweise separate Systeme, die entweder intern entwickelt oder von einem Drittanbieter lizenziert sind. Diese Modularisierung ist oft wünschenswert. Theoretisch ist es sinnvoll, die betrieblichen Aufgaben in mehrere kleinere Funktionen zu untergliedern, um in jedem Bereich die besten und neuesten technologischen Fortschritte einfach einzusetzen und sich schnell an veränderte Geschäftsanforderungen anzupassen.

Um jedoch von den Vorteilen eines solchen verteilten, modularen Systems zu profitieren, müssen Unternehmen Technologien implementieren, welche die mit dieser Architektur verbundenen Probleme beheben:

• Interoperabilität: Die verschiedenen Komponenten der Infrastruktur verwenden möglicherweise unterschiedliche Betriebssysteme, Datenformate und Sprachen. Daher ist es nicht möglich, sie über eine standardmäßige Schnittstelle miteinander zu verbinden.
• Datenintegration: Eine wichtige Voraussetzung für die Funktionsfähigkeit eines modularen, verteilten Systems ist eine standardmäßige Methode für die Abwicklung des Datenflusses zwischen Anwendungen und Systemen. Nur so können Sie in der gesamten Datenbank für Konsistenz sorgen.
• Robustheit, Stabilität und Skalierbarkeit: Da Integrationslösungen eine modulare Infrastruktur zusammenhalten, müssen sie hochgradig robust, stabil und skalierbar sein.

Vor der Entwicklung von EAI-Ansätzen wurden Integrationsprobleme hauptsächlich durch Punkt-zu-Punkt-Integrationen gelöst. Bei einem Punkt-zu-Punkt-Integrationsmodell wird für jedes Paar von Anwendungen oder Systemen, die miteinander kommunizieren müssen, eine einzigartige Konnektorkomponente implementiert. Über diesen Konnektor werden alle Datenumwandlungs- und -integrationsaufgaben sowie alle anderen Messaging-Dienste abgewickelt, die nur zwischen dem spezifischen zu integrierenden Komponentenpaar stattfinden müssen.

In kleinen Infrastrukturen, bei denen nur zwei oder drei Systeme integriert werden müssen, kann dieses Modell durchaus gut funktionieren. Es stellt eine schlanke, auf die Anforderungen der Infrastruktur zugeschnittene Integrationslösung bereit. Wenn jedoch zusätzliche Komponenten zu einer Infrastruktur hinzugefügt werden, nimmt die Anzahl der zum Erstellen einer umfassenden Integrationsarchitektur erforderlichen Punkt-zu-Punkt-Verbindungen exponentiell zu.

Eine aus drei Komponenten bestehende Infrastruktur gilt als vollständig integriert, wenn nur drei Punkt-zu-Punkt-Verbindungen vorhanden sind. Werden nur zwei weitere Komponenten hinzugefügt, steigt diese Zahl auf 10 Konnektoren an. Dadurch entsteht bereits eine unüberschaubare Komplexität. Wenn eine Infrastruktur 8 oder 9 Komponentensysteme umfasst, steigt die Anzahl der Verbindungen schnell auf über 30 an. Punkt-zu-Punkt-Integration kommt dann nicht mehr in Frage.

Jeder dieser Konnektoren muss separat entwickelt und entsprechend verschiedener Änderungen wie zum Beispiel Systemversionen und Skalierbarkeit gepflegt werden. (In einigen Fällen ist es sogar notwendig, einzelne Konnektoren zu ersetzen und zu einem hohen Preis von einem externen Anbieter zu kaufen.) Wenn Sie dies bedenken, wird erschreckend deutlich, dass Punkt-zu-Punkt-Integration für komplexe Unternehmensszenarios absolut ungeeignet ist.

EAI-Lösungen umgehen die Komplexität und Fehleranfälligkeit, die ein Punkt-zu-Punkt-Ansatz bei der Integration komplexer Infrastrukturen mit sich bringt. Mithilfe verschiedener Middleware-Modelle zentralisieren und standardisieren sie Integrationspraktiken über eine gesamte Infrastruktur hinweg.

In einer EAI-basierten Infrastruktur ist es nicht notwendig, dass ein separater Konnektor für jede Anwendung eine Verbindung zu einem anderen Konnektor herstellt. Stattdessen werden standardisierte Methoden für die Verbindung zu einem gemeinsamen System verwendet, das für die Bereitstellung von Integration, Message-Brokering und Zuverlässigkeitsfunktionen im gesamten Netzwerk verantwortlich ist.

EAI löst das Problem der Integration modularer Systeme, indem Integration als reguläre Systemaufgabe behandelt wird, und räumt mit dem Wirrwarr inflexibler Verbindungen auf. In EAI-Systemen werden verschiedene Komponenten gebündelt: Adapter für Konnektivität; Engines für die Datenumwandlung, um Daten in das richtige Format für die Nutzung von Endnutzern zu konvertieren; Engines für die modulare Integration, um viele verschiedene komplexe Routing-Szenarien gleichzeitig zu bewältigen. So entsteht eine einheitliche Integrationslösung.

EAI lockert die eng gekoppelten Verbindungen der Punkt-zu-Punkt-Integrationen. Eine Anwendung kann eine Nachricht senden, ohne den Standort des Verbrauchers, die Datenanforderungen oder den Zweck der Nachricht zu kennen. All diese Informationen können über die EAI-Implementierung abgewickelt werden. So entsteht eine Grundlage für eine flexiblere Architektur, in der neue Teile nach Bedarf hinzugefügt oder entfernt werden können. Dazu muss lediglich die Konfiguration des EAI-Providers geändert werden. Außerdem wird eine vereinfachte modulare Entwicklung ermöglicht, wobei ein einziger Service von mehreren Anwendungen wiederverwendet werden kann.

Viele moderne EAI-Ansätze nutzen auch die Möglichkeiten, die durch das Hinzufügen eines zentralen Integrationsmechanismus entstehen, um Messaging-Aufgaben weiter zu konsolidieren. Abgesehen von Datenintegration kann eine moderne EAI auch Funktionen wie Netzwerkadministration, Sicherheit, Beschleunigung und Skalierbarkeit umfassen.

Die ersten EAI-Lösungen auf dem Markt nahmen die Idee der Vereinigung von Integrationen recht wörtlich: Sie nahmen alle für die Integration erforderlichen Funktionen in zentrale Hubs namens Broker auf.

In diesem Abschnitt stellen wir die Vor- und Nachteile dieses Modells vor. Darüber hinaus erfahren Sie, warum dieses Modell durch eine ESB-Architektur ersetzt wurde.

Bei einem Broker-Ansatz in Verbindung mit EAI befindet sich eine zentrale Integrationsengine („Broker“) im Zentrum des Netzwerks. Diese Engine stellt alle Funktionen für die Nachrichtenumwandlung und das Routing sowie alle anderen Funktionen bereit, die für die Zusammenarbeit zwischen den Anwendungen erforderlich sind. Alle Kommunikationen zwischen Anwendungen müssen durch diesen zentralen Knoten fließen, damit dieser Knoten die Datenparallelität für das gesamte Netzwerk aufrechterhalten kann.

In der Regel umfassen Implementierungen des Broker-Modells auch Überwachungs- und Audit-Tools, die Benutzern den Zugriff auf Informationen über den Nachrichtenfluss in ihren Systemen ermöglichen. Darüber hinaus beinhalten sie oft Tools für die Beschleunigung der komplizierten Aufgabe, das Mapping und Routing zwischen einer großen Anzahl von Systemen und Anwendungen zu konfigurieren.

Wie alle EAI-Integrationsansätze ermöglicht das Broker-Modell eine lose Kopplung zwischen Anwendungen.

Das bedeutet, dass Anwendungen asynchron kommunizieren können. Sie können also Nachrichten senden und ihre Arbeit fortsetzen, ohne auf eine Antwort vom Empfänger zu warten. Dabei wissen sie genau, wie die Nachricht an den Endpunkt gelangt. In einigen Fällen ist ihnen sogar der Endpunkt der Nachricht bekannt.

Bei einem Broker-Ansatz ist es zudem möglich, die gesamte Integrationskonfiguration in einem zentralen Repository auszuführen. Dadurch wird der Konfigurationsaufwand reduziert.

Wie bei jedem anderen Architekturmodell, das eine zentrale Engine verwendet, kann der Broker für das Netzwerk zu einem Single Point of Failure werden. Da der Broker für die gesamte Parallelität zwischen Datensätzen und -zuständen der Anwendungen verantwortlich ist, müssen alle Nachrichten zwischen Anwendungen über den Broker laufen.

Bei einer hohen Auslastung kann der Broker Engpässe für Nachrichten verursachen. Wenn nur ein einziges zentrales Ziel für alle Nachrichten vorhanden ist, kann es mitunter schwierig sein, das Broker-Modell über große Entfernungen hinweg erfolgreich zu nutzen.

Darüber hinaus handelt es sich bei Implementierungen des Broker-Modells oft um aufwendige, proprietäre Produkte, die auf bestimmte Technologien eines spezifischen Anbieters ausgerichtet sind. Dies kann problematisch sein, wenn Ihr Integrationsszenario Produkte von verschiedenen Anbietern, intern entwickelte Systeme oder gar Legacy-Produkte umfasst, die vom Anbieter nicht mehr unterstützt werden.

Das EAI-Broker-Modell wurde von einigen Unternehmen erfolgreich implementiert. Allerdings sind die meisten auf diesem Modell basierenden Integrationsprojekte letztendlich fehlgeschlagen. Der Mangel an eindeutigen Standards für die EAI-Architektur und die Tatsache, dass die meisten frühen Lösungen proprietär waren, brachten einen hohen Arbeits- und Kostenaufwand mit sich. Außerdem funktionierten sie bei Systemen, die nicht ohnehin bereits weitgehend homogen waren, nicht immer erwartungsgemäß.

Verschärft wurden die Auswirkungen dieser Probleme dadurch, dass das EAI-System durch das Broker-Modell zu einem Single Point of Failure für das Netzwerk wurde. Eine fehlerhafte Komponente bedeutete den Totalausfall des gesamten Netzwerks. Nach Schätzungen einer Studie aus dem Jahr 2003 sind aufgrund der Mängel in frühen Broker-Lösungen sage und schreibe 70 Prozent aller Integrationsprojekte letztendlich fehlgeschlagen.

Um die mit dem Broker-basierten „Hub-and-Spoke“-Ansatz einhergehenden Probleme zu überwinden, entstand ein neues EAI-Modell – der Bus. Zwar wurden bei der Bus-Architektur Nachrichten weiterhin über eine zentrale Routing-Komponente von System zu System übertragen. Das Ziel der Bus-Architektur bestand jedoch darin, die auf einer einzigen Komponente liegende Funktionslast zu reduzieren, indem einige der Integrationsaufgaben auf andere Teile des Netzwerks verteilt wurden.

Diese Komponenten konnten dann in verschiedenen Konfigurationen über Konfigurationsdateien gruppiert werden, um alle Integrationsszenarien auf möglichst effiziente Weise zu bewältigen. Darüber hinaus konnten sie überall in der Infrastruktur gehostet oder zwecks Skalierbarkeit über große Entfernungen hinweg dupliziert werden.

Während der Entwicklung von Bus-basierter EAI wurden mehrere andere erforderliche Funktionen identifiziert, wie zum Beispiel Sicherheitstransaktionsabwicklung und Fehlerbehebung. Diese Funktionen mussten nicht in die zentrale Integrationslogik eingebettet werden, wie es in einer Broker-Architektur erforderlich gewesen wäre. In der Bus-Architektur konnten diese Funktionen in separaten Komponenten beigefügt werden.

Das Endergebnis: Schlanke, maßgeschneiderte Integrationslösungen mit garantierter Zuverlässigkeit, die vollständig von der Anwendungsebene abstrahiert sind, auf einem konsistenten Muster basieren und ohne Änderung an den zu integrierenden Systemen mit minimalem zusätzlichen Code entwickelt und konfiguriert werden können.

Diese ausgereifte Version des Bus-basierten EAI-Modells ist der Enterprise Service Bus oder kurz ESB.

Heute sind verschiedene ESB-Produkte erhältlich. Bei einigen handelt es sich um herkömmliche EAI-Produkte, die refaktorisiert wurden, um ESB-artige Funktionen anzubieten, aber dennoch nach dem Broker-Modell funktionieren. Beispiele hierfür sind WebSphere Message Broker oder TIBCO BusinessWorks.

Andere Produkte wie Mule als ESB von MuleSoft wurden zur Umsetzung des ESB-Modells mit offenen Messaging- und Integrationsstandards von Grund auf neu entwickelt.

Es gibt viele verschiedene Arten von ESBs, doch die meisten weisen die folgenden Hauptfunktionen oder „Dienste“ auf:

• Standorttransparenz: Eine Möglichkeit für die zentrale Konfiguration von Endpunkten für Nachrichten, sodass eine Verbraucheranwendung zum Nachrichtenempfang keine Informationen über den Nachrichtenersteller benötigt.
• Umwandlung: Die Fähigkeit des ESB, Nachrichten in ein von der Verbraucheranwendung nutzbares Format zu konvertieren.
• Protokollkonvertierung: Ähnlich wie bei der Umwandlungsanforderung muss der ESB in der Lage sein, Nachrichten zu empfangen, die in allen allgemein üblichen Protokollen gesendet wurden, und diese in das für den Endnutzer erforderliche Format zu konvertieren.
• Routing: Die Fähigkeit, basierend auf vorkonfigurierten Regeln und dynamisch erstellten Anfragen die richtigen Verbraucher zu ermitteln.
• Verbesserung: Die Fähigkeit, basierend auf vorhandenen Nachrichtendaten in eingehenden Nachrichten fehlende Daten abzurufen und diese vor der endgültigen Zustellung an die Nachricht anzuhängen.
• Überwachung/Verwaltung: Der ESB soll die Aufgabe der Integration vereinfachen. Dazu muss ein ESB eine einfache Methode für die Überwachung der Systemleistung, den Nachrichtenfluss in der ESB-Architektur sowie die Verwaltung des Systems bereitstellen, damit das Leistungsversprechen in der Infrastruktur eingehalten wird.
• Sicherheit: ESB-Sicherheit umfasst zwei Hauptkomponenten – der ESB muss Nachrichten auf vollkommen sichere Art verarbeiten und die von den zu integrierenden Systemen verwendeten Sicherheitssysteme aufeinander abstimmen.

Der ESB-Ansatz für die Anwendungsintegration bietet die folgenden Vorteile:

• Lightweight: Da ein ESB aus vielen Diensten besteht, die miteinander zusammenarbeiten, und nicht aus einem einzigen Hub, der alle nur denkbaren Dienste enthält, können ESB-Architekturen je nach Anforderungen des Unternehmens beliebig umfangreich oder schlank sein. Daher handelt es sich um die effizienteste Integrationslösung auf dem Markt.
• Leicht erweiterbar: Wenn Unternehmen wissen, dass sie in Zukunft weitere Anwendungen oder Systeme zur Architektur hinzufügen müssen, können sie ihre Systeme in einem ESB-Szenario sofort integrieren. So müssen sie sich keine Gedanken darüber machen, ob ein neues System in ihrer vorhandenen Infrastruktur funktioniert oder nicht. Wenn die neue Anwendung bereit ist, müssen sie sie lediglich mit dem Bus verbinden, um eine Zusammenarbeit mit dem Rest der Infrastruktur zu ermöglichen.
• Skalierbar und verteilbar: Anders als bei Broker-Architekturen können ESB-Funktionen ganz nach Bedarf mühelos über geografisch verteilte Netzwerke hinweg zusammengeführt werden. Da für die Bereitstellung jeder Funktion einzelne Komponenten verwendet werden, kann hohe Verfügbarkeit und Skalierbarkeit für kritische Teile der Architektur bei Verwendung einer ESB-Lösung außerdem sehr viel einfacher und kostengünstiger sichergestellt werden.
• SOA-freundlich: ESBs sind auf eine serviceorientierte Architektur ausgerichtet. Daher können Unternehmen, die eine SOA-Migration anstreben, dies schrittweise durchführen. Sie können ihre vorhandenen Systeme weiterhin nutzen, während sie wiederverwendbare Dienste bei ihrer Implementierung eingliedern.
• Schrittweise Einführung: Auf den ersten Blick kann die große Anzahl von Funktionen der besten ESBs ein wenig überwältigend sein. Man sollte den ESB jedoch am besten als „Integrationsplattform“ ansehen, auf der Sie nur die Komponenten verwenden müssen, die Ihren aktuellen Integrationsanforderungen entsprechen. Die große Anzahl modularer Komponenten bietet beispiellose Flexibilität. Sie ermöglicht eine schrittweise Einführung einer Integrationsarchitektur, sobald Ressourcen verfügbar werden. Gleichzeitig wird hierdurch garantiert, dass unerwartete zukünftige Anforderungen den ROI nicht beeinträchtigen.

Alle Integrationslösungen haben Stärken und Schwächen, die oft durch die Implementierungsumgebung bestimmt werden. Aus diesem Grund kann Ihre Integrationsstrategie nur erfolgreich sein, wenn Sie fundierte Entscheidungen bezüglich Ihrer EAI-Strategie treffen.

Damit Ihre EAI- und SOA-Bemühungen erfolgreich sind, reicht die „beste“ Technologie allein nicht aus. Ganz wichtig sind auch die folgenden Überlegungen: der beabsichtigte Verwendungszweck des Produkts, die Leistungsfähigkeit bei hoher Beanspruchung, der Reifegrad und ein tiefgreifendes Verständnis der aktuellen und zukünftigen Integrationsherausforderungen in Ihrem Unternehmen.

Bevor Sie eine Entscheidung bezüglich EAI treffen, sollten Sie sich Gedanken darüber machen, wie Sie folgende Fragen beantworten würden:

• Wie viele Anwendungen müssen integriert werden?
• Werden Sie in Zukunft weitere Anwendungen hinzufügen müssen?
• Wie viele Kommunikationsprotokolle sind erforderlich?
• Beinhalten die Integrationsanforderungen Routing, Gabelung oder Zusammenführung?
• Wie wichtig ist Skalierbarkeit für Ihr Unternehmen?
• Erfordert Ihre Integrationssituation asynchrones Messaging, Publish-/Consume-Messaging-Modelle oder andere komplexe Messaging-Szenarien, die aus mehreren Anwendungen bestehen?

Ross Mason, Gründer von MuleSoft und ursprünglicher Architekt von Mule als ESB, gibt in einem Artikel mit dem Titel „To ESB or Not To ESB“ eine gute Einführung für Unternehmen, die einen ESB-Integrationsansatz in Betracht ziehen. Der Artikel umfasst eine erweiterte Version der obigen Checkliste, anhand derer Sie entscheiden können, ob ESB für Ihre Integrationsanforderungen geeignet ist.