Die Summe ist mehr als die Teile: Orchestrierung für das Internet der Dinge

Es gibt viele Entwicklungen, die neue Ansätze für die Architekturen von Systemen erfordern. Einerseits steigt die Komplexität von Produkten, wodurch es unumgänglich wird, so viel wie möglich zu kapseln. Dazu hatte ich vor kurzem bereits ein paar Gedanken veröffentlicht. Dabei ging es jedoch primär um Produkte, die sich zur Laufzeit nicht verändern.

Heute geht es um die Architekturen für Produkte, bei denen erwartet wird, dass diese sich zur Laufzeit ändern. Ohne den Begriff überstrapazieren zu wollen, das trifft insbesondere um das Internet der Dinge (IoT) zu. Es geht also um eigenständige, lose gekoppelte Systeme, die zur Laufzeit kommunizieren. Beispiele umfassen Hausautomatisierung, bis zu kollaborierenden Fahrzeugen, zum Beispiel für Parkplatzsuche oder Platoon-Fahrten. Hier wird eine Orchestrierung der Teile notwendig.

Auch für solche Systeme muss gekapselt werden. Aber hier geht es noch weiter: Das Zusammenspiel der Systeme muss orchestriert werden. Die Grundlagen dafür wurden schon vor über 20 Jahren gelegt.

Service-Oriented Architectures

Eine mögliche Architektur für lose gekoppelte Systeme sieht diese Als Anbieter von Diensten (Services). Dementsprechend werden diese als „Service-Oriented Architectures“ bezeichnet. Die Idee, Dienste zu koppeln, gibt es schon lange. Eine der ältesten und oft zitierten Umsetzungen ist CORBA, welches Anfang der 90er entwickelt wurde und heute immer noch im Einsatz ist.

Der Zeit entsprechend wurde CORBA für Softwarekomponenten entwickelt. Auch wenn die Schnittstellendefinitionen unabhängig von einer bestimmten Programmiersprache waren, so war die Architektur dennoch stark von C++ geprägt, der Zeit entsprechend.

Schon bei CORBA wurde zwischen Schnittstellendefinition und Infrastruktur getrennt. Heute tritt die Bedeutung der Schnittstellendefinition immer mehr in den Hintergrund, da leicht von einer Form in die andere Übersetzt werden kann.

Schnittstellendefinitionen: REST, SOAP, IDL

Die Schnittstellendefinition beschreibt in maschinenlesbarer Form, wie eine Anfrage an einen Dienst formuliert werden muss, und wie die Antwort des Dienstes aussehen kann. Populär ist heute REST, welches als maschinenlesbare Webseite verstanden werden kann.

Ein konkretes Beispiel: Ein Temperatursensor erlaubt eine Anfrage ohne Parameter und gibt die aktuelle Temperatur zurück. Aber da stellt sich direkt die Frage: Wie weiß ein System, dass die Temperatur wissen will, wie es den Sensor erreicht?

Dienste für die Orchestrierung

Damit der Sensor gefunden werden kann, muss es eine Infrastruktur geben, in die sich dieser Eingliedert. Alle SOAs haben solche Infrastruktur-Dienste. Das folgende Bild zeigt die Dienste des Arrowhead-Frameworks (2. Generation). Manche der Dienste sind optional.

Bild aus: Making System of Systems Interoperable – the Core Components of the Arrowhead Framework

Um das Beispiel des Temperatursensors wieder aufzugreifen: Sobald der Sensor mit dem System verbunden wird, wird dieser über die Service Registry seine Anwesenheit melden. Daraufhin würde das Orchestration System diesen konfigurieren – zum Beispiel den Standort festlegen.

Wenn ein anderes System nun Temperaturdaten benötigt, kann es sich von der Service Registry die Liste aller Sensoren holen und einen passenden auswählen. Dieser kann dann direkt angesprochen werden.

Standardisierung der Orchestrierung

Im heiß umkämpften Markt der IoT ist es nicht verwunderlich, dass sich noch kein Standard für die Orchestrierung durchgesetzt hat: Denn hier geht es um viel Einfluss. Hilfreich ist hier das Paper „A survey of commercial frameworks for the internet of things„. Dort sieht man die üblichen verdächtigen agieren: Google, Microsoft, Cisco, und viele ähnlich große Namen.

Das Arrowhead-Projekt versucht, einen Rahmen vorzugeben, über den die verschiedenen Architekturen zumindest interoperabel gehalten werden können. Zum einen werden bestimmte architektonische Rahmenbedingungen vorgegeben, um „Arrowhead-Compliant“ zu sein. Weiterhin werden verschiedene Strategien aufgezeigt, wie inkompatible Dienste über Wrapper oder Übersetzer in eine Architektur eingegliedert werden können.

Und die Mechanik?

Schade finde ich, dass es vergleichsweise wenig Aussagen zur Interoperabilität der physikalischen Komponenten gesagt wird. Schließlich geht es ja um das Internet der Dinge. Das ist in vielen Anwendungsfällen wohl auch nicht so kritisch: Beispielsweise werden bei Platoon-Fahrten die Fahrzeuge ja nicht miteinander verbunden. Aber wenn dieser Aspekt nicht zumindest grundsätzlich berücksichtigt wird, könnte es auch hier wieder zu unschönen Inkompatibilitäten kommen. Oder noch schlimmer, zu Unfällen.

Fazit

Wer sich im IoT-Bereich bewegt, sollte zumindest Grundsätzlich das Konzept von Service-orientierten Architekturen verstehen. Auch wenn es noch viele ungelöste Fragen gibt, gibt es keinen Grund, hier das Rad neu zu erfinden.

Photo by Manuel Nägeli on Unsplash