Unabhängig davon, welche Integrationsarchitektur für eine IT-Landschaft gewählt wird und ob Anwendungen, Unternehmen oder ganze Ökosysteme integriert werden: Bestimmte Integrationsmuster wiederholen sich immer wieder. Alle Muster haben Vor- und Nachteile, die im Folgenden kurz dargestellt werden.

Das Integrationsmuster: Big Ball of Mud

Dateien übertragen

Dateien sind Container für Daten aller Art. Sie können binäre Daten wie Bilder oder PDF-Dateien enthalten. Für die Integration im hier verstandenen Sinne sind jedoch nur Dateien relevant, die Datensätze enthalten. Im einfachsten Fall sind dies kommaseparierte (CSV)-Dateien einschließlich ihrer Verwandten wie Tab- oder Semikolon-separierte Dateien. Wenn die Datensätze mehr Struktur als eine flache Liste haben, werden XML- oder JSON-Dateien verwendet.

Der Dateitransfer hat eine lange Tradition in der Integration zwischen Anwendungen, in der Unternehmensintegration und in einigen Fällen sogar in der Ökosystemintegration. Aber nicht, weil es eine besonders gute Lösung für Integrationsherausforderungen ist. Sondern weil es eine billige, einfache und schnelle Lösung ist. Die Übertragung von Dateien bietet keinerlei Typ- oder Transaktionssicherheit. Was in einer Datei steht, wird vom Protokoll ebenso wenig überwacht wie die Frage, ob eine Datei zur richtigen Zeit am richtigen Ort ist. Es gibt auch kein vordefiniertes Datenformat. Die Kopplung ist sehr lose und besteht vor allem aus - hoffentlich expliziten - Absprachen zwischen den Betreibern einer Anwendung. So schnell und einfach Dateiübertragungen für die Integration eingerichtet werden können, so schnell und einfach können sie auch ins Chaos führen, denn eine Datei kann für eine Anwendung ein echtes Überraschungspaket sein.

Für die Dateiübertragung werden entweder einfache Dateiübertragungsprotokolle und Server wie FTP oder S3 verwendet. Innerhalb eines Unternehmens (für Unternehmensintegration oder Integration zwischen Anwendungen) sind auch verteilte Dateisysteme wie NFS, CIFS, SMB, AFP oder Cluster-Dateisysteme (Ceph, GlusterFS, HDFS) anzutreffen. Zur zeitgesteuerten Übertragung von Dateien werden auch verschiedene Scheduler (z.B. Cronjobs) eingesetzt.

Eigenschaft Ausprägung
Typische Protokolle FTP, S3, NFS, CIFS, SMB, AFP, Ceph, GlusterFS, HDFS
Typische Datenformate Meist CSV, XML oder JSON
Kopplung lose
Typsicherheit keine
Initiator Provider oder Consumer
Transaktionssicherheit keine
Caching möglich
Architekturmuster File Transfer
Integrationsarchitekturen Unternehmensintegration, Integration zwischen Anwendungen, Ökosystemintegration

Datensätze und Objekte übertragen

Sehr viel granularer als Dateien können Daten als Datensätze oder Objekte übertragen werden. Datensätze enthalten nur Daten (z.B.: Kunde, Bestellung, Lieferung), während Objekte auch Methoden enthalten, um die Daten zu manipulieren (z.B.: Kunde anlegen, Mehrwertsteuer berechnen, Liefereingang protokollieren). Irgendwo im Kosmos zwischen reinen Datensätzen und echten Objekten befinden sich die Geschäftsobjekte. Für manche Unternehmen sind sie echte Objekte, für andere sind sie nur Datensätze.

Während echte, ausführbare Objekte in einem binären Format vorliegen müssen, sind für Datensätze die menschen- und maschinenlesbaren Formate JSON und XML weit verbreitet. Dabei ist zu beachten, dass JSON nicht JSON und XML nicht XML ist. Beides sind Meta-Beschreibungssprachen. Das Datenformat eines Datensatzes muss auf der Basis dieses Metadatenformats definiert werden. Für XML wird dazu XML Schema (XSD) verwendet, früher auch Document Type Definition (DTD). Für JSON wird OpenAPI verwendet, früher auch Swagger.

Grundsätzlich ist das Übertragen von Datensätzen für jede Art von Integration geeignet:

