Integration Patterns praktisch erklärt

Die vier wichtigsten Formen von Integration Patterns sind: File Transfer, Shared Database, Remote Procedure Invocation und Messaging. Da Messaging unmittelbarer als File Transfer, besser gekapselt als Shared Database und zuverlässiger als Remote Procedure Invocation ist, möchte ich mich im Folgenden auf diese Form von Integration Pattern konzentrieren.

Wenn zwei Menschen interagieren

Um die ganze Problematik von Kommunikationsproblemen verständlicher zu machen, möchte ich von folgendem Beispiel ausgehen: Stellt euch, anstatt von zwei IT-Systemen, zwei Personen (Sender und Empfänger) vor, die räumlich durch einen Ozean voneinander getrennt sind und zudem noch unterschiedliche Sprachen sprechen. Trotz dieser Barrieren möchten Sender und Empfänger möglichst effizient miteinander kommunizieren. In der IT wird diese erschwerte Kommunikation durch Integration Patterns unterstützt. Auf unser Bespiel übertragen heißt das: Die beiden Personen schreiben sich Zettel (Files), die sie dann jeweils lesen (File Transfer). Bald merken sie aber, dass sie sich unterschiedliche Arten von Nachrichten schicken. Also wird ein System eingeführt, dass ihnen die Arbeit beim Verfassen der unterschiedlichen Nachrichten abnimmt (Messaging).

Wie das Messaging funktioniert

Bleiben wir bei unserem Bespiel: Die erste Person schickt der zweiten einen Brief (Message) mit der Post (Computer Network). Der Brief enthält eine Nachricht (Body), die in einem Umschlag (Headers) verpackt ist. Der Umschlag enthält wiederum Informationen über den Absender und Empfänger. Der Absender muss schließlich wissen, wo der Empfänger lebt (Endpoint) und umgekehrt muss der Empfänger wissen, wer den Brief geschickt hat.

Der Empfänger möchte nicht mehr als fünf ungelesene Briefe in seinem Briefkasten haben und sie zudem in der Reihenfolge erhalten, in der sie angekommen sind. Aus diesem Grund benutzt er einen Briefkasten, in dem die Briefe sortiert werden und die Anzahl auf fünf Stück beschränkt ist (Message Channel). Damit er nicht ständig selber kontrollieren muss, ob neue Briefe angekommen sind, hat er einen Angestellten, der alle zehn Minuten den Briefkasten prüft (Polling Consumer). Auf Dauer ist dieses Vorgehen allerdings recht ineffizient und so schafft er sich einen modernen Briefkasten an, der automatisch eine SMS (Event) verschickt, wenn ein neuer Brief angekommen ist. So muss der Briefkasten nicht alle zehn Minuten, sondern nur dann, wenn eine neue SMS angekommen ist (Event Driven Consumer), kontrolliert werden.

Nehmen wir an, die Adresse des Empfängers (Endpoint) ist mehreren Personen bekannt. Der Empfänger möchte aber nur Sendungen von einem bestimmten Absender empfangen und außerdem sollen diese Sendungen aus Zeitgründen nicht mehr als fünf Zeilen haben. Um das sicherzustellen, benutzt er zwei Assistenten (Filter), die in getrennten Zimmern sitzen. Der erste Assistent wirft alles weg, was nicht vom gewünschten Absender stammt. Die gefilterten Sendungen werden durch eine Leitung (Pipe) an den zweiten Assistenten weitergegeben. Dieser wirft wiederum alle Nachrichten weg, die mehr als fünf Zeilen umfassen. Nun haben wir - wie eingangs erwähnt - noch das Problem, dass Person A (Sender) und Person B (Empfänger) nicht die gleiche Sprache sprechen. Daher sitzt im nächsten Zimmer noch ein Übersetzer (Translator), der alle Nachrichten entsprechend übersetzt.

