Kanäle

Kanäle sind die Leitungen, durch die Nachrichten fließen. Diese Gruppe beschreibt die verschiedenen Arten von Kanälen und beantwortet dabei vor allem drei Fragen: Wie viele Empfänger bekommt eine Nachricht? Was passiert mit Nachrichten, die nicht verarbeitet oder nicht zugestellt werden können? Und wie verbindet man Anwendungen und ganze Messaging-Systeme, die von sich aus nicht zusammenpassen?

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

• 11. Point-to-Point Channel
• 12. Publish-Subscribe Channel
• 13. Datatype Channel
• 14. Invalid Message Channel
• 15. Dead Letter Channel
• 16. Guaranteed Delivery
• 17. Channel Adapter
• 18. Messaging Bridge
• 19. Message Bus

11. Point-to-Point Channel · Punkt-zu-Punkt-Kanal

Die Idee

Ein Point-to-Point Channel stellt sicher, dass jede Nachricht von genau einem Empfänger verarbeitet wird. Es können mehrere Empfänger am Kanal lauschen, aber sobald einer eine Nachricht genommen hat, ist sie für die anderen weg. Wie bei einem Stapel Arbeitsaufträge: Jeder Mitarbeiter nimmt sich den obersten, und kein Auftrag wird doppelt erledigt.

Beispiel

Das Lager betreibt drei Worker, die Bestellungen kommissionieren. Alle drei lesen aus der Queue bestellungen. Bestellung A geht an Worker 1, Bestellung B an Worker 2, Bestellung C an Worker 3. Keine Bestellung wird zweimal verpackt. Bei viel Betrieb startet man einfach einen vierten Worker.

Worauf achten

Dieser Kanaltyp eignet sich für Aufträge, die genau einmal erledigt werden sollen, und ist die Grundlage für Lastverteilung (siehe Competing Consumers in Gruppe 7). Die Reihenfolge der Verarbeitung ist bei mehreren Empfängern allerdings nicht mehr garantiert: Worker 2 kann mit Bestellung B fertig sein, bevor Worker 1 Bestellung A abgeschlossen hat.

In der Praxis

Queues in JMS (jakarta.jms.Queue), RabbitMQ und Amazon SQS. In Kafka erreicht man dasselbe Verhalten über eine Consumer Group: Innerhalb einer Gruppe bekommt jede Partition genau einen Leser.

12. Publish-Subscribe Channel · Veröffentlichen und Abonnieren

Die Idee

Ein Publish-Subscribe Channel verteilt jede Nachricht an alle Empfänger, die den Kanal abonniert haben. Jeder bekommt eine eigene Kopie und verarbeitet sie unabhängig von den anderen. Der Sender weiß nicht, wie viele Abonnenten es gibt, und muss es auch nicht wissen. Das ist das Observer-Muster der GoF, übertragen auf Systeme, die über ein Netzwerk verbunden sind.

Beispiel

Der Shop meldet jede neue Bestellung im Topic bestellung-eingegangen. Das Lager beginnt mit dem Kommissionieren, die Buchhaltung bereitet die Rechnung vor, und der Newsletter-Dienst trägt den Kunden in die Liste für Produktempfehlungen ein. Kommt später ein Analyse-Dienst hinzu, abonniert er das Topic. Am Shop ändert sich nichts.

Worauf achten

Dieser Kanaltyp eignet sich für Ereignisse, also Meldungen der Art „Das ist passiert“, auf die beliebig viele Interessenten reagieren können. Für Aufträge, die genau einmal ausgeführt werden sollen, ist er falsch. Eine wichtige Frage ist, was mit Abonnenten passiert, die gerade nicht laufen: Bekommen sie verpasste Nachrichten später nachgeliefert? Das regelt der Durable Subscriber aus Gruppe 7.

In der Praxis

Topics in JMS (jakarta.jms.Topic), Fanout- und Topic-Exchanges in RabbitMQ, Amazon SNS, Google Pub/Sub. In Kafka liest jede Consumer Group ein Topic vollständig, mehrere Gruppen ergeben also Publish-Subscribe.

