Einführung in synchrone und asynchrone Kommunikationskonzepte

06.11.2021

Abstract

Im Rahmen des Vorlesungsmoduls Advanced Manufacturing (kurz: AMAN) des Masterstudiengangs Wirtschaftsingenieurwesens an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt werden von den Studierenden Blogartikel zu verschiedenen Themen verfasst. Dieser Artikel liefert eine Einführung in synchrone und asynchrone Kommunikationsstile. Konkret werden Konzepte, wie das Request-Response-Modell, sowie Ausprägungen eines Messages Brokers in Form von Message-Queuing und Publish-Subscribe vorgestellt. Des Weiteren wird anhand der Open Source Message Broker Software RabbitMQ in Python ein einführendes Message-Queuing-Beispiel gegeben. Zu guter Letzt werden zusammenfassend einige Vor- und Nachteile der in diesem Blogartikel behandelten Kommunikationsstile aufgezeigt.

Keywords: Request-Response-Modell, Message-Queuing, Publish-Subscribe, Message Broker, Anwendungsbeispiel, Vor- und Nachteile

Einleitung

Sender, Empfänger und Nachrichten – nicht nur Menschen nutzen diesen Kern von Kommunikationsstrukturen, sondern auch Softwareanwendungen greifen auf diese Struktur zurück, um den Austausch unter Systemen zu ermöglichen. Je nachdem, welche Bedürfnisse die Systeme haben, variiert dabei die Art und Weise, wie die Systeme miteinander sprechen (Dossot 2014, S. 7). Daher können unterschiedliche Kommunikationsstile unterschieden werden. Übergeordnet lassen sich diese Konzepte in synchrone und asynchrone Kommunikation unterteilen. Ob Mensch oder Softwareanwendung, synchrone Kommunikation setzt eine gleichzeitige Aktivität/Anwesenheit von Sender und Empfänger voraus, wohingegen bei asynchroner Kommunikation der Empfänger seine Aufmerksamkeit nicht unmittelbar zur Verfügung stellen muss und dementsprechend keine gleichzeitige Aktivität/Anwesenheit notwendig ist. Praxisnahe und anschauliche Beispiele dieser beiden Kommunikationskonzepte sind u.a. Telefonanrufe (synchrone) oder E-Mails (asynchron). (Wilde und Buriticá 2021; SAP o.J.)

Wie diese beiden Kommunikationsstile im Kontext von Softwareanwendungen aussehen können, wird im Folgenden dargestellt.

Unterschiedliche Kommunikationskonzepte: Synchrone und asynchrone Kommunikation

In diesem Kapitel wird nun genauer auf synchrone Kommunikation in Form des Request-Response-Modells eingegangen. Für die asynchrone Kommunikation werden die Modelle Message Queuing und Publish-Subscribe genauer erläutert.

Synchrone Kommunikation – Request-Response-Modell

Im Rahmen der synchronen Interaktion, ist die Anfrage-Antwort-Interaktion (engl. Request-Response-Interaction) mit der gebräuchlichste Stil (Dossot 2014, S. 8; Femia 2018). Hierbei kommuniziert ein System mit einem anderen entfernten System per Direktverbindung, d.h. auf einer Punkt-zu-Punkt-Basis (engl. point-to-point, kurz: P2P), sodass beide Seiten einander kennen (Dossot 2014, S. 8; Lipinski et al. 2020). Konkret wartet, wie in Abbildung 1 dargestellt, ein Server (=Dienstanbieter), nachdem er entsprechend gestartet wurde, auf das Eintreffen einer Anfrage des Clients (=Dienstnutzer). Sobald dies der Fall ist, erbringt der Server den erwünschten Dienst und meldet eine synchrone Antwort an den Client zurück (Heinzl und Mathes 2005, S. 71–73; Dossot 2014, S. 8). Gemäß der einleitend beschriebenen Definition von synchroner Kommunikation, stellt der Server somit dem Client zeitnah nach dem Erreichen der Anfrage seine Aufmerksamkeit zur Verfügung. Da sowohl für die Anfragen, als auch für Antworten ein point-to-point-Kanal verwendet wird, kann in diesem Kontext von einem bidirektionalen Austausch gesprochen werden (Solace Corporation 2021).

