Nachrichtenmuster - Messaging pattern

In der Softwarearchitektur ist ein Messaging-Muster ein Architekturmuster, das beschreibt, wie sich zwei verschiedene Teile einer Anwendung oder verschiedene Systeme verbinden und miteinander kommunizieren. Es gibt viele Aspekte des Messaging-Konzepts, die in die folgenden Kategorien unterteilt werden können: Hardware-Geräte-Messaging (Telekommunikation, Computernetzwerke, IoT usw.) und Software-Datenaustausch (die verschiedenen Datenaustauschformate und Softwarefunktionen eines solchen Datenaustauschs). Trotz des unterschiedlichen Kontextes weisen beide Kategorien gemeinsame Merkmale für den Datenaustausch auf.

Allgemeine Konzepte des Nachrichtenmusters

In der Telekommunikation , ein Nachrichtenaustauschmuster ( MEP beschrieben) , um das Muster von Nachrichten durch ein erforderliches Kommunikationsprotokoll zu etablieren oder Verwendung Kommunikationskanal . Das Kommunikationsprotokoll ist ein Format, das verwendet wird, um die Nachricht darzustellen, auf die sich alle kommunizierenden Parteien einigen (oder verarbeiten können). Der Kommunikationskanal ist die Infrastruktur, die es ermöglicht, dass Nachrichten zwischen den Kommunikationspartnern "reisen". Die Nachrichtenaustauschmuster den Nachrichtenfluss zwischen den Parteien in dem Kommunikationsprozess zu beschreiben, gibt es zwei Hauptnachrichtenaustauschmuster - ein Anforderungs-Antwort - Muster und ein Einweg- Muster.

Wenn beispielsweise Inhalte im Internet (dem Kanal) angezeigt werden , verwendet ein Webbrowser (eine kommunizierende Partei) das HTTP (das Kommunikationsprotokoll), um eine Webseite vom Server (einer anderen kommunizierenden Partei) anzufordern, und rendert dann die zurückgegebenen Daten in ihre visuelle Form. So funktioniert das Request-Response- Messaging-Muster.

Alternativ haben wir in Computernetzwerken das UDP- Netzwerkprotokoll. Es wird mit dem Einweg- Nachrichtenmuster verwendet, bei dem der sendende Teilnehmer nicht daran interessiert ist, ob die Nachricht bei einem empfangenden Teilnehmer ankommt, noch erwartet er, dass einer der empfangenden Teilnehmer eine "Antwort"-Nachricht produziert.

Gerätekommunikation