13. Datatype Channel · Kanal pro Datentyp

Die Idee

Jede Art von Nachricht bekommt ihren eigenen Kanal. Bestellungen fließen durch den Bestellkanal, Zahlungen durch den Zahlungskanal. Wer aus einem Kanal liest, weiß damit von vornherein, welchen Datentyp er erhält, und muss nicht jede Nachricht erst untersuchen.

Beispiel

Statt alle Geschäftsvorfälle des Shops in einen gemeinsamen Kanal shop-ereignisse zu werfen, gibt es bestellungen, zahlungen und retouren. Die Retourenabteilung liest nur ihren Kanal und muss sich nicht durch Tausende Bestellungen wühlen, um die wenigen Rücksendungen zu finden.

Worauf achten

Datatype Channels machen das System übersichtlich und typsicher, vergleichbar mit der Typisierung in Java: List<Bestellung> statt List<Object>. Bei sehr vielen Nachrichtentypen wächst allerdings die Zahl der Kanäle stark. Dann kann ein gemeinsamer Kanal mit einem Format Indicator im Header (Gruppe 4) und einem Router (Gruppe 5) die bessere Wahl sein.

In der Praxis

Ein Kafka-Topic pro Ereignistyp, oft mit einem fest zugeordneten Schema in einer Schema Registry. In JMS eine Queue pro Nachrichtentyp. Die Benennung folgt meist einem festen Schema wie bereich.typ.version.

14. Invalid Message Channel · Kanal für ungültige Nachrichten

Die Idee

Manchmal erhält ein Empfänger eine Nachricht, mit der er nichts anfangen kann: falsches Format, Pflichtfelder fehlen, unbekannter Typ. Statt sie stillschweigend zu verwerfen oder abzustürzen, legt er sie in einen besonderen Kanal, den Invalid Message Channel. Dort kann sie später untersucht werden, ohne die normale Verarbeitung aufzuhalten.

Beispiel

Das Lager erhält eine Bestellung, in der das Feld menge fehlt. Es verschiebt die Nachricht in den Kanal ungueltige-nachrichten und arbeitet die nächste Bestellung ab. Ein Entwickler sieht sich die gesammelten Fehler morgens an und stellt fest, dass eine neue Version des Shops das Feld umbenannt hat.

Worauf achten

Wichtig ist die Abgrenzung zum Dead Letter Channel (Muster 15): Beim Invalid Message Channel entscheidet der Empfänger, dass eine Nachricht unbrauchbar ist. Sie wurde zugestellt, aber ihr Inhalt ist fehlerhaft. Beim Dead Letter Channel entscheidet das Messaging-System, weil es eine Nachricht gar nicht zustellen konnte. Ohne einen solchen Kanal bleiben kaputte Nachrichten oft in der Warteschlange hängen und werden endlos neu zugestellt, eine sogenannte Poison Message.

In der Praxis

In Spring Kafka ein DeadLetterPublishingRecoverer für Deserialisierungsfehler, in Camel ein errorHandler mit Ziel-Endpunkt, in RabbitMQ eine eigene Queue, an die abgelehnte Nachrichten weitergeleitet werden. In der Praxis werden Invalid und Dead Letter Channel oft in einem Kanal zusammengefasst, obwohl das Buch sie unterscheidet.

15. Dead Letter Channel · Kanal für unzustellbare Nachrichten

Die Idee

Wie die Post bei unzustellbaren Briefen braucht auch ein Messaging-System einen Ort für Nachrichten, die es nicht zustellen kann. Statt sie zu verlieren oder ewig neu zu versuchen, verschiebt es sie nach einer festgelegten Regel in den Dead Letter Channel. Dort bleiben sie erhalten, bis sich jemand darum kümmert.

Beispiel

Das Lagersystem ist nach einem fehlgeschlagenen Update stundenlang nicht erreichbar. Die Bestellungen haben eine Ablaufzeit von zwei Stunden. Nachrichten, die in dieser Zeit nicht zugestellt werden konnten, verschiebt der Broker in den Dead Letter Channel. Ein Überwachungsdienst schlägt Alarm, und nach der Reparatur werden die Bestellungen von dort aus erneut eingespielt.