Ein praxisnahes und hier vereinfachtes Beispiel in diesem Zusammenhang bietet der Abruf eines Webseiteninhalts. Dabei richtet ein Web-Browser (Client) einen Request an den Webserver und fragt bei diesem ein HTML-Dokument, d.h. z.B. den Webseiteninhalt, an. Der Webserver überträgt anschließend in Form der Response das gewünschte Dokument an den Web-Browser (Client). (Lipinski et al. 2019)

Asynchrone Kommunikation

Nachdem zuvor die Grundsätze der synchronen Kommunikation beschrieben wurden, wird nun der Fokus auf die asynchrone Kommunikation gelegt. Im Kontext dieser einseitigen Interaktion kommunizieren die Systeme, wie in Abbildung 2 dargestellt, asynchron durch die Übermittlung von Nachrichten von sogenannten Nachrichtenvermittlern (engl. Message Brokern). Konkret übermittelt dieser Broker eine Nachricht, die er von einem Herausgeber (engl. Publisher) erhalten hat, an den oder die entsprechend vorgesehenen Empfänger/Konsumenten/Abonnenten (engl. Consumer/Subscriber) weiter (Dossot 2014, S. 8; Femia 2018). Der Message Broker agiert somit als eine nachrichtenorientierte Middleware[1]. (Lithmee 2019; Garvie 2021)

Es ist dabei grundsätzlich möglich, dass nach der Übermittlung der ursprünglichen Nachricht eine Antwort erforderlich ist. Dies erfolgt dann anhand des gleichen Mechanismus, jedoch in umgekehrter Reihenfolge, d.h. Publisher und Consumer tauschen ihre Rollen. (Dossot 2014, S. 8)

Das in Abbildung 2 dargestellte Kommunikationskonzept über einen Message Broker kann allerdings noch weiter spezifiziert werden. Zwei diesbezügliche Ausprägungen in Form von Message Queuing und Publish-Subscribe, diese werden in den beiden folgenden Teilkapiteln detaillierter vorgestellt.

Message Queuing

Unter Nachrichtenwarteschlangen (engl. Message Queues) wird ein Kommunikationskonzept verstanden, bei dem Sender und Empfänger über eine Warteschlange ihre Nachrichten austauschen. Hierbei wird die Nachricht im P2P-Modell übermittelt. Wie bereits angedeutet, dient der Message Broker als nachrichtenorientierte Middleware, der hier die Queue zur Verfügung stellt. Hierbei sendet der Publisher seine Nachrichten an die definierte Queue des Message Brokers. Dort werden die Nachrichten in der Reihenfolge des Eintreffens abgelegt (vgl. Abbildung 3). (Lithmee 2019; Garvie 2021)

Sollte ein Empfänger mit der Queue schon verbunden sein (z.B. der in Abbildung 4 dargestellte Consumer A), kann er die in der Warteschlange liegenden Nachrichten empfangen. Hierbei erhält das konsumierende System A immer die Nachrichten nach dem First-In-First-Out-Prinzip (kurz: FIFO). Diese empfangenen Nachrichten werden dann sofort endgültig aus der Queue genommen. (Garvie 2021) Die Folge dieses Mechanismus ist, dass immer nur ein Empfänger die Nachricht konsumieren kann, da die Nachrichten nicht für immer in der Queue gespeichert bleiben (Solace Corporation 2021; Heinzl und Mathes 2005, S. 215). Im Beispiel aus Abbildung 4 würde somit Consumer B die Nachricht m₁ nicht mehr erhalten, da sie bereits an Consumer A geleitet wurde. Im Fall, dass kein Empfänger mit der Queue verbunden ist, werden die Nachrichten so lange dort abgelegt, bis ein Empfänger sie dort abruft (RabbitMQ o.J.). Für dieses Kommunikationskonzept wird im späteren Verlauf noch ein kurzes Anwendungsbeispiel aufgezeigt (vgl. Anwendungsbeispiel zu Message Queuing).

Die Verwendung von Warteschlangen ist in einer Mikro-Service-Architektur[2] und bei der Entwicklung von cloudbasierten oder serverlosen Anwendungen beliebt. Denn mit diesem Konzept lassen sich Anwendungen je nach Auslastung horizontal skalieren. Zudem wird es häufig dafür eingesetzt, wenn sichergestellt werden soll, dass ein Dienst die Arbeit wirklich nur einmal ausführt. (Garvie 2021)