Allerdings ist nicht jede Ausprägung für jede Integrationsarchitektur geeignet. Daher werden im Folgenden die Ausprägungen dieses Integrationsmusters näher erläutert.

Enterprise Service Bus (ESB) und Message-Oriented-Middleware (MOM)

Ein ESB oder eine MOM stellen zentrale Komponenten innerhalb einer Anwendungslandschaft dar. Sie bieten den Vorteil eines hohen Komforts bei der Integration von Anwendungen. Sie unterstützen verschiedene Architekturmuster wie Message Passing, Message Queuing oder Publish & Subscribe. Sie bieten teilweise Transaktionssicherheit und Caches. Und sie koppeln die Anwendungen lose aneinander, aber stark an ESB/MOM.Das bedeutet, dass sich ein ESB oder eine MOM zum zentralen Flaschenhals und Single Point of Failure entwickeln kann, der in der Lage ist, die gesamte Anwendungslandschaft lahm zu legen. Darauf sollte bei der Dimensionierung dieser Komponente sehr genau geachtet werden!

Die richtige Integrationsarchitektur für den Einsatz eines ESB / einer MOM ist die Enterprise Integration. Für eine Application Integration ist diese Technologie overkill und für eine Ecosystem Integration ist diese Technologie zu klein. Eine Ecosystem Integration darf nicht auf ein Unternehmensnetzwerk beschränkt sein, was ein ESB / eine MOM zwangsläufig ist.

Eigenschaft Ausprägung
Typische Protokolle JMS, SOAP, AMQP, Apache Openwire
Typische Datenformate XML
Kopplung Zwischen den Anwendungen: Lose; An den Bus / die Middleware: Stark
Typsicherheit Hoch
Initiator Provider oder Consumer
Transaktionssicherheit Möglich
Caching Möglich
Architekturmuster ESB: Message Queuing; MOM: Message Passing, Message Queuing, Publish & Subscribe
Integrationsarchitekturen Unternehmensintegration

REST

Representational State Transfer (REST) ist ein Paradigma für Integrationsarchitekturen, die Datensätze oder Objekte übertragen wollen - im REST-Wording sind beides: Ressourcen. Das Paradigma abstrahiert die Architektur des World Wide Web und ist entsprechend massiv skalierbar. **REST ist nicht an Produkte oder Komponenten gebunden - allein das Muster zählt. Folgende Anforderungen gelten:

  • Die Kommunikation wird immer vom Client zum Server initiiert.
  • Die Kommunikation ist zustandslos. Das bedeutet, dass jede Nachricht alle Informationen enthält, die der Client bzw. Server zur Verarbeitung benötigt.
  • Das Caching von Anfragen wird aktiv genutzt.
  • Die Systeme, die die Architektur implementieren, sind mehrschichtig aufgebaut. Typischerweise stellt eine Anwendung eine REST-API zur Verfügung, die über ein API-Gateway dem weiteren Netzwerk zur Verfügung gestellt wird, davor befindet sich ein SSL-Offloader, der sich um die Verschlüsselung der Verbindungen kümmert.
  • Eine einheitliche Schnittstelle für alle Ressourcen. Das bedeutet im Einzelnen:
    • Jede Ressource ist über einen URI eindeutig adressierbar, jeder REST-konforme Dienst hat eine eindeutige URL.
    • Die unter einer URL erreichbaren Dienste können unterschiedliche Repräsentationen haben. Ein REST-konformer Dienst kann je nach Bedarf eines Clients verschiedene Repräsentationen einer Ressource ausliefern (z.B.: JSON oder XML).
    • Zur Manipulation von Ressourcen werden ausschließlich Standardmethoden (die HTTP-Verben) verwendet.
    • Für die Interaktion zwischen Client und Server wird HATEOAS (Hypermedia as the Engine of Application State) verwendet. Dadurch benötigt ein Client nur wenige Informationen über einen Server oder die dahinterliegende Datenstruktur.

REST ist beliebig skalierbar von sehr kleinen bis zu sehr großen Systemen und damit universell für jede Integrationsarchitektur geeignet - von der Intra Application Integration bis zur Ecosystem Integration, solange der Use Case der Datenübertragung zulässt, dass die Kommunikation immer vom Client initiiert wird.