Worauf achten

Typische Gründe für eine Verschiebung sind: zu viele fehlgeschlagene Zustellversuche, abgelaufene Nachrichten (siehe Message Expiration in Gruppe 4), ein Zielkanal, den es nicht gibt, oder eine volle Warteschlange. Ein Dead Letter Channel ist nur nützlich, wenn ihn jemand beobachtet. Ein Kanal, der unbemerkt vollläuft, ist nur eine aufwendigere Form, Nachrichten zu verlieren.

In der Praxis

Dead Letter Exchanges in RabbitMQ, Dead-Letter-Queues in Amazon SQS und ActiveMQ (ActiveMQ.DLQ), Dead-Letter-Topics in Spring Kafka und der deadLetterChannel-Fehlerbehandler in Apache Camel.

16. Guaranteed Delivery · Garantierte Zustellung

Die Idee

Nachrichten, die nur im Arbeitsspeicher des Brokers liegen, gehen bei einem Absturz oder Neustart verloren. Bei garantierter Zustellung schreibt das Messaging-System jede Nachricht auf einen dauerhaften Speicher, bevor es dem Sender den Empfang bestätigt. Erst wenn der Empfänger die Verarbeitung bestätigt hat, wird sie gelöscht. So überlebt eine Nachricht jeden Ausfall dazwischen.

Beispiel

Ein Kunde bestellt um 23:58 Uhr. Um 23:59 Uhr startet der Broker wegen eines Sicherheitsupdates neu. Weil die Bestellung schon auf der Platte liegt, ist sie nach dem Neustart wieder da und wird an das Lager zugestellt. Ohne Guaranteed Delivery wäre die Bestellung verloren, obwohl der Shop dem Kunden schon „Danke für Ihre Bestellung“ angezeigt hat.

Worauf achten

Die Sicherheit kostet Geschwindigkeit, denn Schreiben auf die Platte ist langsamer als im Speicher zu bleiben. Für unwichtige, schnell veraltende Daten, etwa Live-Kurse, die eine Sekunde später ohnehin überholt sind, verzichtet man deshalb oft darauf. Und „garantiert“ bedeutet in der Praxis meist mindestens einmal: Im Fehlerfall kann eine Nachricht doppelt ankommen. Damit muss der Empfänger umgehen können (siehe Idempotent Receiver in Gruppe 7).

In der Praxis

DeliveryMode.PERSISTENT in JMS, durable Queues mit persistenten Nachrichten in RabbitMQ, in Kafka die Einstellungen acks=all und ein Replikationsfaktor größer als eins, sodass jede Nachricht auf mehreren Servern liegt.

17. Channel Adapter · Kanaladapter

Die Idee

Viele Systeme wurden nie für Messaging gebaut: Altanwendungen, Standardsoftware, Datenbanken, Dateiablagen. Ein Channel Adapter sitzt an ihrem Rand und übersetzt zwischen ihrer Welt und dem Messaging-System. Er liest Daten über die Schnittstelle, die das System ohnehin bietet, und verschickt sie als Nachrichten. Oder umgekehrt: Er empfängt Nachrichten und schreibt sie in das System.

Beispiel

Ein 20 Jahre altes ERP-System verwaltet die Preise. Ändern kann man es nicht mehr. Ein Channel Adapter fragt jede Minute die Preistabelle der Datenbank ab und schickt jede Änderung als Nachricht an den Kanal preisaenderungen. Der Shop abonniert den Kanal und zeigt neue Preise innerhalb einer Minute an, ohne dass das ERP davon etwas weiß.

Worauf achten

Ein Adapter kann auf verschiedenen Ebenen ansetzen: an der Benutzeroberfläche (die schlechteste Wahl, sie bricht bei jeder Änderung), an einer Programmschnittstelle oder direkt an der Datenbank. Je tiefer er ansetzt, desto mehr Wissen über interne Strukturen braucht er. Moderne Varianten lesen das Transaktionslog der Datenbank mit, statt sie regelmäßig abzufragen (Change Data Capture).