Publish-Subscribe-Kommunikation

Im Vergleich zum zuvor beschriebenen Konzept des Message Queuings ist mit der Publish-Subscribe-Kommunikation (kurz: Pub-Sub) die Distribution einer Nachricht an mehrere Konsumenten möglich (vgl. Abbildung 5 und Abbildung 6), wobei in dieser Architektur der Message Broker weiterhin als nachrichtenorientierte Middleware anzusehen ist (Lithmee 2019; Garvie 2021). Hierzu ist es jedoch erforderlich, dass ein oder mehrere interessierte Konsumenten ein bestimmtes Thema (engl. Topic) abonnieren (engl. Subscribe). Die Konsumenten können daher auch Abonnenten (engl. Subscriber) genannt werden. Sofern ein (oder ggf. mehrere) Produzenten/Publisher eine Nachricht zu einem bestimmten Topic veröffentlichen, bekommen sämtliche zugehörigen Abonnenten eine Nachricht zugestellt. Dies ist ähnlich wie beim Broadcasting. (Heinzl und Mathes 2005, S. 216)

Ist ein bestimmter Abonnent nicht verfügbar, während die Nachricht veröffentlicht wird, erhält er grundsätzlich keine Kopie dieser Nachricht. Sofern dies vermieden, werden soll, ist es allerdings möglich, ein sogenanntes dauerhaftes Abonnement (engl. Durable Subscriber) einzurichten. Hierdurch erfolgt eine Zwischenspeicherung sämtlicher Nachrichten, die im Zuge der Inaktivität eines Abonnenten veröffentlicht wurden. Direkt wenn der Abonnent wieder aktiv ist, bekommt er dann alle entgangenen Nachrichten zugesendet. (Heinzl und Mathes 2005, S. 216) Der Message Broker ist beim Pub-Sub-Prinzip grundsätzlich dafür verantwortlich, dass sämtliche Konsumenten die Nachrichten bekommen, für dessen Topic sie ein Abonnement getätigt haben. Dies ist ein bedeutender Unterschied zum Message Queuing. Im Einsatz der Architekturgestaltung bietet Pub-Sub ebenfalls, wie Message Queuing, eine horizontale Skalierbarkeit[3]. (Garvie 2021)

Anwendungsbeispiel zu Message Queuing

Nachdem verschiedene Ausprägungen von synchronen und asynchronen Kommunikationskonzepten vorgestellt wurden, wird nun ein veranschaulichendes Beispiel zum Thema Message Queuing gegeben. Dieses Beispiel wird in Anlehnung an RabbitMQ (o.J.) mithilfe der Open Source Message Broker Software RabbitMQ in Python dargestellt. Es wird dabei davon ausgegangen, dass die erforderliche Software RabbitMQ und Erlang auf dem PC installiert sind. Sollte diese nicht der Fall sein, kann für RabbitMQ die Installation unter https://www.rabbitmq.com/download.html und für Erlang unter https://www.erlang.org/downloads erfolgen.

Zudem gilt es zu dem Anwendungsbeispiel zu sagen, dass dies in der Entwicklungsumgebung Anaconda umgesetzt wurde und darauf die Beispielbeschreibung aufbaut.

Senden – send.py

Im ersten Schritt des Beispiels muss das pika package über die Powershell Prompt heruntergeladen werden. Pika ist eine reine Python Implementierung des  Advanced Message Queuing Protocol (kurz: AMQP) Protokolls, welches versucht unabhänigig von der zugrunde liegenden Netzwerkunterstützungsbibliothek zu bleiben (Garnock-Jones und Roy 2015). Allgemein kann RabbitMQ eine vielzahl an Protokollen sprechen (RabbitMQ o.J.). Hierzu muss die Powershell geöffnet werden und folgender Befehl eingegeben werden:

python -m pip install pika --upgrade

