Weingarten.gApp – die ferngesteuerte generisch App
Die Verwendung der Remote-App-Plattform (rApp) erlaubt es den Geräteherstellern, die Nachteile der herkömmlichen Fat und Thin Client Lösungen zu vermeiden und sich wie bisher vollständig auf die Entwicklung ihrer Geräte-Software zu konzentrieren.
Mit den Herausforderungen von App-Entwicklungen auf den Smart Devices und des App-Vertriebs über App-Stores brauchen sich die Gerätehersteller nicht zu beschäftigen.
Die Grundidee: Eine immer gleichbleibende, generische App (die gApp) auf den Smart Devices wird über SOA-Dienste (Service Oriented Architecture) durch die Geräte ferngesteuert.
Alle Aktionen gehen dabei immer vom Gerät aus, die gApp führt lediglich aus, was das Gerät ihr aufträgt.
Insofern fungiert die gApp als SOA-Dienste-Server und das Gerät ist der SOA-Dienste-Client.
Die gApp wird als ein Bestandteil von rApp durch acontis in den unterschiedlichen App Stores zum Download bereitgestellt.
Geräte mit Apple iOS, Android, Windows Phone, Windows Modern Apps, Windows IoT, Desktop Windows, Linux oder auch Apple OSX können eingesetzt werden.
Desktop-Windows, Linux und MacOS adressieren neben Smart Devices auch herkömmliche PCs, Laptops und Server, welche somit auch als Terminal zum Benutzer dienen können.
Aus diesem Grunde wird im Weiteren der allgemeinere Begriff „Terminal“ anstatt „Smart Device“ verwendet.
Bei Bedarf sind die generischen Apps auch in Source Code erhältlich, sodass der Gerätehersteller gerade bei PCs, Laptops und Servern diese durch eigene Programme auf den Terminals erweitern kann, welche zum Beispiel zusätzlich zu Benutzerinteraktionen auch Datenerfassungen und Auswertungen durchführen.
rApp SDK
Für die Geräteseite stellt rApp eine Bibliothek mit definiertem API für die gängigsten (Echtzeit-) Betriebssysteme, Prozessoren und zunächst für die Programmiersprachen C# und C++ zur Verfügung.
Über diese Bibliothek, welche der Gerätehersteller in seine Geräte-Software einbindet, kann er alle Funktionen des Terminals wie Bildschirm-Ein- und Ausgabe, Hardware-Funktionen und Dienste quasi fernsteuern. Dabei stehen dem Geräteprogrammierer bei der Remote-Nutzung nahezu alle gängigen Dienste von Smart Devices zur Verfügung.
Für die Bildschirmausgabe existieren wahlweise zwei Möglichkeiten: Zum einen wie beim Thin-Client-Prinzip die Bildschirm-Aus- und -Eingaben mittels HTML und JavaScript zu beschreiben. Die dabei erzeugten Dateien werden jedoch nicht durch einen Webserver wie üblich bereitgestellt, sondern durch die rApp-Bibliothek auf Veranlassung des Gerätes zum Terminal geschickt (Push-Verfahren), welches den sich daraus ergebenden Bildschirm anzeigt und die in JavaScript programmierte Logik ausführt. Dies hat den Vorteil, dass kein Webserver im Gerät notwendig ist und es auch keine patentrechtlichen Probleme gibt.
Eine zweite Möglichkeit für die Bildschirmausgabe besteht darin, den lokal auf dem Gerät erzeugten Bildschirminhalt mittels H.264 komprimierten Video-Stream an das Terminal zu senden, welches diesen Video-Stream dekomprimiert und auf dem Bildschirm darstellt. Dies ist auch der Weg, den Apple bei CarPlay beschritten hat, um die Bildschirminhalte eines iPhone auf der Konsole des Autos darzustellen. Der Vorteil von H.264 Streaming ist, dass die Bildschirmerzeugung auf dem Gerät mit herkömmlichen Methoden des Geräteherstellers erfolgen kann und nicht auf Web-Techniken umgestiegen werden muss. Das H.264 Streaming zur Bildschirmausgabe setzt allerdings Hardware-Unterstützung im Gerät voraus, wie sie alle modernen Intel- und ARM-Prozessoren mit eingebauter Grafik Processing Unit (GPU) aufweisen.
Flexible Kommunikation, rApp Relay
Damit das Gerät die Dienste des Terminals nutzen kann, muss es mit diesem in einer Kommunikationsbeziehung stehen. Hierfür gibt es vier Möglichkeiten, welche der Programmierer wahlfrei nutzen kann. Alle Kommunikationsarten sind mittels aktuellen Security-Verfahren verschlüsselt und für den Benutzer völlig transparent. Das heißt, es stellt für ihn keinen Unterschied dar, ob er lokal (On Premise), über einen Inhouse-Server (Private Cloud), über das Internet (Public Cloud) oder einer Kombination von beiden (Hybrid Cloud) mit dem Gerät verbunden ist.
Die erste Kommunikationsart ist „On Premise“. Dies ist dann der Fall, wenn Gerät und Terminal im selben lokalen Netzwerk angemeldet oder über VPN verbunden sind. In diesem Falle ist kein weiterer Server notwendig: Gerät und Terminal kommunizieren Peer to Peer.
Die Kommunikationsarten „Lokales Relay“ bzw. „Internet Relay“ werden angewendet, wenn zwar das Terminal Zugang zum Internet hat, das Gerät aber nur über einen zentralen Server als Gateway mit dem Internet kommunizieren kann (Hybrid Cloud) oder wenn sich Gerät und Terminal in zwei unterschiedlichen Netzen befinden, an welche der lokale Server angeschlossen ist, zum Beispiel wenn Produktions- und Office-Netzwerk getrennt sind (Private Cloud, gestrichelt dargestellt). Auf dem lokalen Server muss dann die rApp-Relay-Software ablaufen, welche ebenfalls Bestandteil von rApp ist. rApp-Relay speichert lokal keine Daten, sondern reicht den Datenstrom vom Gerät zum Terminal in beide Richtungen einfach nur durch.
Die vierte Kommunikationsart kommt zum Einsatz, wenn sowohl Gerät als auch Terminal einen Internet-Zugang haben. „Internet-Zugang“ bedeutet jedoch nicht, dass das Gerät oder das Terminal eine offizielle IP-Adresse haben und vollständig funktionsfähig am Internet angeschlossen sein müssen. Es reicht aus, wenn sowohl das Gerät als auch das Terminal lediglich Outbound-Zugriffe über Port 80 oder Port 443 machen können (HTTP Standard Web-Port beziehungsweise mit TLS (HTTPS) verschlüsselt). Dies ist beispielsweise bei Geräten hinter Firewalls oder in Privathaushalten mit DSL-Routern und NAT der Fall. Sowohl Gerät als auch Terminal nehmen lediglich über Port 80/443 Outbound-Kontakt mit dem rApp-Relay in der Public Cloud auf, welches dann den Datenkanal zwischen den beiden durchschaltet. Durch diesen, auf Outbound-only-Ports bestehendem Mechanismus wird ein hohes Maß an Sicherheit erreicht, da anders als bei Fat- und Thin-Client-Lösungen auf dem Gerät keine Inbound-Ports offen sind. Auch spielt es keine Rolle, hinter welchen Firewalls, DMZs und NAT-Netzen sich das Gerät befindet. In dem Moment, da es Port-80/443-Web-Browser-Zugriffe machen kann, können Gerät und Terminal über das rApp-Relay miteinander kommunizieren. Der Gerätehersteller kann die rApp-Relay-Software in einer eigenen Cloud betreiben oder den von Acontis hierzu angebotenen Service nutzen.
