Messaging: Computer, Kommunikation und Kaffee

„Man kann nicht nicht kommunizieren“, wusste schon der österreichisch-amerikanische Philosoph Paul Watzlawick. Kommunikation ist komplex und vielschichtig: Manchmal warten wir auf eine Antwort, manchmal machen wir etwas anderes, bis wir eine Antwort erhalten. Manchmal kommunizieren wir über eine dritte Person oder mit mehreren Personen gleichzeitig. Manchmal fragen wir uns, warum unser Gegenüber nicht antwortet, oder wir stellen fest, dass wir die Anforderungen der Menschen, die uns kontaktieren, nicht erfüllen können. Wir kommunizieren, um auf dem Weg zur Arbeit einen Kaffee zu kaufen, wir kommunizieren bei der Arbeit und wir kommunizieren, wenn wir wieder daheim sind. Wir sprechen, telefonieren, präsentieren, hören zu, und wir schreiben und lesen Nachrichten. Sehr viele Nachrichten, um genau zu sein.

Genau wie Menschen täglich Nachrichten verwenden, um Informationen auszutauschen, wird das Konzept des Datenaustauschs zwischen Computern in einem vordefinierten Format in der Informatik als Messaging bezeichnet. Messaging hat viele Aspekte – gerne erklären wir dir in diesem Artikel die Grundlagen.

Asynchrone vs. Synchrone Kommunikation

Der Hauptunterschied zwischen asynchroner und synchroner Kommunikation ist schnell erklärt. Wartet man auf eine Antwort oder macht man etwas anderes, bis man eine Antwort erhält? Bei der synchronen Kommunikation stellt der Sender eine Verbindung zum Empfänger her, übermittelt die Nachricht und wartet dann auf eine Antwort. Während dieser Zeit werden keine zusätzlichen Aufgaben bearbeitet, bis die Kommunikation abgeschlossen ist und die Verbindung beendet wird.

Dies kann mit dem Bestellvorgang in einem Fast-Food-Restaurant verglichen werden: Wenn Kund:innen ihr Lieblings-Burger-Menü bestellen, sollen sie nicht nach der Getränkebestellung auf die Toilette gehen und alle anderen warten lassen, bevor sie ihr Essen bestellen. Der gesamte Bestellvorgang erfolgt in synchroner Kommunikation, und Kund:innen und Mitarbeitende unterbrechen alle anderen Aufgaben und Aktivitäten, bis die Bestellung vollständig aufgegeben ist. Hier ist die Essensbestellung in synchroner Kommunikation visuell dargestellt:

Bei der asynchronen Kommunikation entfällt die Notwendigkeit, auf eine Antwort zu warten. Nach der Übermittlung der Nachricht können sowohl der Absender als auch der Empfänger mit anderen Aufgaben fortfahren.

Im Beispiel des Fast-Food-Restaurants ist die Art und Weise, wie die Bestellungen in der Küche bearbeitet werden, ein gutes Beispiel für asynchrone Kommunikation. In diesem asynchronen Prozess wird die Bestellung in einer Warteschlange platziert und die Mitarbeitenden in der Küche holen sie ab, sobald sie mindestens einen Thread (oder Arm) zur Verfügung haben. Je nach Arbeitsaufkommen können Mitarbeitende die Bestellung sofort oder erst nach einigen Minuten bearbeiten. Wie genau die Bearbeitung der Bestellungen organisiert ist, kann von Restaurant zu Restaurant unterschiedlich sein, aber die Grundelemente der asynchronen Kommunikation sind dieselben. Das wäre die Weiterleitung der Bestellung von Kassierer:in zum Mitarbeitenden bei asynchroner Kommunikation in einem Diagramm:

Messaging Providers und Queues

Während die synchrone Kommunikation im direkten Austausch von zwei Seiten stattfindet, braucht es für die asynchrone Kommunikation zwei Schlüsselkomponenten: Queues und den Messaging Provider. 

Die Motivation für die Verwendung von Queues ist, dass der Absender mit anderen Aufgaben fortfahren kann. Dafür muss die Nachricht (z.B. die Bestellung Nummer 5) bis zur Abholung im System gehalten werden. Die Lösung ist eine Komponente, die Nachrichten zwischen Sender und Empfänger zwischen speichert. Und diese Komponente heißt… Trommelwirbel: Queue!

Wie eine Warteschlange von Kund:innen, die darauf warten, dass ein:e Kassierer:in ihre Bestellung entgegennimmt, ist eine Messaging Queue eine geordnete Liste von Nachrichten, die darauf warten, verarbeitet zu werden. Das Konzept von Queues ist besonders relevant für Point-to-Point Messaging, bei dem Nachrichten vom Absender genau einen Nachrichtenempfänger haben.

Im Beispiel des Fast-Food-Restaurants sind die Empfänger der Nachricht die Mitarbeitenden in der Küche, die Bestellungen aus der Warteschlange aufnehmen. Wenn gerade jemand eine Schicht alleine in der Küche machen muss, dann ist diese Person der Empfänger im Point-to-Point Messaging. Sehr stressiges Szenario, schauen wir uns diese Visualisierung der Kommunikation an und machen dann schnell weiter…