Sollte dieser Schritt erfolgreich abgeschlossen sein, kann nun eine Python-Entwicklungsumgebung (z.B. Spyder oder jupyter) gewechselt werden. Hier kann das erste Programm send.py erstellt werden. Dabei muss zuerst die zuvor installierte Bibliothek pika importiert werden. Als Nächstes wird eine Verbindung zum Message Broker aufgebaut, da das Beispiel lokal auf dem Rechner durchgeführt wird, wird die Adresse localhost eingetragen. Für Beispiele, die nicht lokal dargestellt werden, kann hier jede andere IP-Adresse entsprechend eintragen werden.

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))

channel = connection.channel() 

Als nächster Schritt muss eine Queue angelegt und definiert werden. Im Beispiel (bzw. wie in Abbildung 3 aufgezeigt) heißt diese Queue.

channel.queue_declare(queue='Queue')

Nun ist es möglich eine Nachricht zu senden. Damit die Nachricht in der richtigen Queue ankommt, wird dies über den routing_key definiert und im body der Inhalt der Nachricht gespeichert. Um eine variable Eingabe bewerkstelligen zu können, wird über input eine beliebige Eingabe in die Variable message ermöglicht. Wurde die Nachricht eingeben wird durch einen Printbefehl, die gesendete Nachricht ausgeben.

message=input('Geben Sie Ihre Nachricht ein:' )

channel.basic_publish(exchange='',

                     routing_key='Queue',

                      body= message)

print(' [x] Sent '+ message +'!')

Sollen noch weiter Details angezeigt werden, z. B. wie viele Nachrichten in der Queue liegen, kann das Programm um folgenden Code erweitert werden:

print(channel.queue_declare(queue='Queue'))

Zum Schluss muss die Verbindung zum Message Broker wieder getrennt werden.

connection.close

Empfangen – receiving.py

Das zweite Programm receiving.py soll nun dazu dienen, die gesendeten Nachrichten, die auf der Queue liegen zu konsumieren. Hierfür muss zu Beginn die Pakete pika, sys, os importiert werden:

import pika, sys, os

Im ersten Schritt muss wie im ersten Programm die Verbindung zum Message Broker aufgebaut werden. Optional kann der Befehl queue_declare (vgl. Kommentierung im Code) ergänzt werden. Hierrüber kann sichergestellt werden, sofern das Programm receiving.py zuerst laufen sollte, dass eine Queue auf dem Message Broker erstellt wird. Sollte eine Queue schon bestehen, wird der Befehl von RabbitMQ ignoriert.

connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))

channel = connection.channel()

#channel.queue_declare(queue='Queue')

Nun kann die Callback-Funktion aus der pika Bibliothek dazu genutzt werden, um die Nachrichten von der erstellten Queue abzurufen. Für jede erhaltene Nachricht wird eine Ausgabe angezeigt. Zudem muss über channel.basic_consume Parameter angegeben werden, wie die Nachrichten konsumiert werden sollen (z.B. aus welcher Queue). Dieses Teilprogramm ist als eine dauerhafte Schleife geschrieben und konsumiert so lange den Message Broker bzw. die Queue, bis die Verbindung unterbrochen wird.

def callback(ch, method, properties, body):

   print(" [x] Received %r" % body)

channel.basic_consume(queue='Queue', on_message_callback=callback, auto_ack=True)

print(' [*] Waiting for messages. To exit press CTRL+C')

channel.start_consuming

Um die Schleife zu unterbrechen wird folgende Logik implementiert. Mit dieser ist es möglich über die Eingabe STRG+C, den Loop abzubrechen (vgl. hierzu Hinweis im Printbefehl print(' [*] Waiting for messages. To exit press CTRL+C').

if __name__ == '__main__':

    try:

        main()

    except KeyboardInterrupt:

        print('Interrupted')

        try:

            sys.exit(0)

        except SystemExit:

            os._exit(0)

Nun ist es möglich, die beiden Programme über Powershell oder die eingangs erwähnten Entwicklungsumgebungen auszuführen und zu testen, ob die eingegebene Nachricht im Programm send.py vom Programm receiving.py abgerufen werden kann.

Die beiden erstellten Dateien send.py und receiving.py können nochmals zusammenfassend wie folgt dargestellt werden.

Send.py

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))

channel = connection.channel()

channel.queue_declare(queue='Queue')

message=input('Geben Sie ihre Nachricht ein: ' )

channel.basic_publish(exchange='',

                      routing_key='Queue',

                      body= message)

