| 

.NET C# Java Javascript Exception

7
[Vorbemerkung: Teil 3 erscheint wegen seines Umfangs, in mehreren Folgen] Hallo zusammen, heute möchte ich meine Deep Dive Artikelserie, zur Azure IoT Solution Architecture fortsetzen. In der letzten Folge hatten wir uns mit dem Segment Field und denn darin enthaltenen Element (IoT) Devices beschäftigt. Nun werden wir das Bild etwas erweitern und auch das Segment […]

[Vorbemerkung: Teil 3 erscheint wegen seines Umfangs, in mehreren Folgen]

Hallo zusammen,

heute möchte ich meine Deep Dive Artikelserie, zur Azure IoT Solution Architecture fortsetzen.

In der letzten Folge hatten wir uns mit dem Segment Field und denn darin enthaltenen Element (IoT) Devices beschäftigt.

Nun werden wir das Bild etwas erweitern und auch das Segment Cloud Gateway in die Betrachtungen mit einbeziehen. Damit verlassen wir dann auch die reine Hardwareebene und beziehen erstmals Azure mit ein.

Ok, bevor ihr fragt: Cloud Gateway ist ein abstraktes Element aus der Architekturbeschreibung und bezeichnet kein konkretes Produkt. Wenn ich also vom Cloud Gateway rede, ist als Produkt ein Azure IoT Hub und / oder ein Azure Event Hub gemeint.


Wie ihr sehen könnt, haben wir jetzt ein schon viel komplexeres Bild. Eigentlich so komplex, dass wir es für unsere Betrachtungen noch einmal splitten werden.

a)

b)

c)

Nun stellt sich die Frage: Womit fangen wir an?

Der Gegenstand unserer heutigen Betrachtungen, sind die Kommunikationswege (Communication Paths) zwischen den Segmenten, in unserer Abbildung als schwarze Pfeile dargestellt.

Wenn ihr genau hinschaut seht ihr, dass die schwarzen Pfeile meistens in beide Richtungen zeigen. Man spricht dann von Bi-Directional Communication. Der Kommunikationsweg vom Device zur Cloud wird auch als Device-to-Cloud Messaging bezeichnet. Bei Device-to-Cloud Messaging werden Telemetrie Daten zur Verarbeitung oder ein Eventauslöser übertragen. Der umgekehrte Kommunikationsweg von der Cloud zum Device wird als Cloud-to-Device Messaging bezeichnet. Der Begriff Messaging ist dabei allerdings irreführend, da keine Nachrichten übermittelt werden sondern in der Regel nur Befehle (Commands).

Ok, in der „Teilabbildung a“ findet ihr auch einen schwarzen Pfeil der in nur eine Richtung zeigt. Dies ist eine Uni-Directional Communication und tritt immer dann auf, wenn euer IoT Szenario nur auf den Einsatz des Azure Event Hubs basiert. Der Einsatz des Azure Event Hubs erlaubt nur Device-to-Cloud Messaging.

Jetzt machen wir einen  kurzen Break und betrachten erst einmal einen weiteren Aspekt der Kommunikation: Den Kommunikationsprotokollen, die in unserer Architektur zum Einsatz kommen.

Bei der direkten Kommunikation, also zwischen Device und Cloud bzw. umgekehrt, kommen folgende Protokolle zum Einsatz:

AMQP (Advanced Message Queuing Protocol) – AMQP ist ein offener Standard und stellt ein binäres Netzwerkprotokoll auf Anwendungsebene für eine Message-orientierte Middleware (MOM) bereit

MQTT (MQ Telemetry Transport oder Message Queue Telemetry Transport) – MQTT ist ein offenes Protokoll für M2M (Machine – to -Machine) Kommunikation, das die Übertragung von Telemetrie Daten zwischen Geräten ermöglicht. Hohe Latenzen oder beschränkte Netzwerkaktivität,  sind dabei kein Problem.

Hinweis 1: Bei der Kommunikation mit AMQP und MQTT ist auch die sog. Verbindung „over WebSockets“ möglich.

Hinweis 2: MQTT steht beim Standalone Einsatz von Azure Event Hubs nicht zur Verfügung.

HTTP (Hypertext Transfer Protocol) – HTTP ist ein zustandsloses Protokoll zur Übertragung von Daten auf die Anwendungsschicht über ein Rechnernetz. Es wird hauptsächlich eingesetzt, um Webseiten aus dem Internet in einen Webbrowser zu laden. Es ist jedoch nicht prinzipiell darauf beschränkt und wird auch als allgemeines Dateiübertragungsprotokoll verwendet

Hinweis 3: HTTP sollte nur dann genutzt werden, wenn keine Alternative verfügbar ist, denn HTTP bietet zurzeit keine effiziente Methode zum Implementieren von Server Push. Daher fragen Devices, bei der Verwendung von HTTP, den Azure IoT Hub mindestens alle 25 Minuten nach C2D – Messages ab.

Kommen wir zu den Bildern zurück, diesmal zur „Teilabbildung b„.

Möglicherweise kommt ihr in die Lage, dass ihr nicht eines dieser Protokolle in Reinform verwenden könnt und ihr benötigt eine Protokollanpassung. Das ist dann die Stunde des Protocol Gateways (Protocol Adapter Gateways).

Für die Azure IoT Plattform wird das Protocol Adapter Gateway, als Open Source Projekt „Azure IoT – Protocol Gateway“ auf GitHub (hier) angeboten.

Betrachten wir das Azure IoT – Protocol Gateway einmal näher:

Das Azure IoT-Protokoll Gateway ist ein Framework zur Protokollanpassung für den Azure IoT Hub. Das Protokoll Gateway ist eine Komponente, die Geräteverbindungen über ein bestimmtes Protokoll akzeptiert und für den Datenverkehr mit dem Azure IoT Hub  als Brücke (Bridge) fungiert.

Das Protokollgateway wird in Azure in Form von Cloud Services Worker Roles und neuerdings auch als Microservice (Azure Service Fabric) bereitgestellt. Darüber hinaus kann das Protocol Gateway auch in einer On Premises Umgebung breitgestellt werden.

Das Azure IoT-Protokoll Gateway enthält einen MQTT-Adapter, um die Kommunikation mit Geräten über ein angepasstes MQTT  Protocol ermöglicht.

Dieser MQTT-Adapter dient als Beispiel, um euch das Programmiermodell zum Erstellen von Protokolladaptern für andere Protokolle zu veranschaulichen.

[Fortsetzung folgt]

Schöne Grüße

Oliver


news microsoft-azure iot azure-architecture
Schreibe einen Kommentar:
Themen:
azure-architecture iot microsoft-azure news
Entweder einloggen... ...oder ohne Wartezeit registrieren
Benutzername
Passwort
Passwort wiederholen
E-Mail