Messaging Pattern

Messaging Pattern

Das Messaging Pattern ist ein grundlegendes Kommunikations- und Integrationsmuster in der Softwareentwicklung. Es beschreibt den **Austausch von Informationen zwischen verteilten Komponenten über Nachrichten**, anstatt über direkte Funktionsaufrufe. Dadurch werden Systeme **lose gekoppelt**, asynchron und skalierbar.

Motivation

In verteilten Systemen kommunizieren Komponenten häufig über Netzwerke. Direkte Aufrufe (z. B. RPC) führen zu:

• starker Abhängigkeit zwischen Sender und Empfänger,
• geringerer Fehlertoleranz,
• schlechter Skalierbarkeit.

Das Messaging Pattern löst diese Probleme durch **Message Passing**:

• Sender und Empfänger müssen **nicht gleichzeitig aktiv** sein.
• Die Zustellung erfolgt über eine **Zwischeninstanz** (Message Broker oder Queue).
• Nachrichten können **zwischengespeichert, verteilt oder priorisiert** werden.

Grundprinzip

Nachrichten werden von einem **Producer (Sender)** erzeugt und über eine **Nachrichteninfrastruktur** an einen oder mehrere **Consumer (Empfänger)** zugestellt.

Grafische Darstellung

+-----------+         +---------------+         +-----------+
| Producer  |  --->   |  Message Bus   |  --->   | Consumer  |
|(sendet)   |         | (Broker/Queue) |         | (verarbeitet)
+-----------+         +---------------+         +-----------+

Bestandteile

Komponente	Rolle
**Producer**	Erzeugt und sendet Nachrichten.
**Consumer**	Empfängt und verarbeitet Nachrichten.
**Message**	Daten, die übertragen werden (z. B. JSON, Protobuf).
**Message Broker / Queue**	Vermittelt, speichert und verteilt Nachrichten.

Nachrichteneigenschaften

Nachrichten können sein:

• **Befehle** (z. B. „führe X aus“)
• **Ereignisse** (z. B. „Y ist passiert“)
• **Anfragen & Antworten** (Request/Reply)
• **Status- oder Datenpakete**

Kommunikationsmodelle

Modell	Beschreibung	Beispiel
**One-to-One**	Eine Nachricht wird nur von einem Consumer verarbeitet.	Job-Queue / Task-Verarbeitung
**One-to-Many**	Eine Nachricht wird an mehrere Empfänger verteilt.	Event-Broadcast
**Many-to-Many**	Mehrere Sender und Empfänger teilen sich denselben Nachrichtenkanal.	Pub/Sub-Systeme

Varianten des Messaging Patterns

1. Point-to-Point (Queue)

Eine Queue speichert Nachrichten, bis ein Consumer sie verarbeitet. Verwendung: Aufgabenverarbeitung, Hintergrundjobs.

2. Publish-Subscribe (Pub/Sub)

Publisher senden Nachrichten an ein **Topic**; alle Subscriber dieses Topics empfangen sie. Verwendung: Event-getriebene Systeme, Echtzeitkommunikation.

3. Request-Reply

Eine Anfrage-Nachricht führt zu einer Rückantwort. Verwendung: Remote-Kommunikation zwischen Diensten.

Zustellungsgarantien

Viele Messaging-Systeme bieten unterschiedliche Zustellungsmodelle:

Garantie	Bedeutung
**At most once**	Nachricht wird höchstens einmal zugestellt (keine Wiederholung, Risiko von Verlust).
**At least once**	Nachricht wird mindestens einmal zugestellt (mögliche Duplikate).
**Exactly once**	Nachricht wird genau einmal zugestellt (aufwendig, z. B. durch Transaktionen).

Beispiel mit RabbitMQ (vereinfachtes Python-Beispiel)

Producer

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='tasks')

channel.basic_publish(exchange='', routing_key='tasks', body='Aufgabe 1')
connection.close()

Consumer

import pika

def callback(ch, method, properties, body):
    print("Verarbeitung:", body.decode())
    ch.basic_ack(delivery_tag=method.delivery_tag)

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.basic_consume(queue='tasks', on_message_callback=callback)
channel.start_consuming()

Vorteile

• **Lose Kopplung** zwischen Komponenten
• **Asynchronität** → keine gegenseitigen Wartezeiten
• **Hohe Skalierbarkeit** durch parallele Consumer
• **Fehlertoleranz** durch persistente Nachrichten und Wiederholungen
• **Flexibilität** in heterogenen Systemlandschaften

Nachteile

• Komplexere Infrastruktur (Broker, Monitoring, Fehlermanagement)
• Verzögerungen möglich (Latenz statt unmittelbarer Antwort)
• Zustands- und Fehlermanagement müssen explizit berücksichtigt werden

Typische Anwendungen

• Microservices-Kommunikation
• Event-getriebene Architekturen (EDA)
• Hintergrundverarbeitung (Batch/Worker)
• IoT-Systeme und Sensordaten
• Finanz- und Handelssysteme

Bekannte Messaging-Technologien

• **RabbitMQ** (AMQP)
• **Apache Kafka** (Streaming & Pub/Sub)
• **ActiveMQ / Artemis**
• **Redis Pub/Sub**
• **Google Pub/Sub**, **AWS SNS/SQS**, **Azure Service Bus**

Zusammenhang mit anderen Mustern

Muster	Beziehung
Publisher-Subscriber-Entwurfsmuster	Spezielle Form des Messaging zur Eventverteilung.
Competing-Consumer-Entwurfsmuster	Spezielle Form des Messaging zur Lastverteilung.
Mediator-Entwurfsmuster	Zentrale Kommunikation, aber innerhalb von Objektsystemen.

Zusammenfassung

Das Messaging Pattern ermöglicht die **asynchrone, skalierbare und lose gekoppelte Kommunikation** zwischen Softwarekomponenten. Durch Message Broker, Queues und Themenkanäle können Systeme entworfen werden, die robust, erweiterbar und verteilter Natur sind.

Siehe auch

• Publisher-Subscriber-Entwurfsmuster
• Competing-Consumer-Entwurfsmuster
• RabbitMQ
• Apache Kafka
• Event-Driven Architecture

Weblinks

• https://www.enterpriseintegrationpatterns.com/
• https://en.wikipedia.org/wiki/Message-oriented_middleware
• https://www.rabbitmq.com/getstarted.html