Serie „Integrationsarchitektur“ – Teil 1 Architektur

5 Kommentare

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

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

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

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

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

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

Tobias Schaber

Neben seinem Schwerpunkt „Verteilte Systeme“ beschäftigt sich Tobias Schaber mit den Themen DevOps und Infrastructure-As-Code und automatisiert zum Beispiel die Bereitstellung von komplexen Systemen wie OpenStack oder Elasticsearch-Clustern.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Johannes Stelzer

    20. Oktober 2014 von Johannes Stelzer

    Hi Tobi,

    imho ist es sehr schwer ein gemeinsames Datenmodell zu finden, dass für alle beteiligten Anwendungen passt, gerade wenn Standardsoftware verschiedener Hersteller eingesetzt werden, da die Sicht und die Anforderungen sehr unterschiedlich sind.
    Dazu kommen noch unbekannte Changes und Anwendungen von Morgen.
    Kannst du drauf eingehen, wie man idealerweise ein solches Modell erarbeitet und gestaltet?
    Durch die vielen unbekannten und stakeholder kann man imho hier unendlich Zeit investieren und doch nicht fertig werden (und es birgt die Gefahr zu viel BDUF zu machen)

  • Tobias Schaber

    20. Oktober 2014 von Tobias Schaber

    Hallo Johannes,

    Im zweiten Teil der Serie werde ich ein wenig auf das Thema „gemeinsames Datenmodell“ eingehen, daher nur kurz vorweg:
    Ich gebe dir vollständig recht, es ist mitunter schwer bis utopisch, ein gemeinsames Datenmodell unternehmensweit zu etablieren, und es macht daher meist gar keinen Sinn. Zwei Tipps habe ich deswegen:

    1. Datenmodelle nur für kleinere Unternehmensbereiche etablieren, die thematisch schon eng beieinander liegen („Business Domains“). Oftmals existieren hier schon gemeinsame Strukturen, die ohne große Anpassung übernommen werden können. Zwischen den Business Domains müssen die Objekte dann „übersetzt“ werden.

    2. Strikte Versionierung des Datenmodells. Kommt es zu einer nicht rückwärtskompatiblen Änderung, muss eine neue Version des Datenmodells erzeugt werden. Hierdurch erreicht man eine Entkopplung des Datenmodells von den Bedürfnissen der Nutzer.

    Um es zusammenzufassen: Baut man nicht gerade einen ESB für ein ganz junges Unternehmen, sollte man das Ziel eines unternehmensweiten Datenmodells nicht verfolgen sondern sich auf Teilbereiche beschränken!

    Viele Grüße,
    Tobias

  • Johannes Stelzer

    20. Oktober 2014 von Johannes Stelzer

    Ich habe schon selbst gesehen, wie für einen Teilbereich ein gemeinsames Datenmodell gescheitert ist. Vorallem das Problem, dass Änderungen im gemeinsamen Modell die Entwicklungsgeschgwindigkeit so stark verringert, führte dazu dass es verworfen wurde, da mit den eintreffenden Changes nicht mitgehalten werden konnte.

  • Tobias Schaber

    20. Oktober 2014 von Tobias Schaber

    Um dies beantworten zu können fehlen mir natürlich die konkreten Hintergründe, z.B. wie viele Anwendungen das Format sprechen sollten und über welchen Zeitraum, wie viele Versionen wir sprechen.

    Grundsätzlich gilt jedoch: Ist das Datenmodell versioniert, so tangieren nicht-abwärtskompatible Änderungen die alten Versionen des Modells nicht. Es muss also nicht jede Änderung am Datenmodell zwangsläufig an alle Beteiligten Anwendungen weitergegeben werden.

    Ein domäne-spezifisches Datenmodell ist leider auch kein 100%iger Erfolgsgarant. Es ist lediglich die Wahrscheinlichkeit höher, ein gemeinsames Datenmodell innerhalb einer Business Domäne umsetzen zu können, weil hier potentiell bereits gemeinsame Strukturen bestehen. Ist dies nicht der Fall, kann dieser Ansatz auch keinen Erfolg bringen.

  • Tobias Schaber

    10. Februar 2015 von Tobias Schaber

    Alaeddin Gedik, ein Architekt mit dem ich früher eng zusammengearbeitet habe, hat mich darauf hingewiesen, dass gelöste Kopplung bzw. eine „Entkopplung“ bedeutet, dass eine Verbindung gelöst und somit keinerlei Kommunikation mehr möglich ist. Da er hierbei natürlich vollkommen Recht hat, spreche ich in meiner Serie nun anstelle dessen von einer „losen Kopplung“, was den Kern tatsächlich wesentlich besser trifft.

    Vielen Dank für den Hinweis!

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.