Das gesamte Nachrichtensystem einschließlich aller Queues und der Logik für die Bearbeitung der Nachrichten wird von einer speziellen Softwarekomponente verwaltet. Hier kommt der Messaging Provider zum Einsatz, der für die Speicherung, die Warteschlangen und die Weiterleitung von Nachrichten zuständig ist. Er sorgt auch dafür, dass die Nachricht nur einmal und in der richtigen Reihenfolge an den Empfänger zugestellt wird.

In unserem Fast-Food-Restaurant speichert der Messaging Provider alle Bestellungen und sorgt dafür, dass jede Bestellung nur einmal und in der richtigen Reihenfolge bearbeitet wird. Die Kassierer:innen könnten hier als Messaging Provider fungieren und die Bestellungen auf einem Blatt Papier notieren, damit die Mitarbeitenden in der Küche sie abholen können. Grafisch dargestellt sieht das etwa wie folgt aus:

Publish/Subscribe Pattern

Was tun, wenn die Nachrichten an mehrere Empfänger versandt werden sollen? Man verwendet die Alternative zum Point-to-Point Messaging, das sogenannte Publish/Subscribe Pattern.

Bei diesem Design Pattern sendet der Absender die Nachricht nicht direkt an den Empfänger, sondern koppelt die Nachricht an ein Topic. Der Empfänger abonniert das Topic und erhält alle an dieses Thema gesendeten Nachrichten. Dieses Konzept ist besonders nützlich, wenn der Absender den Empfänger nicht kennt oder wenn er die Nachricht an mehrere Empfänger senden möchte.

Wir haben im Artikel ja versprochen, dass es um Kaffee geht. Jetzt ist es soweit: Stell dir vor, das Fast-Food-Restaurant beschließt, einen zweiten Bereich zu eröffnen, z. B. ein Café, das alle Bestellungen zum Thema Kaffee bearbeitet. In diesem Fall sind bestimmte Mitarbeitende in der Küche für alle Bestellungen mit dem Topic "Kaffee" zuständig. Andere Mitarbeitende bearbeiten weiterhin die normalen Burger-Bestellungen und kümmern sich nicht um die Kaffee-Bestellungen. In diesem Beispiel befinden wir uns im Bereich der "Publish/Subscribe"-Nachrichtenübermittlung mit den Themen "Burger" und "Kaffee". 

Hierbei empfangen die Mitarbeitenden in der Küche Nachrichten mit Bestellungen aus ihrem Topic. Es gibt noch einen Aspekt der Reihenfolge in der Queue, da die zuerst aufgegebene Kaffeebestellung zuerst bearbeitet werden sollte. Es kann aber auch sein, dass der Burger nach dem Kaffee bestellt wird, aber schon vor dem Kaffee fertig ist. Diese Bearbeitungszeit hängt von der Arbeitsbelastung und der aktuellen Anzahl der Mitarbeitenden in der Küche ab, sei es im Burger- oder im Cafébereich.

APIs vs. Messaging

APIs (Application Programming Interfaces) und Messaging sind zwei verschiedene Arten der Kommunikation zwischen Systemen. Die Unterschiede zwischen diesen Konzepten können wie folgt beschrieben werden: Kommunikation über APIs läuft als synchrone Point-to-point Verbindung. Messaging dagegen ist asynchron und kann sowohl über Point-to-point als auch über Publish-Subscribe laufen. Mit anderen Worten: APIs werden verwendet, wenn der Absender eine sofortige Antwort des Empfängers benötigt. Messaging wird verwendet, wenn der Absender keine sofortige Antwort benötigt oder wenn der Empfänger zum Zeitpunkt des Versands der Nachricht nicht erreichbar ist. Die Anzahl der Empfänger kann bei der Verwendung von Messaging variieren.

In unserem Fast-Food-Restaurant ist die API vergleichbar mit dem Getränkeautomat, bei dem ein:e Kund:in ein Getränk bestellen kann und es sofort erhält. Das Messaging-System ist im Self-Service-Terminal implementiert, das die Bestellung speichert, bis der Mitarbeitende in der Küche sie abholt.

Ok cool. Und jetzt?

Bitte den Sitz nach vorne klappen, wir sind im Landeanflug mit einem weiteren inspirierenden Zitat: "Kommunikation arbeitet für diejenigen, die an ihr arbeiten" (John Powell). Die Tatsache, dass du diesen Artikel bis zum Ende gelesen hast, beweist, dass du bereit bist, an der Kommunikation in deiner Anwendung zu arbeiten. Wir haben gelernt, dass es viele verschiedene Konzepte gibt, um die Kommunikation zwischen Komponenten zu implementieren, und dass jedes Konzept seine Vor- und Nachteile hat. Die Wahl zwischen asynchroner oder synchroner, Point-to-Point- oder Publish-Subscribe-Kommunikation hängt von dem jeweiligen Use Case ab. Letztendlich bleibt das oberste Ziel, sicherzustellen, dass der Burger bzw. der Service rechtzeitig an die Kund:innen geliefert wird.