Serie „Integrationsarchitektur“ – Teil 1 Architektur

Enterprise Integration ist anders. Es unterscheidet sich in vielen Punkten von der Entwicklung einer Anwendung z.B. in Form eines Produkts. Die Entwicklungstätigkeit an sich ist vergleichbar einfach, die Herausforderungen liegen in der hohen Anzahl und großen Heterogenität der beteiligten Personen und sind so vielfältig wie das Unternehmen selbst.

In dieser Blog Serie möchte ich einige der wichtigsten Themen und Fragestellungen rund um Enterprise Integration betrachten. Angefangen bei sehr abstrakten Fragestellungen führe ich zu immer konkreteren Beispielen, die dann mit unterschiedlichen ESB Technologien beispielhaft umgesetzt werden.

Ich möchte diese Serie mit einem Zitat aus dem Buch „Enterprise Integration Patterns“ beginnen:

„There are no simple answers for enterprise integration“

So einfach diese Aussage auch ist, so viel Wahrheit steckt in ihr. Allerdings ist das kein Grund, sich vor Enterprise Integration zu drücken. Suchen wir lieber Mittel und Wege, die Komplexität und Schwierigkeit zu beherrschen. Ein wichtiges Werkzeug hierzu ist „Abstraktion“. Daher beginne ich diese Serie auf einer möglichst abstrakten Ebene: Der Gesamtarchitektur. Wir werden bald sehen: Auf dieser Ebene sehen die Probleme ganz klein und Enterprise Integration ganz einfach aus. Ein Blick auf eine höhere Abstraktionsebene wird uns außerdem immer wieder helfen, den Kopf im Integrationschaos nicht zu verlieren und uns nicht in Details zu verlieren.

Beginnen wir – ganz abstrakt – mit dem Kernproblem der Softwareintegration: Eine Anwendung (A) besitzt Daten, die einer anderen Anwendung (X) bereitgestellt werden müssen. Weder die Betreuer von Anwendung A, noch die von Anwendung X haben hierbei ein Interesse daran, ihre Anwendung auf die Bedürfnisse der anderen anzupassen.

Dieses Problem lässt sich zunächst nach einem sehr einfachen Muster lösen:

Abbildung 1 Point-to-Point Kommunikation zwischen zwei Anwendungen

Nehmen wir zur Veranschaulichung an, A stellt die Daten als XML über JDBC bereit, und Anwendung X möchte die Daten als CSV-Datei per FTP erhalten. Da weder A noch X bereit sind, Anpassungen vorzunehmen, führen wir einen Transformator ein, der die Daten von Anwendung A entgegennimmt und in ein Format umwandelt, dass auch Anwendung X versteht.
Dieses Prinzip wird (auch wenn die Kommunikation über einen Transformator läuft) „Point-to-Point“ genannt und ist das wohl einfachste Kommunikationsmuster, dass die Integrationswelt zu bieten hat. Dieses Beispiel offenbart zwei Grundbedingungen, die für eine Kommunikation zwingend erforderlich sind und die bei jeder Kommunikation berücksichtigt werden müssen:

• Die Auswahl des Datenformats
• Die Auswahl des Transportkanals

Wird eine der Bedingungen nicht erfüllt, kann keine Kommunikation zustande kommen. Nehmen wir nun an, Die Daten von Anwendung A werden von zwei weiteren Anwendungen – Y und Z – benötigt, so kommen wir zu folgendem Aufbau:

Abbildung 2 Netz aus Point-to-Point Kommunikation

Wenden wir das gleiche Muster an, so führt das zu drei Transformatoren, die alle XML/JDBC entgegennehmen und in das jeweilige Zielformat der Anwendungen X, Y und Z umwandeln. Beide Bedingungen (Datenformat und Protokoll) sind erfüllt, die Kommunikation funktioniert.

Doch was passiert, wenn Anwendung A nun durch ein neues System abgelöst wird, welches die Daten anstelle von XML/JDBC nun plötzlich als JSON-Objekt über HTTP bereitstellt? In diesem Fall funktioniert die Kommunikation erst wieder, wenn wir zusätzlich zur Anwendung A die Transformatoren A->X, A->Y und A->Z angepasst haben. Alle müssen nun anstelle des XML-Dokuments ein JSON-Objekt über einen neuen Kanal einlesen und verarbeiten. In Summe bedeutet das: Es müssen Alle mit A verbundenen Transformatoren angepasst werden.