Eigenschaft Ausprägung
Typische Protokolle HTTP
Typische Datenformate JSON, XML
Kopplung Lose
Typsicherheit Möglich
Initiator Consumer
Transaktionssicherheit Nein
Caching Ja
Architekturmuster REST
Integrationsarchitekturen Alle: Intra Anwendungsintegration, Integration zwischen Anwendungen, Unternehmensintegration, Ökosystemintegration

Funktionsaufrufe übertragen

Dies ist ein Muster zur Realisierung von Interprozesskommunikation (Remote Procedure Call, RPC). Dabei werden Funktionen auf einem anderen System aufgerufen und dort ausgeführt. Gängige Protokolle hierfür sind gRPC, XML-RPC, JSON-RPC oder SAP RFC. Obwohl diese Form der Integration auch für die Enterprise Integration und die Integration zwischen Anwendungen eingesetzt werden kann, ist ihr Haupteinsatzgebiet die Intra Anwendungsintegration. Direkte Funktionsaufrufe stellen eine starke Kopplung zwischen 2 Komponenten her, daher ist dieses Integrationsmuster für hochskalierende Systeme ungeeignet. Für die Ökosystemintegration ist es nicht geeignet.

Eigenschaft Ausprägung
Typische Protokolle CORBA, RFC, gRPC, WebRPC, XML-RPC, JSON-RPC
Typische Datenformate proprietär, XML, JSON
Kopplung stark
Typsicherheit hoch
Initiator Consumer
Transaktionssicherheit Möglich
Caching Nein
Architekturmuster RPC
Integrationsarchitekturen Primär: Intra Anwendungsintegration, In freier Wildbahn aber auch: Integration zwischen Anwendungen und Unternehmensintegration

Queries

Unter Queries, Query Languages, Data Query Languages (DQL) oder auf Deutsch Abfragesprachen versteht man ein Integrationsmuster, um Informationen aus einem System abzurufen. Das System ist in den meisten Fällen eine Datenbank - dann wird SQL verwendet. Es kann aber auch ein Webservice sein, der mit GraphQL abgefragt wird. Oder eine XML-Datei, die dann mit XQuery abgefragt wird. Eine Query beschreibt sehr detailliert, welches Ergebnis der Client vom Server haben möchte. Queries können sehr effizient und schnell sein. Sie binden Client und Server sehr stark aneinander, da eine Query sehr viel über die zugrundeliegende Datenstruktur wissen muss. Dies ist ein ideales Muster für die Intra Application Integration. Für alle anderen Integrationsarchitekturen ist es nicht zu empfehlen. Erstens wegen der bereits erwähnten starken Kopplung und zweitens, weil der Client definiert, welche Daten übertragen werden. Dies kann zu großen Sicherheits- und Performancerisiken führen. Mit einer ungeschickten SQL-Abfrage ist es möglich, ganze Server-Cluster lahm zu legen. Dies kann z.B. mit dem Integrationspattern REST nicht passieren.

Eigenschaft Ausprägung
Typische Protokolle SQL, GraphQL, XQuery
Typische Datenformate Datenbankspezifisch, JSON, XML
Kopplung stark
Typsicherheit hoch
Initiator Consumer
Transaktionssicherheit Möglich
Caching Möglich
Architekturmuster Abfragesprache
Integrationsarchitekturen Intra Anwendungsintegration

Shared Database

Eine Besonderheit unter den Queries ist die Shared Database. Dieses Muster wurde früher häufig für die Integrationsarchitektur Inter Application Integration verwendet und bedeutet, dass sich mehrere Anwendungen eine zentrale Datenbank teilen. So einfach es zu implementieren ist, so gefährlich ist es. Mit diesem Muster können Anwendungen die Daten anderer Anwendungen manipulieren, ohne dass dies bemerkt wird. Sicherheitsaspekte sind schwierig zu handhaben, wenn alle Anwendungen auf dieselben Daten zugreifen, und die Skalierbarkeit ist begrenzt. Hinsichtlich der Verfügbarkeit gibt es in diesem Muster mit der zentralen Datenbank auch eine überkritische Komponente: Sie ist der Single Point of Failure, der bei einem Ausfall alle abhängigen Anwendungen mit ausfallen lässt. Dieses Muster kann etwas entschärft werden, indem die Anwendungen zwar alle dieselbe physische Datenbank, aber unterschiedliche Datenbankschemata verwenden. Dann ist es einfacher, die Sicherheitsrichtlinien durchzusetzen. Außerdem ist ein Schema mit Abhängigkeiten zu nur einer Anwendung leichter zu skalieren oder zu migrieren.

