Integrationsmuster

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.

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.

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).

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:

•  Intra Application Integration
•  Inter Application Integration
•  Enterprise Integration
•  Ecosystem Integration

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

Ein Enterprise Service Bus (ESB) stellt eine zentrale Komponente innerhalb einer Anwendungslandschaft dar. Sie bietet den Vorteil eines hohen Komforts bei der Integration von  Services. Der ESB ist zuerst nicht auf ein Übertragungsmuster festgelegt, aber es werden meistens  Datensätze oder  Objekte übertragen. Er bietet teilweise Transaktionssicherheit und Caches. Er koppelt  Anwendungen lose aneinander, sofern sie Services nutzen. Aber er koppelt sie stark an den ESB selbst. Das bedeutet, dass sich ein ESB 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 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 zwangsläufig ist.

REST

 Representational State Transfer (REST) ist ein Paradigma für Integrationsarchitekturen, das gundsätzlich jede Art von Daten übertragen kann. Diese Daten müssen jedoch als  Ressourcen vorliegen. Das bedeutet, dass sie ausschließlich über HTTP-Methoden manipuliert werden können und über einen  URI verfügen müssen.

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.

Funktionsaufrufe übertragen

Funktionsaufrufe übertragen ist ein Muster zur Realisierung von Interprozesskommunikation (Remote Procedure Call, RPC, bzw. Remote Function Call, RFC im SAP-Kontext). 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.

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.

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.

Message Brokering

Beim Message Brokering (deutsch: Nachrichten vermittlen) werden einzelne  Nachrichten ü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 oder die Message-Oriented-Middleware (MOM). Technisch ist dieses Modell mit dem ESB verwandt. Der entscheidende Unterschied liegt nicht in der Technologie, sondern in der Abstraktionsebene. Beim Message Brokering werden Nachrichten in Form von  Ereignissen,  Kommandos oder  Dokumenten übertragen. Ein ESB dagegen verbindet einfach nur Services, ohne eine Vorgabe des Abstraktionslevels zu machen. Meistens werden jedoch Datensätze oder Objekte von einem ESB übertragen. 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.

Streaming

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 Message Brokering.

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.