Im Laufe der Zeit schickt der Sender dem Empfänger verschiedene Arten von Nachrichten. Dazu können beispielsweise allgemeine Informationen (Generic Data), bestimmte Anfragen (Description of a command) oder eine Aussage über eine bestimmte Tätigkeit (Description of an event that occurred in the sender) zählen. Falls der Sender vom Empfänger eine Rückmeldung erwartet (Request-Reply), müssen die Rückantwortadresse sowie ein eindeutiger Identifikator (Correlation Identifier) mitgeliefert werden. Nur auf diese Weise kann die Rückmeldung der richtigen Nachricht zugeordnet werden.

Wie ihr wisst, geht ab und zu auch eine Sendung unterwegs verloren. Der Sender vertraut der Post (Computer Network) daher nicht komplett. Deswegen behält er solange eine Kopie von jedem verschickten Brief, bis ihm die Post bestätigt, dass der jeweilige Brief dem Empfänger zugestellt wurde (Store and Forward). Bleibt die Sendebestätigung innerhalb einer angemessenen Frist aus, kann der Sender den Brief nochmals verschicken. Als zusätzliche Sicherheit besteht zudem noch die Möglichkeit, eine Bestätigung - sobald der Empfänger den Brief gelesen hat – anzufordern. (Acknowledgment).

Kurz zusammengefasst, gibt es im beschriebenen Prozess fünf wichtige Schritte: Die Nachricht wird erstellt, gesendet, zugestellt, danach vom Message Channel herausgeholt und schließlich bearbeitet oder gelesen. Die beschriebenen Grundkomponenten sind die Basis jeder Messaging Architektur.

Message Channel und Message Router

Da der Message Channel das Fundament von jedem Messaging-System ist und der Message Router die fortgeschrittene Verarbeitung von Nachrichten ermöglicht, möchte ich euch in diesem Zusammenhang weitere Beispiele für die Nutzung dieser beiden Komponenten nennen.

Message Channel:

Neben der beschrieben Möglichkeit, dass der Empfänger einen „Briefkasten“ nutzt, um Nachrichten zu sortieren und ihre Anzahl zu limitieren (Point to Point Channel), gibt es weitere Verwendungszwecke. Nehmen wir beispielsweise den Fall, dass der Absender (Publisher) Einladungen - allerdings nur an gewisse Personen – verschickt, die vorher ein entsprechendes Interesse angemeldet haben, diese Veranstaltungen zu besuchen (Subscriber).

Message Router:

Nehmen wir an, der Empfänger wohnt mit einer anderen Person zusammen in der Wohnung. Er braucht also einen weiteren Assistenten (Router), der sich um die korrekte Nachrichtenverteilung zwischen diesen zwei Personen kümmert. Es ist nun möglich, dass ein Absender eine zusammengesetzte Nachricht aus verschiedenen Teilen schickt, die jeweils auf unterschiedliche Empfänger aufgeteilt werden muss. Hier hilft ein weiterer Assistent (Splitter), der die Nachricht entsprechend auf mehrere Empfänger splittet. Auch das gegenteilige Beispiel kann eintreten, in dem der Sender mehrere Einzelnachrichten verschickt, die am Ende zu einer konsolidierten Nachricht zusammengefügt werden sollen. In diesem Fall wird ein Aggregator genutzt.

Fazit

Wie ihr am Beispiel des Messagings gesehen habt, sind Integration Patterns wichtige Komponenten, die wiederkehrende Kommunikationsprobleme – etwa unterschiedliche Sprachen oder verschiedene Anforderungen - während der Entwicklung von IT-Systemen lösen. In meinem Blog-Beitrag habe ich natürlich nur an der Oberfläche gekratzt und versucht, das Thema einfach und verständlich zu erklären. Wer mehr über Integration Patterns lesen und erfahren möchte, dem empfehle ich das Buch „Enterprise Integration Patterns”. Obwohl es das Buch schon seit zehn Jahren gibt, ist es meiner Meinung nach noch immer aktuell.

Ihr möchtet mehr über interessante Themen aus der IT-Welt erfahren? Dann werft doch auch einen Blick in unsere bisher erschienenen Blog-Beiträge.