Diese Menge kann den Wartungsaufwand enorm in die Höhe treiben. Um sie zu reduzieren führen wir ein gemeinsames Datenmodell und einen gemeinsamen Transportkanal ein (wir nennen das ganze „M“), in unserem Beispiel CSV über FTP.

Abbildung 3 Einführung eines gemeinsamen Datenmodells sowie Transportkanals

Der Unterschied ist nun, dass für jede Anwendung ein eigener, nur für diese Anwendung zuständiger Transformator existiert, der die Übersetzung in das gemeinsame Datenmodell und den Transportkanal übernimmt. Dies funktioniert im Übrigen in beide Richtungen, also auch „rückwärts“, z.B. von Anwendung X nach A.

Wie würde sich ein Austausch von Anwendung A jetzt auswirken? Es müsste nur noch der dazugehörige Transformator (A->M) angepasst werden und die Kommunikation würde wieder funktionieren. Eine erhebliche Verbesserung! Dieses Prinzip der losen Kopplung ist eines der wichtigsten in der Anwendungsintegration und wird uns an vielen Stellen und auf unterschiedlichen Ebenen begegnen.

Oftmals sollen gleiche Daten einer Anwendung nicht nur einer sondern mehreren anderen Anwendungen bereitgestellt werden, z.B. wenn mehrere Anwendungen über neue Wechselkurse oder Änderungen an Kundendaten informiert werden sollen. Allerdings soll nicht die Quell-Anwendung entscheiden, wohin die Daten weitergeleitet werden. In anderen Fällen möchte man die Daten mit Informationen aus weiteren Anwendungen anreichern, bevor sie an die Zielanwendung weitergeleitet werden. Für diese Fälle lohnt sich die Einführung eines Vermittlers, der genau diese Aufgaben übernimmt:

Abbildung 4 Einführung eines Vermittlers

Dieser Vermittler kann nun zusätzlich zur normalen Kommunikation erweiterte Funktionen bereitstellen, ohne dass die beteiligten Anwendungen dies bemerken oder sich hierum kümmern müssten. Außerdem können wir den Vermittler als zusätzliche Entkopplung einsetzen und die Kommunikation gezielt bündeln. Da rund um den Vermittler gemeinsames Datenmodell („M“) gesprochen wird können angebundene Anwendung ausgetauscht und Aufrufe umgeleitet werden.

Um diese Vorteile langfristig zu erhalten, wollen wir unbedingt vermeiden, dass Anwendungen am Vermittler vorbei direkt miteinander kommunizieren. Hierzu nutzen wir ein bekanntes Architekturkonzept: Wir führen Layer ein:

Abbildung 6 Unterbinden von Point-to-Point Kommunikation durch Layer

Wir definieren, dass Anwendungen nun nur noch mit dem jeweils benachbarten Layer und nicht mehr untereinander kommunizieren dürfen und erhalten sauber getrennte Layer. Grundvoraussetzung hierbei ist, dass die Kommunikation zwischen den Layern über klar definierte Schnittstellen erfolgt.

Schon zu Beginn haben wir hingenommen, dass die Entwickler der einzelnen Anwendungen kein Interesse daran haben, Transformationslogik zu implementieren. Mit den Layern haben wir diesem Umstand Rechnung getragen, und können den Anwendungsentwicklern nach außen nun ein tolles Angebot machen: Wir binden jede beliebige Anwendung an und richten uns dabei nach ihren Wünschen. Die meisten Anpassungen können wir dann in unserem Transformator abfangen. Sie müssen weder unsere Plattform kennen noch Integrations-Know-How mitbringen, denn beides bringen wir mit.

Wir haben nun eine Architektur entwickelt, die uns ein hohes Maß an Flexibilität und eine lose Kopplung bietet. Außerdem schielen wir mit dieser Architektur auch in die Zukunft, nämlich in Richtung SOA. Durch die klar definierten Schnittstellen zwischen den Layern ist es uns möglich, in Zukunft einen vierten Layer über unserem Vermittler-Layer zu bedienen. Hier finden wir für gewöhnlich einen BPM Layer, der über die von uns bereitgestellten Schnittstellen ohne feste Kopplung auf den Anwendungs-Layer zugreifen kann.

Wie geht es nun weiter? In den nächsten Artikeln lösen wir uns Schritt für Schritt von der Architektur hin zur konkreten Umsetzung der Architektur mit verschiedenen Technologien. Im nächsten Artikel geht es daher um die beiden zentralen Grundbedingungen der Kommunikation: Das Datenformat und den Transportkanal, und damit auch um die Schnittstellen zwischen unseren Layern, die wir später implementieren und verwenden werden.

Zu Teil 2 der Serie