In diesem Abschnitt geht es um den Datenaustausch zwischen Hardwaregeräten. Damit die Geräte Daten lesen und austauschen können, würden sie ein hardwarespezifisches Protokoll (z von einem anderen Hardwaregerät interpretiert, das der Empfänger ist (z. B. Ihr Küchenradio). Beim Beispiel des Funkgeräts haben wir ein unidirektionales Kommunikationsmuster, und das Nachrichtenaustauschprotokoll ist das Funksignal selbst.

Gerätekommunikation kann sich auch darauf beziehen, wie die Hardwaregeräte in einem Nachrichtenaustauschsystem den Nachrichtenaustausch ermöglichen. Beim Surfen im Internet arbeiten beispielsweise mehrere verschiedene Geräte zusammen, um die Nachricht über den Internetverkehr zu übermitteln – Router, Switches und Netzwerkadapter, die auf Hardwareebene Signale in Form von TCP- oder UDP-Paketen senden und empfangen . Jedes solche Paket könnte für sich genommen als Nachricht bezeichnet werden, wenn wir unsere Sicht auf ein Paar miteinander kommunizierender Hardwaregeräte beschränken, während im allgemeinen Sinne der Internetkommunikation eine Reihe von hintereinander angeordneten Paketen zusammen eine sinnvolle Nachricht bilden. B. ein Bild oder eine Webseite.

Softwarekommunikation

In diesem Abschnitt wird das Konzept der Messaging-Kommunikation zwischen Softwaresystemen beschrieben. Im Gegensatz zur Gerätekommunikation, bei der die Form der Nachrichtendaten auf Protokolle beschränkt ist, die vom Typ und den Fähigkeiten der beteiligten Geräte unterstützt werden (z , und ein Beacon würde Morsecode-Sequenzen blinken lassen, die eine Person lesen könnte), kann eine Software komplexere und robustere Datenaustauschformate einrichten. Diese Formate würden von der sendenden Partei in eine von der zugrunde liegenden Hardware auslieferbare Form übersetzt und dann von der empfangenden Partei aus dem hardwarespezifischen Format in eine Form dekodiert, die dem ursprünglichen Protokoll entspricht, das von den kommunizierenden Softwaresystemen eingerichtet wurde. Dieser Datenaustausch auf höherer Ebene ermöglicht die Übertragung von Informationen in einer für den Menschen lesbareren Form und ermöglicht auch die Verwendung von Software-Verschlüsselungs- und -Entschlüsselungstechniken, um das Messaging sicher zu machen. Außerdem ermöglicht der Software-Nachrichtenaustausch mehr Variationen des Nachrichtenaustauschmusters, die nicht mehr auf einfache Anfrage-Antwort- und Einweg- Ansätze beschränkt sind. Und nicht zuletzt sind Software-Kommunikationssysteme in der Lage, verschiedene Kanäle für den Datenaustausch bereitzustellen , die zur Optimierung der Nachrichtenzustellung genutzt werden können, oder komplexe Regeln zur Auswahl und Filterung aufzustellen, die bei der Entscheidung helfen, wer bestimmte Nachrichten erhält. Dies ermöglicht die Möglichkeit für software-orchestriertes Nachrichten-Routing . Als Ergebnis der letzteren haben sich die Konzepte eines Themas (bei dem alle empfangenden Parteien in einer Zielgruppe eine Kopie der Nachricht zugestellt werden würden) und einer Warteschlange (bei der nur eine Partei in einer Zielgruppe die Nachricht erhalten würde) herausgebildet.

Wie bereits erwähnt, ermöglicht Software-Messaging mehr Optionen und Freiheit bei den Datenaustauschprotokollen. Dies wäre jedoch nicht sehr nützlich, es sei denn, die kommunizierenden Parteien einigen sich auf die Einzelheiten des beteiligten Protokolls, und daher existiert eine Reihe von standardisierten Software-Nachrichtenübermittlungsprotokollen. Diese Standardisierung ermöglicht es verschiedenen Softwaresystemen, die normalerweise von verschiedenen Organisationen erstellt und verwaltet werden und die auf verschiedenen Hardwaregeräten (Server, Computer, Smart Devices oder IoT-Controller) ausgeführt werden können, am Echtzeit-Datenaustausch teilzunehmen.

Im Folgenden sind einige der beliebtesten Software-Messaging-Protokolle aufgeführt, die noch heute verwendet werden. Jeder von ihnen bietet erweiterte Bedeutungen für das im vorherigen Abschnitt beschriebene Messaging-Konzept.

SEIFE

Der Begriff Nachrichtenaustauschmuster hat innerhalb des Simple Object Access Protocol ( SOAP ) eine erweiterte Bedeutung . Zu den SOAP MEP-Typen gehören:

1. In-Only : Dies ist äquivalent zu unidirektional . Ein standardmäßiger unidirektionaler Nachrichtenaustausch, bei dem der Verbraucher eine Nachricht an den Anbieter sendet, die nur eine Statusantwort bereitstellt.
2. Robust In-Only : Dieses Muster ist für einen zuverlässigen einseitigen Nachrichtenaustausch vorgesehen. Der Verbraucher initiiert mit einer Nachricht, auf die der Anbieter mit Status antwortet. Wenn die Antwort ein Status ist, ist der Austausch abgeschlossen, aber wenn die Antwort ein Fehler ist, muss der Verbraucher mit einem Status antworten.
3. In-Out : Dies entspricht Request–Response . Ein standardmäßiger bidirektionaler Nachrichtenaustausch, bei dem der Verbraucher mit einer Nachricht beginnt, der Anbieter mit einer Nachricht oder einem Fehler antwortet und der Verbraucher mit einem Status antwortet.
4. In-Optional-Out : Ein standardmäßiger bidirektionaler Nachrichtenaustausch, bei dem die Antwort des Anbieters optional ist.
5. Out-Only : Die Umkehrung von In-Only. Es unterstützt in erster Linie Ereignisbenachrichtigungen. Es kann keine Fehlermeldung auslösen.
6. Robust Out-Only : Ähnlich dem Out-only-Muster, außer dass es eine Fehlermeldung auslösen kann. Die ausgehende Nachricht leitet die Übertragung ein.
7. Out-In : Die Umkehrung von In-Out. Der Provider übermittelt die Anfrage und initiiert den Austausch.
8. Out-Optional-In : Die Umkehrung von In-Optional-Out. Der Dienst erzeugt eine ausgehende Nachricht. Die eingehende Nachricht ist optional ("Optional-in").

ØMQ

Die ØMQ Message Queuing Library bietet sogenannte Sockets (eine Art Verallgemeinerung gegenüber den traditionellen IP- und Unix-Sockets ), die die Angabe eines zu verwendenden Messaging-Musters erfordern und für jedes Muster optimiert sind. Die grundlegenden ØMQ-Muster sind:

• Request–Reply verbindet eine Reihe von Clients mit einer Reihe von Diensten. Dies ist einMuster füreinen Remoteprozeduraufruf und eine Aufgabenverteilung.
• Veröffentlichen–Abonnieren verbindet eine Reihe von Herausgebern mit einer Reihe von Abonnenten. Dies ist ein Datenverteilungsmuster.
• Push-Pull verbindet Knoten in einem Fan-Out / Fan-In-Muster, das mehrere Schritte und Schleifen haben kann. Dies ist ein paralleles Aufgabenverteilungs- und Sammlungsmuster.
• Exclusive Pair verbindet zwei Sockets in einem exklusiven Paar. Dies ist ein Low-Level-Muster für spezifische, fortgeschrittene Anwendungsfälle.

Jedes Muster definiert eine bestimmte Netzwerktopologie. Request-Reply definiert den sogenannten "Service Bus", Publish-Subscribe definiert "Data Distribution Tree", Push-Pull definiert "Parallelized Pipeline". Alle Muster sind bewusst so gestaltet, dass sie unendlich skalierbar und damit im Internet-Maßstab nutzbar sind.

SICH AUSRUHEN

Das REST- Protokoll ist ein Messaging-Protokoll, das auf dem HTTP-Protokoll aufgebaut ist und auf ähnliche Weise das Anforderungs-Antwort- Muster des Nachrichtenaustauschs verwendet. Während das Hauptziel von HTTP darin besteht, Webseiten und Dateien über das Internet bereitzustellen, die für einen menschlichen Endbenutzer bestimmt sind, wird das REST- Protokoll hauptsächlich für die Kommunikation zwischen verschiedenen Softwaresystemen verwendet und spielt eine Schlüsselrolle im Architekturmuster der Microservices- Software. Zu den bemerkenswerten Eigenschaften des REST-Protokolls gehört, dass es vielseitig genug ist, um Daten in vielen anderen Formaten (normalerweise JSON und XML) darzustellen, und dass es zusätzliche Metadaten-Deskriptoren für die von ihm repräsentierte Nachricht bereitstellt. Die Metadaten-Deskriptoren folgen den HTTP-Standards, indem sie als HTTP-Header dargestellt werden (die durch das zugrunde liegende HTTP-Protokoll standardisiert werden) und können daher als Anweisungen für die empfangende Partei zur Interpretation der Nachrichtennutzlast verwendet werden. Aus diesem Grund verbessert REST die Entwicklung eines Softwaresystems, das mit einem anderen Softwaresystem kommunizieren kann, erheblich, da die Entwickler nur das übergeordnete Format der Nachrichtennutzlast (das JSON- oder XML-Modell) kennen müssen. Die eigentliche HTTP-Kommunikation wird normalerweise von einer Softwarebibliothek oder einem Framework abgewickelt. Eine weitere großartige Eigenschaft des REST-Protokolls besteht darin, dass es geeignet ist, andere Protokollsemantiken darauf aufzubauen , wie das Beispiel bei HATEOAS ist .

Siehe auch

• Push-Technologie
• Verteilter Datenfluss
• Unternehmensintegrationsmuster

Verweise

Externe Links

• Messaging-Muster in einer serviceorientierten Architektur
• Muster zur Unternehmensintegration - Musterkatalog