Messaging Pattern - Versionsgeschichte

PhilKa am 8. November 2025 um 13:00 Uhr

2025-11-08T13:00:47Z

← Nächstältere Version		Version vom 8. November 2025, 15:00 Uhr
Zeile 2:		Zeile 2:

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

	== Motivation ==		== Motivation ==
Zeile 11:		Zeile 11:
	* schlechter Skalierbarkeit.		* schlechter Skalierbarkeit.

	Das Messaging Pattern löst diese Probleme durch Message Passing:		Das Messaging Pattern löst diese Probleme durch ''Message Passing'':
	* Sender und Empfänger müssen nicht gleichzeitig aktiv sein.		* Sender und Empfänger müssen ''nicht gleichzeitig aktiv'' sein.
	* Die Zustellung erfolgt über eine Zwischeninstanz (Message Broker oder Queue).		* Die Zustellung erfolgt über eine ''Zwischeninstanz'' (Message Broker oder Queue).
	* Nachrichten können zwischengespeichert, verteilt oder priorisiert werden.		* Nachrichten können ''zwischengespeichert, verteilt oder priorisiert'' werden.

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

	=== Grafische Darstellung ===		=== Grafische Darstellung ===
Zeile 31:		Zeile 31:
	! Komponente !! Rolle		! Komponente !! Rolle
	\|-		\|-
	\| Producer \|\| Erzeugt und sendet Nachrichten.		\| ''Producer'' \|\| Erzeugt und sendet Nachrichten.
	\|-		\|-
	\| Consumer \|\| Empfängt und verarbeitet Nachrichten.		\| ''Consumer'' \|\| Empfängt und verarbeitet Nachrichten.
	\|-		\|-
	\| Message \|\| Daten, die übertragen werden (z. B. JSON, Protobuf).		\| ''Message'' \|\| Daten, die übertragen werden (z. B. JSON, Protobuf).
	\|-		\|-
	\| Message Broker / Queue \|\| Vermittelt, speichert und verteilt Nachrichten.		\| ''Message Broker / Queue'' \|\| Vermittelt, speichert und verteilt Nachrichten.
	\|}		\|}

	== Nachrichteneigenschaften ==		== Nachrichteneigenschaften ==
	Nachrichten können sein:		Nachrichten können sein:
	* Befehle (z. B. „führe X aus“)		* ''Befehle'' (z. B. „führe X aus“)
	* Ereignisse (z. B. „Y ist passiert“)		* ''Ereignisse'' (z. B. „Y ist passiert“)
	* Anfragen & Antworten (Request/Reply)		* ''Anfragen & Antworten'' (Request/Reply)
	* Status- oder Datenpakete		* ''Status- oder Datenpakete''

	== Kommunikationsmodelle ==		== Kommunikationsmodelle ==
Zeile 51:		Zeile 51:
	! Modell !! Beschreibung !! Beispiel		! Modell !! Beschreibung !! Beispiel
	\|-		\|-
	\| One-to-One \|\| Eine Nachricht wird nur von einem Consumer verarbeitet. \|\| Job-Queue / Task-Verarbeitung		\| ''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		\| ''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		\| ''Many-to-Many'' \|\| Mehrere Sender und Empfänger teilen sich denselben Nachrichtenkanal. \|\| Pub/Sub-Systeme
	\|}		\|}

Zeile 65:		Zeile 65:

	=== 2. Publish-Subscribe (Pub/Sub) ===		=== 2. Publish-Subscribe (Pub/Sub) ===
	Publisher senden Nachrichten an ein Topic; alle Subscriber dieses Topics empfangen sie.		Publisher senden Nachrichten an ein ''Topic''; alle Subscriber dieses Topics empfangen sie.
	Verwendung: Event-getriebene Systeme, Echtzeitkommunikation.		Verwendung: Event-getriebene Systeme, Echtzeitkommunikation.

Zeile 78:		Zeile 78:
	! Garantie !! Bedeutung		! Garantie !! Bedeutung
	\|-		\|-
	\| At most once \|\| Nachricht wird höchstens einmal zugestellt (keine Wiederholung, Risiko von Verlust).		\| ''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).		\| ''At least once'' \|\| Nachricht wird mindestens einmal zugestellt (mögliche Duplikate).
	\|-		\|-
	\| Exactly once \|\| Nachricht wird genau einmal zugestellt (aufwendig, z. B. durch Transaktionen).		\| ''Exactly once'' \|\| Nachricht wird genau einmal zugestellt (aufwendig, z. B. durch Transaktionen).
	\|}		\|}

Zeile 114:		Zeile 114:

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

	== Nachteile ==		== Nachteile ==
Zeile 133:		Zeile 133:

	== Bekannte Messaging-Technologien ==		== Bekannte Messaging-Technologien ==
	* RabbitMQ (AMQP)		* ''RabbitMQ'' (AMQP)
	* Apache Kafka (Streaming & Pub/Sub)		* ''Apache Kafka'' (Streaming & Pub/Sub)
	* ActiveMQ / Artemis		* ''ActiveMQ / Artemis''
	* Redis Pub/Sub		* ''Redis Pub/Sub''
	* Google Pub/Sub, AWS SNS/SQS, Azure Service Bus		* ''Google Pub/Sub'', ''AWS SNS/SQS'', ''Azure Service Bus''

	== Zusammenhang mit anderen Mustern ==		== Zusammenhang mit anderen Mustern ==
Zeile 151:		Zeile 151:

	== Zusammenfassung ==		== Zusammenfassung ==
	Das Messaging Pattern ermöglicht die asynchrone, skalierbare und lose gekoppelte Kommunikation zwischen Softwarekomponenten.		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.		Durch Message Broker, Queues und Themenkanäle können Systeme entworfen werden, die robust, erweiterbar und verteilter Natur sind.

PhilKa: Die Seite wurde neu angelegt: „= 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 Aufru…“

2025-11-08T13:00:12Z

Die Seite wurde neu angelegt: „= 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 Aufru…“

Neue Seite

= 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 ===
<pre>
+-----------+ +---------------+ +-----------+
| Producer | ---> | Message Bus | ---> | Consumer |
|(sendet) | | (Broker/Queue) | | (verarbeitet)
+-----------+ +---------------+ +-----------+
</pre>

== Bestandteile ==
{| class="wikitable"
! 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 ==
{| class="wikitable"
! 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:

{| class="wikitable"
! 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 ===
<syntaxhighlight lang="python">
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()
</syntaxhighlight>

=== Consumer ===
<syntaxhighlight lang="python">
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()
</syntaxhighlight>

== 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 ==
{| class="wikitable"
! 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