print(' [x] Sent '+ message +'!')

#print(channel.queue_declare(queue='Queue'))  #for more Details

connection.close()  #in jupyter notebook please use an extra cell for this command

Receiving.py

import pika, sys, os

def main(): 

    connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))

    channel = connection.channel()

    channel.queue_declare(queue='Queue')

    def callback(ch, method, properties, body):

        print(" [x] Received %r" % body)

    channel.basic_consume(queue='Queue', on_message_callback=callback, auto_ack=True)

    print(' [*] Waiting for messages. To exit press CTRL+C')

    channel.start_consuming()

if __name__ == '__main__':

    try:

        main()

    except KeyboardInterrupt:

        print('Interrupted')

        try:

            sys.exit(0)

        except SystemExit:

            os._exit(0)

Die nachfolgenden Abbildungen zeigen nochmals die Ergebnisse des hier beschriebenen Anwendungsbeispiels unter Bezugnahme auf die theoretischen Ausführungen in Abbildung 3 und Abbildung 4. In Abbildung 7 und Abbildung 8 werden entsprechend der erstellten sender.py (hier dargestellt über jupyter) einzelne Nachrichten im Sinne eines Publishers an den Message Broker weitergegeben. Abbildung 9 hingegen demonstriert einen Consumer anhand der aufbereiteten reiceiving.py (hier dargestellt über die Entwicklungsumgebung Spyder).

Fazit / Vor- und Nachteile

Zusammenfassend kann gesagt werden, dass, sobald eine Kommunikation eine zeitliche Anforderung auf eine Antwort besitzt, Request-Response eingesetzt werden sollte. Für Kommunikationen, die horizontal skalierbar sein sollten, ist Message-Queuing oder Pub-Sub zu empfehlen. Für die detailliertere Entscheidung, ob Message Queuing oder Pub-Sub, sollte sich folgende Frage gestellt werden: „Ist es wichtig, dass jeder Konsument jede Nachricht erhält?“ (Garvie 2021). Zusammenfassend werden hierzu auch noch einmal Vor- und Nachteile der zuvor vorgestellten Kommunikationskonzepte in nachfolgender Tabelle 1 dargestellt:

Tabelle 1: Vor- und Nachteile synchroner und asynchroner Kommunikationsstile (Quelle: eigene Darstellung in Anlehnung an Garvie (2021), Solace Corporation (2021), Lithmee (2019), Dossot (2014), Heinzl und Mathes (2005), Amazon Web Services (o.J.))