In der Praxis

Kafka Connect mit Hunderten fertiger Konnektoren für Datenbanken, Dateien und SaaS-Dienste, Debezium für Change Data Capture, die Komponenten in Apache Camel (file:, ftp:, sql:, jdbc:) und die Inbound- und Outbound-Adapter von Spring Integration.

18. Messaging Bridge · Brücke zwischen Messaging-Systemen

Die Idee

Große Organisationen haben oft mehr als ein Messaging-System: eines aus einem älteren Projekt, ein anderes von einer übernommenen Firma, ein drittes in der Cloud. Die Systeme sprechen nicht direkt miteinander. Eine Messaging Bridge verbindet sie, indem sie aus einem Kanal im einen System liest und jede Nachricht in den passenden Kanal im anderen System schreibt.

Beispiel

Der Shop läuft seit Jahren mit RabbitMQ. Die neue Datenplattform setzt auf Kafka. Statt den Shop umzubauen, kopiert eine Bridge alle Nachrichten aus dem RabbitMQ-Kanal bestellungen in das gleichnamige Kafka-Topic. Rückmeldungen laufen auf demselben Weg zurück.

Worauf achten

Eine Bridge verbindet nur bestimmte, ausgewählte Kanäle, nicht ganze Systeme, und braucht für jeden eine eigene Zuordnung. Sie muss mit unterschiedlichen Zustellgarantien umgehen: Bietet das Zielsystem weniger Sicherheit als das Quellsystem, gilt für den Weg insgesamt die schwächere. Unterscheiden sich die Nachrichtenformate, kommt zur Bridge ein Message Translator hinzu. Oft ist eine Bridge eine Übergangslösung während einer Migration.

In der Praxis

Der JMS-Bridge-Dienst von ActiveMQ Artemis, die Shovel- und Federation-Plugins von RabbitMQ, Kafka Connect mit einem Quell- und einem Ziel-Konnektor, MirrorMaker zwischen zwei Kafka-Clustern.

19. Message Bus · Nachrichtenbus

Die Idee

Ein Message Bus ist eine gemeinsame Integrationsplattform für eine ganze Organisation, vergleichbar mit dem Bus in einem Computer, an den Grafikkarte, Festplatte und Netzwerkkarte angeschlossen werden. Er besteht aus drei Absprachen: einer gemeinsamen Infrastruktur (Kanäle und Broker), einem gemeinsamen Datenformat (siehe Canonical Data Model in Gruppe 6) und gemeinsamen Regeln, welche Nachrichten über welche Kanäle laufen. Jede Anwendung wird einmal an den Bus angeschlossen und kann dann mit allen anderen kommunizieren.

Beispiel

Ein Händler verbindet Shop, Lager, Buchhaltung, CRM, Versand, Reporting und ein altes ERP über einen Bus. Ohne Bus bräuchte jede Anwendung eine eigene Schnittstelle zu jeder anderen: Bei sieben Anwendungen sind das bis zu 21 Verbindungen. Mit Bus sind es sieben Anschlüsse. Ein neues Kassensystem in den Filialen wird einmal angeschlossen und erhält sofort alle Bestellungen und Preisänderungen.

Worauf achten

Der Bus lohnt sich erst ab einer gewissen Zahl von Anwendungen, und der Aufwand liegt vor allem in den Absprachen, nicht in der Technik: Auf ein gemeinsames Datenmodell müssen sich alle Abteilungen einigen. Historisch wurden Busse oft mit viel Logik überladen. Die schwergewichtigen „Enterprise Service Bus“-Produkte der 2000er-Jahre gelten deshalb heute als Warnung. Der moderne Ansatz heißt „Smart Endpoints, Dumb Pipes“: Der Bus transportiert nur, die Logik bleibt in den Anwendungen.

In der Praxis

Eine zentrale Kafka-Plattform mit vereinbarten Topics und Schemas ist heute die häufigste Form. Klassische Enterprise Service Buses sind etwa MuleSoft, IBM Integration Bus oder WSO2.

Die Kanalarten im Überblick