Nachrichten übertragen

Bei diesem Muster werden einzelne Nachrichten über Ereignisse oder Zustandsänderungen übertragen. Dies können Nachrichten sein, die über moderne Protokolle (Kafka-Protokoll, MQTT) übertragen werden, aber auch RSS-Feed-Updates im XML-Format oder ganz klassisch E-Mails über SMTP. Der zentrale “Umschlagplatz” für Nachrichten ist der Broker. Technisch ist dieses Modell mit dem ESB und der MOM verwandt. Der entscheidende Unterschied liegt nicht in den Protokollen, Datenformaten oder Technologien, sondern darin, ob Nachrichten, Ereignisse oder Statusänderungen im einen Fall - oder Datensätze oder Geschäftsobjekte im anderen Fall übertragen werden. Technisch sind auch Mischformen möglich, aber eine gute Architektur verwendet sie nicht, weil sie das Prinzip der Single Level of Abstraction verletzen.

Es wird unterschieden zwischen Nachrichten, die durch Ereignisse erzeugt werden (Messages) und Nachrichten, die als Antwort auf eine Anfrage erzeugt werden (Request-Reply). Die Übertragung von Nachrichten hat ihren Nutzen in Nachrichtenorientierten Anwendungen (E-Mail, IoT) und wird dort sowohl für die Intra Anwendungsintegration wie auch für die Integration zwischen Anwendungen verwendet. Werden in einem Unternehmen oder Ökosystem Daten ebenfalls auf Basis von Nachrichten und Ereignissen ausgetauscht, dann eignet sich dieses Muster (implementiert von geeigneten Systemen) auch für die Unternehmensintegration und die Ökosystemintegration.

Das Muster Nachrichten übertragen sollte jedoch nicht die erste Wahl sein: Nachrichtenübertragungssysteme sind komplex und erfordern einen hohen Betriebsaufwand. Es muss gute Gründe geben, diese Art der Integration zu wählen. Ein solcher Grund kann z.B. eine nachrichtenbasierte Unternehmensarchitektur sein, bei der die Kommunikation sowohl vom Provider als auch vom Consumer initiiert werden muss. Wenn die Geschäftsvorfälle im Unternehmen auch anders abgedeckt werden können, würde ich wegen der einfacheren Handhabbarkeit das Muster Daten und Objekte übertragen bevorzugen.

Eigenschaft Ausprägung
Typische Protokolle XMPP, MQTT, STOMP, Kafka Protokoll, SMTP, RSS
Typische Datenformate Proprietär, XML, Text
Kopplung Zwischen den Anwendungen: Lose; An den Broker: Stark
Typsicherheit Möglich
Initiator Provider oder Consumer
Transaktionssicherheit Möglich
Caching Möglich
Architekturmuster Message Passing (Nachrichtenaustausch), Publish & Subscribe
Integrationsarchitekturen Alle: Intra Anwendungsintegration, Integration zwischen Anwendungen, Unternehmensintegration, Ökosystemintegration

Datenströme übertragen

Hier werden große Datenmengen - meist binäre Daten - übertragen. Diese Form der Integration kommt vor allem bei der Übertragung von Audio- oder Videodaten zum Einsatz. Gängige Protokolle sind RTSP (Real-Time Streaming Protocol) oder WebRTC (Web Real-Time Communication). Auf Basis dieser Protokolle kommt eine Integration per Datenstrom für keine der betrachteten Integrationsarchitekturen in Frage. In letzter Zeit wird jedoch eine spezielle Form von Datenströmen häufiger verwendet: die Übertragung von Nachrichten als Stream im Kafka-Protokoll. Dies ist jedoch kein Datenstrom im hier verwendeten Sinne, sondern entspricht dem Muster Nachrichten übertragen.

Fazit

Wie so oft in der IT-Architektur gibt es nicht die eine Lösung oder in diesem Fall das eine Integrationsmuster, das alle Probleme löst. Wie immer ist ein solides Verständnis des vorliegenden Problems notwendig, um das geeignete Integrationsmuster für eine Lösung zu finden. Dazu macht man sich zunächst klar, was man integrieren möchte (Integrationsarchitekturen), um dann zu definieren, wie man integrieren möchte (Integrationsmuster). Wenn beides zusammenpasst, hat man eine gute Lösung.