Synchrone Kommunikation		Asynchrone Kommunikation
Request-Response		Message Queuing		Pub-Sub
Vorteile	Nachteile	Vorteile	Nachteile	Vorteile	Nachteile
Einfaches Programmiermodell aufgrund von prozessualem Ablauf.	Enge Kopplung zwischen beiden Parteien wirkt sich stark auf Architektur des Gesamtsystems aus, sodass Entwicklung erschwert wird. Dementsprechend sind Skalierungseffekte schwerer realisierbar.	Nachrichtenorientierte Middleware, die die Nachricht so lange hält, bis der Empfänger bereit/aktiv ist (Stichwort: Persistenz bzw. Puffer). Beim Message Queuing erfolgt eine stärkere Stapelung der Nachrichten, als beim Pub-Sub-Prinzip.	Keine Rückmeldung, ob Nachricht angekommen ist, ggf. Verluste. Eine Rückmeldung erfordert gleichen Prozess in umgekehrter Reihenfolge.	Lose Kopplung der beiden miteinander kommunizierenden Systeme.	Keine Rückmeldung, ob Nachricht angekommen ist, ggf. Verluste. Eine Rückmeldung erfordert gleichen Prozess in umgekehrter Reihenfolge.
Kommunikation in heterogener Umgebung (d.h. trotz möglicher unterschiedlicher Rechner- und Betriebssysteme) möglich.	Feste Verbindung zwischen Client und Server. Daraus folgt erhöhter Konfigurationsaufwand bei Änderungen.	Bei der Verwendung von Nachrichten-Warteschlangen kann bei Ausfall einer Verbraucheranwendung ein anderer Verbraucher die Nachricht stattdessen verarbeiten. Dadurch ist auch eine leichtere Wartung möglich. Dies ist auch ein wesentlicher Aspekt der Mikro-Service-Architektur bzw. von cloudbasierten/serverlosen Anwendungen.	Keine prozedurale Programmierung, bei dem Dinge sofort nacheinander ablaufen. Hierunter kann Transparenz leiden.	Individuelle Weiterentwicklung der verschiedenen Systeme möglich, da Übersetzung dem Message Broker anvertraut wird. Dies ist auch ein wesentlicher Aspekt der Mikro-Service-Architektur bzw. von cloudbasierten/ serverlosen Anwendungen.	Keine prozedurale Programmierung, bei dem Dinge sofort nacheinander ablaufen. Hierunter kann Transparenz leiden.
Interaktion zwischen beiden Seiten klar festgelegt.	Bei Datenverlust muss eine komplett neue Anfrage gestellt werden.	Horizontale Skalierungseffekte können realisiert werden.		Horizontale Skalierungseffekte können realisiert werden.
	Bei zeitversetzter Aktivierung von Client und Server kann sogenanntes Rendezvous-Problem entstehen. D.h. Client und Server finden sich aufgrund des Zeitversatzes nicht und werden vorzeitig beendet.	Mehrere Empfänger, jedoch Nachricht nur von einem Empfänger abrufbar.		Message Broker führt gewisse Anonymität ein, da Publisher und Consumer nichts über Standort oder Technologie der jeweils anderen Seite wissen.
	Unter der möglichen Kommunikation in heterogener Umgebung leidet möglicherweise die Transparenz.	Individuelle Weiterentwicklung der verschiedenen Systeme möglich, da Übersetzung dem Message Broker anvertraut wird. Dies ist auch ein wesentlicher Aspekt der Mikro-Service-Architektur bzw. von cloudbasierten/serverlosen Anwendungen.		Nachrichtenorientierte Middleware trägt Verantwortung für das Halten und Versenden der Nachrichten an die Abonnenten, wobei grundsätzlich eine geringe Stapelung der Nachrichten als beim Message Queuing verfolgt wird. Durch Einrichtung eines dauerhaften Abonnements (engl. Durable Subscriber) kann jedoch ebenfalls Persistenz bzw. eine Pufferung erreicht werden.
	In Praxis ist klare Trennung zwischen Client und Server nicht immer möglich, da bspw. ein Server gleichzeitig ein Client im Rahmen eines anderen Systems sein kann.	Publisher benötigen weniger Informationen des Consumers (im Vergleich zu Request-Response-Prinzip).		Auch bei der Verwendung des Pub-Sub-Prinzips kann grundsätzlich bei Ausfall eines Subscribers ein anderer Subscriber die Nachricht verarbeiten. Dadurch ist auch hier eine leichtere Wartung möglich. Dies ist auch ein wesentlicher Aspekt der Mikro-Service-Architektur bzw. von cloudbasierten/ serverlosen Anwendungen.
				Mehrere Empfänger für eine Nachricht möglich. Dadurch können die Empfänger mit der gleichen Nachricht verschiedene Aufgaben parallel absolvieren.
				Abonnenten können bei Topics Filterung einstellen, wodurch die Flexibilität erhöht wird.

________________________________________

[1] Eine Middleware lässts sich als Werkzeug bzgl. der Übersetzung zweier Sprachen einordnen. Oft wird diese auch als Übersetzungsebene bezeichnet, welche eine Kommunikation und Verwaltung von Daten ermöglicht – auch dann, wenn die betroffenen Anwendungen inkompatibel sind (Karlstetter 2017).

[2] Microservices sind ein Architekturkonzept der Anwendungsentwicklung. Sie unterscheiden sich von monolithischen Ansätzen in der Art und Weise, wie ihre Kernfunktionen aufgeschlüsselt werden. Konkret können hier jede Funktion bzw. jeder Service unabhängig entwickelt bzw. implementiert werden, sodass individuelle Services ohne Beeinflussung anderer Services funktionieren können. Ein einfaches Beispiel für ist die Funktion Produktsuche in einem Online-Shop.(Red Hat 2021)

[3] In diesem Zusammenhang bedeutet eine horizontale Skalierbarkeit, dass sowohl auf der Publisher- als auch auf der Consumer-/Subscriber-Seite flexible Erweiterungen oder Reduzierungen vorgenommen werden können.

Literaturverzeichnis

Amazon Web Services (o.J.): What is Pub/Sub Messaging? Online verfügbar unter https://aws.amazon.com/de/pub-sub-messaging/?nc1=h_ls, zuletzt geprüft am 02.11.2021.

Dossot, David (2014): RabbitMQ essentials. Hop straight into developing your own messaging applications by learning how to utilize RabbitMQ. Birmingham, England: Packt Publishing. Online verfügbar unter http://site.ebrary.com/lib/alltitles/Doc?id=10868174.

Femia, Jean (2018): Request-response vs. publish-subscribe, part 1: What’s the diff? Online verfügbar unter https://blog.opto22.com/optoblog/request-response-vs-pub-sub-part-1, zuletzt aktualisiert am 08.02.2018, zuletzt geprüft am 28.10.2021.

Garnock-Jones, Tony; Roy, Gavin M. (2015): Introduction to Pika. Hg. v. Pivotal Software (0537c8f3). Online verfügbar unter https://pika.readthedocs.io/en/stable/, zuletzt geprüft am 14.11.2021.

Garvie, Liam (2021): Pub-Sub vs. Message Queues. Hg. v. Baeldung. Online verfügbar unter https://www.baeldung.com/pub-sub-vs-message-queues, zuletzt geprüft am 29.10.2021.

Heinzl, Steffen; Mathes, Markus (2005): Middleware in Java. Wiesbaden: Vieweg+Teubner Verlag.

Karlstetter, Florian (2017): Was ist Middleware? Hg. v. Cloudcomputing Insider. Online verfügbar unter https://www.cloudcomputing-insider.de/was-ist-middleware-a-611085/, zuletzt aktualisiert am 02.06.2017, zuletzt geprüft am 02.11.2021.

Lipinski, Klaus; Lackner, Hans; Laué, Oliver P.; Kafka, Gerhard; Niemann, Alexander; Raasch, Eberhard et al. (2019): Request-Response-Verfahren. Hg. v. ITWissen.info. Online verfügbar unter https://www.itwissen.info/Request-Response-Verfahren-request-response-method.html, zuletzt aktualisiert am 12.03.2019, zuletzt geprüft am 02.11.2021.

Lipinski, Klaus; Lackner, Hans; Laué, Oliver P.; Kafka, Gerhard; Niemann, Alexander; Raasch, Eberhard et al. (2020): Punkt-zu-Punkt-Verbindung (PzP). Hg. v. ITWissen.info. Online verfügbar unter https://www.itwissen.info/P2P-point-to-point-PzP-Punkt-zu-Punkt-Verbindung.html, zuletzt aktualisiert am 08.01.2020, zuletzt geprüft am 28.10.2021.

Lithmee (2019): What is the Difference Between Queue and Topic. Online verfügbar unter https://pediaa.com/what-is-the-difference-between-queue-and-topic/, zuletzt geprüft am 29.10.2021.

RabbitMQ (o.J.): „Hello World!“. Online verfügbar unter https://www.rabbitmq.com/tutorials/tutorial-one-python.html, zuletzt geprüft am 24.10.2021.

Red Hat (2021): Microservices. Was sind Microservices? Online verfügbar unter https://www.redhat.com/de/topics/microservices/what-are-microservices, zuletzt geprüft am 02.11.2021.

SAP (o.J.): Arten der Message-Übermittlung. Online verfügbar unter https://help.sap.com/doc/saphelp_me60/6.0.4/de-DE/47/9bc9f265a9484be10000000a421138/content.htm?no_cache=true, zuletzt geprüft am 24.10.2021.

Solace Corporation (2021): Message Exchange Patterns. Online verfügbar unter https://docs.solace.com/PubSub-Basics/Core-Concepts-Message-Models.htm#Point-to, zuletzt aktualisiert am 26.10.2021, zuletzt geprüft am 28.10.2021.

Wilde, Katie; Buriticá, Juan Pablo (2021): Synchronous vs. Asynchronous Communication. Online verfügbar unter https://www.holloway.com/g/remote-work/sections/synchronous-vs-asynchronous-communication, zuletzt aktualisiert am 16.06.2021, zuletzt geprüft am 24.10.2021.