Integrationsstile

Bevor es um Kanäle, Router und Übersetzer geht, steht eine Grundsatzfrage: Auf welche Weise sollen zwei Systeme überhaupt Daten austauschen? Hohpe und Woolf beschreiben vier Grundstile. Sie schließen sich nicht gegenseitig aus, und in großen Unternehmen kommen meist alle vier gleichzeitig vor. Jeder Stil ist eine Antwort auf dieselben Fragen: Wie eng hängen die Systeme voneinander ab? Wie aktuell sind die Daten? Was passiert, wenn ein System ausfällt?

• Anwendung
• Integrationskomponente
• Kanal
• Nachricht
• Datenbank / Speicher

• 1. File Transfer
• 2. Shared Database
• 3. Remote Procedure Invocation
• 4. Messaging

1. File Transfer · Dateiübertragung

Die Idee

Die älteste und einfachste Form der Integration: Ein System schreibt seine Daten in eine Datei, ein anderes liest sie später ein. Beide müssen sich nur auf Dateiformat, Ablageort und Dateinamen einigen. Wie das jeweils andere System intern funktioniert, ist egal.

Beispiel

Ein Online-Shop exportiert jede Nacht alle Bestellungen des Tages als CSV-Datei auf einen gemeinsamen Server. Die Buchhaltungssoftware liest die Datei morgens ein und erzeugt daraus Rechnungen.

Stärken und Schwächen

File Transfer ist robust und leicht zu verstehen, und fast jedes System kann Dateien schreiben und lesen. Die Systeme sind stark entkoppelt: Fällt die Buchhaltung aus, wartet die Datei einfach. Der Preis ist die Verzögerung. Daten sind bis zum nächsten Export veraltet. Dazu kommen praktische Fragen: Was passiert, wenn die Datei noch geschrieben wird, während sie schon gelesen wird? Wer löscht alte Dateien? Wie erkennt man, dass ein Export ausgefallen ist?

In der Praxis

Nach wie vor weit verbreitet, etwa beim Bankenverkehr (SEPA-Dateien), bei Datenlieferungen an Behörden, im Großhandel (EDI) und überall dort, wo nächtliche Stapelverarbeitung genügt.

2. Shared Database · Gemeinsame Datenbank

Die Idee

Statt Daten zwischen Systemen hin- und herzuschicken, arbeiten alle Systeme direkt auf derselben Datenbank. Was ein System schreibt, sehen alle anderen sofort. Es gibt keine Kopien, die auseinanderlaufen können.

Beispiel

Shop, Lagerverwaltung und Buchhaltung nutzen eine gemeinsame Datenbank. Legt der Shop eine Bestellung an, sieht das Lager sie im selben Moment und kann kommissionieren. Die Buchhaltung bucht direkt aus derselben Tabelle.

Stärken und Schwächen

Die Daten sind immer aktuell und konsistent, und die Datenbank sorgt mit Transaktionen für Ordnung. Das Problem ist die enge Kopplung: Alle Systeme hängen am selben Datenmodell. Will das Lager eine Spalte umbenennen, müssen Shop und Buchhaltung mitziehen. Ein gemeinsames Schema, das allen Anforderungen gerecht wird, ist schwer zu entwerfen. Und die Datenbank wird zum Engpass: Sperrt die Buchhaltung bei einem großen Monatsabschluss eine Tabelle, steht womöglich der Shop.

In der Praxis

Häufig innerhalb einer Abteilung oder bei gewachsenen Altsystemen. In Microservice-Architekturen gilt die gemeinsame Datenbank dagegen ausdrücklich als Anti-Pattern: Jeder Dienst soll seine Daten selbst besitzen.

3. Remote Procedure Invocation · Entfernter Aufruf

Die Idee

Ein System stellt Funktionen bereit, die andere Systeme über das Netzwerk direkt aufrufen können, fast so, als wären es lokale Methoden. Der Aufrufer schickt eine Anfrage und wartet auf die Antwort. Anders als bei der gemeinsamen Datenbank bleiben die Daten gekapselt: Jedes System entscheidet selbst, was es nach außen anbietet.

Beispiel

Bevor der Shop eine Bestellung annimmt, ruft er beim Lager bestand("Artikel 4711") auf. Das Lager antwortet mit „12 Stück“, und erst dann zeigt der Shop „lieferbar“ an.

Stärken und Schwächen

Das Modell ist vertraut, weil es sich wie ein normaler Methodenaufruf anfühlt, und die Antwort ist sofort da. Gerade das täuscht aber: Ein Aufruf über das Netz kann langsam sein, ausfallen oder hängen bleiben. Beide Systeme sind zeitlich gekoppelt: Ist das Lager nicht erreichbar, kann der Shop nicht weiterarbeiten. Hängen viele Dienste in Ketten voneinander ab, summieren sich Wartezeiten und Ausfälle.

In der Praxis

REST- und HTTP-Schnittstellen, gRPC, SOAP-Webservices sowie in Java früher RMI und EJB-Remote-Aufrufe. Für Abfragen, die sofort eine Antwort brauchen, ist das oft die richtige Wahl.

4. Messaging · Nachrichtenaustausch

Die Idee

Systeme schicken sich kleine Datenpakete, die Nachrichten, über einen Kanal, den ein Messaging-System bereitstellt. Der Absender legt die Nachricht ab und arbeitet sofort weiter. Der Empfänger holt sie ab, sobald er bereit ist. Das Messaging-System sorgt dafür, dass nichts verloren geht, auch wenn der Empfänger gerade nicht läuft.

Beispiel

Der Shop schickt jede neue Bestellung als Nachricht in den Kanal bestellungen. Das Lager liest die Nachrichten der Reihe nach und kommissioniert. Wird das Lagersystem für ein Update neu gestartet, sammeln sich die Bestellungen solange im Kanal und werden danach abgearbeitet. Der Shop merkt davon nichts.

Stärken und Schwächen

Messaging verbindet die Vorteile der anderen Stile: schneller als Dateien, weniger gekoppelt als eine gemeinsame Datenbank, robuster als direkte Aufrufe. Absender und Empfänger müssen weder gleichzeitig laufen noch einander kennen. Dafür ist das Programmiermodell asynchron und damit anspruchsvoller: Antworten kommen später oder gar nicht, Nachrichten können doppelt ankommen, und die Fehlersuche über mehrere Systeme hinweg ist schwieriger. Außerdem braucht man eine zusätzliche Infrastruktur, den Message Broker.

In der Praxis

Message Broker wie RabbitMQ, Apache ActiveMQ, Apache Kafka, Amazon SQS oder Azure Service Bus. In Java über die Standards JMS bzw. Jakarta Messaging oder Frameworks wie Spring Integration und Apache Camel. Alle weiteren 61 Muster des Buchs bauen auf diesem Stil auf.

Die vier Stile im Vergleich

Das Buch konzentriert sich auf Messaging, weil es den besten Kompromiss aus Aktualität, Entkopplung und Robustheit bietet. Die übrigen sieben Gruppen beschreiben, wie man Messaging-Systeme im Detail aufbaut.