© deomis/Shutterstock.com
Unter dem Druck der Ereignisse – Teil 6

MQTT – Events als Plattformwanderer


Freunde bzw. Advokaten der Event-orientierten Programmierung bewerben seit jeher, dass dieses Designparadigma den PT-Entwickler von Hostplattformen unabhängig macht. Wirklich sinnvoll wird das allerdings erst durch die Einführung des Microservices-Designparadigmas.

Bei der Arbeit an klassischen, monolithisch strukturierten Applikationen hat man als Entwickler nicht wirklich etwas von der Möglichkeit der Plattformwahl: Für das gesamte System, das normalerweise auf einem Server oder einer Gruppe von Servern arbeitet, muss man logischerweise ein Betriebssystem auswählen. Ein Microservices-basiertes System bricht diese alte Beziehung insofern auf, als es aus einer Gruppe von Minidiensten besteht. Häufig lebt jeder dieser Mikrodienste in einer Containerumgebung, weshalb das Auswählen des idealen Betriebssystems noch leichter ist. Zur Kommunikation zwischen diesen Diensten lässt sich dann Event-orientierte Programmierung einspannen. Sofern alle Beteiligten dasselbe Protokoll implementieren, muss man sich für die Anbindung nur noch darum kümmern, eine Verbindung zum Event Broker aufzubauen – sind die Payloads intelligent konstruiert und vermeidet man Probleme mit Endianness, Swizzeling und Co., wird die Arbeit stellenweise sogar richtig bequem.

Service Bus, zur Zweiten

Am Ende des letzten Teils hatten wir unsere Azure-Service-Bus-Applikation so weit fertiggestellt, dass sie Nachrichten in Richtung Backend senden konnte. In einem normalen Tutorial würde man an dieser Stelle einen weiteren in Visual Studio 2019 lebenden Client realisieren, der die Nachrichten wieder auf die Workstation herunterlädt. Wir wollen an dieser Stelle allerdings einen anderen Weg gehen. Das ThinkPad des Autors läuft mit Ubuntu 20.04 – ein ideales Opfer. Statt der Arbeit mit .NET Core wollen wir nun auf die Programmierumgebung Python setzen. Der Versionsstand auf der Workstation des Autors präsentiert sich nach diversen Liveupdates seit Version 14.04 folgendermaßen:

tamhan@tamhan-thinkpad:~$ python --version Python 2.7.18 tamhan@tamhan-thinkpad:~$ python3 --version Python 3.8.5

Obwohl Microsoft Python 2.7 noch unterstützt, werden wir im weiteren Verlauf mit Version 3 arbeiten. Die Bereitstellung der diversen Azure-SDKs für die Python-Arbeitsumgebung erfolgt ganz pythonisch über den Paketmanager pip. Als Problem erweist sich das Herausfinden der Namen der zu installierenden Pakete. Microsoft stellt eine Liste [1] zur Verfügung, in der wir im ersten Schritt nach dem Namen des benötigten Dienstes bzw. Pakets suchen. In unserem Fall benötigen wir „Service Bus“ – in der Tabelle finden wir danach einen nach dem Schema pypi <version> aufgebauten Link, den wir anklicken. Er führt zum in Abbildung 1 gezeigten Informationsfenster, das uns über den eigentlich einzugebenden Befehl informiert.

hanna_events_teil6_1.tif_fmt1.jpgAbb. 1: Presto: Azure Service Bus für Python

Im nächsten Schritt installieren wir die Bibliothek nach folgendem Schema:

tamhan@tamhan-thinkpad:~$ python3 -m pip install azure-servicebus Collecting azure-servicebus Downloading azure_servicebus-7.0.0-py2.py3-none-any.whl (185 kB)

Wichtig ist hier zweierlei: Erstens haben Python 2.x und Python 3.x voneinander unabhängige Bibliotheksspeicher, weshalb die Installation einer für Python 3 vorgesehenen Bibliothek ausschließlich über die Dreier-Version von pip erfolgen darf. Zweitens unterstützt Microsoft die systemweite Installation von Bibliotheken nicht. Das Azure-SDK funktioniert also nur dann, wenn man es auf Userebene einrichtet und installiert. Eine Python-Applikation ist ob ihrer Ausführung in der Python-Programmierumgebung nicht von der Anforderung befreit, sich ebenfalls gegenüber dem Azure-Backend auszuweisen. Analog zur .NET-Arbeitsumgebung kommt auch dabei ein Connection-String zum Einsatz. Erzeugen wir eine neue .py-Arbeitsdatei und deklarieren die benötigten Elemente nach folgendem Schema:

CONNECTION_STR = "Endpoint=sb://sustestnamespace. . . . TOPIC_NAME = "sustopic1" SUBSCRIPTION_NAME = "susexamplesubscription"

Sodann können wir mit der Realisierung des Testharnischs beginnen, der für den Datenempfang verantwortlich zeichnet. Er beginnt mit der Inklusion des Azure-Bibliotheksmoduls und kümmert sich quasi nebenbei auch um die Erzeugung des Clients:

from azure.servicebus import ServiceBusClient, ServiceBusMessage servicebus_client = ServiceBusClient.from_connection_string(conn_str=CONNECTION_STR, logging_enable=True)

Als nächste Amtshandlung müssen wir uns darum kümmern, einen Subscription-Receiver zu erzeugen und ihn nach und nach um die in ihm enthaltenen Nachrichten erleichtern. Das aus Visual Basic bekannte with-Kommando leistet an dieser Stelle insofern gute Dienste, als es uns vom manuellen Abtragen der diversen Instanzen und Objekte befreit (Listing 1).

Listing 1

servicebus_client = ServiceBusClient.from_connection_string(conn_str=CONNECTION_STR, logging_enable=True) with servicebus_client: receiv...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang