Entwurf einer durchgängigen Dienste-Kette

Die Darstellung der einzelnen Bestandteile soll mit einem Komponentendiagramm verdeutlicht werden. Das Komponentendiagramm gehört zu den 14 Diagrammtypen der Unified Modeling Language (UML) zur Datenmodellierung. Es eignet sich zur Beschreibung der Struktur eines Systems. Dabei stehen besonders die einzelnen Bestandteile des Systems und ihre Schnittstellen, über die sie miteinander verbunden sind, im Vordergrund.

Die Kommunikation zwischen dem Sensor und der GeoEvent Extension soll über einen TCP-Port erfolgen. Der GIS-Server führt die Anfragen aus, die an die jeweiligen Web-GIS-Services gerichtet werden. Als Datenspeicher der angebotenen Schnittstellen des GIS-Servers soll eine PostgreSQL-Datenbank dienen. Bei den angebotenen Schnittstellen soll es sich um einen Feature Service und zwei Stream Services handeln. Zusätzlich dazu erfolgt die Ausgabe einiger Daten als Text. Nur die Daten des Feature Service werden in der Datenbank hinterlegt. Eine persistente Datenspeicherung der Streaming-Daten ist nicht möglich. Es können zwar die Daten eines Stream Service vorübergehend gespeichert werden, dabei handelt es sich aber nur um das jeweils zuletzt übertragene Feature. Zudem haben die gespeicherten Features eine Ablauffrist. Nach einer bestimmten Zeit, die bei der Konfiguration des Stream-Output-Konnektors festgelegt wurde, werden die Features gelöscht.

Der bereits erwähnte Feature Service soll mehrere Layer haben. Darunter zwei Punkt-Layer, die zum einen die Positionen des Sensors und zum anderen die Benachrichtigungen, die ausgelöst wurden, enthalten sollen. Zudem soll es einen Polygon-Layer geben, der die GeoFences enthält. Die zwei erstgenannten Layer sollen ihre Features aus der GeoEvent Extension erhalten. Die Features des Polygon-Layer sollen vom Client stammen. Dabei sollen die GeoFences vom Anwender im Client erstellt und für die spätere Prozessierung im Feature Service hinterlegt werden können.

Wir bereits beschrieben, sollen in der entworfenen Dienste-Kette zusätzlich zwei Stream Services genutzt werden. Es sind zwei Stream Services notwendig, da sie im Gegensatz zu einem Feature Service keine Layer aufweisen und die Positions- und Benachrichtigungs-Features unterschiedliche GeoEvent Definitions haben, unter deren Verwendung die Stream Services veröffentlicht werden. Die Stream Services pushen alle Positionen der Sensoren sowie ausgelöste Benachrichtigungen. Die Benachrichtigungen sollen beim Betreten oder Verlassen eines GeoFence, dem Überschreiten einer festgesetzten Geschwindigkeitsgrenze sowie bei nicht vorhandenem GNSS-Signal und schwachem Akkustand ausgelöst werden. Dabei sollen jedoch nur die Benachrichtigungen bzgl. der Geschwindigkeit und der Grenzüberschreitung eines GeoFence über den entsprechenden Stream Service gesendet bzw. im Benachrichtigungs-Layer des Feature Service hinterlegt werden. Die Attribute der Positions- und Benachrichtigungs-Features der Stream Services sollen denen der Features des Feature Services entsprechen.

Der Webserver (hier die virtuelle Maschine) hostet die Web-Anwendungen. Über den Web-Adapter sind der Webserver und der GIS-Server miteinander verbunden. Anfragen des Clients werden durch ihn direkt an den GIS-Server weitergeleitet. Inhalte der Streaming-Services und des Feature Service sollen an den Client übermittelt werden können, der die ArcGIS Server Java Script API enthält. Im Client sollen, wie bereits erwähnt, die GeoFences erstellt werden, die in der GeoEvent Extension zur Prozessierung der Daten verwendet werden. Die Positionen und Benachrichtigungen, die die Stream Services über den Webserver an den Client pushen, werden auf einer Karte dargestellt. Dabei soll von den beobachteten Sensoren jedoch nur die jeweils zuletzt übermittelte Position zu sehen sein. Die entsprechenden Benachrichtigungs-Features sollen an den Stellen, an denen sie ausgelöst wurden, platziert werden. Das gilt nur für Benachrichtigungen, die durch den Übertritt einer GeoFence- bzw. Geschwindigkeitsgrenze ausgelöst wurden. Benachrichtigungen, die aufgrund des Akkustandes oder eines nicht vorhandenen GPS-Signals erfolgen, sollen als Text im Client dargestellt werden. Um die Route eines Sensors darzustellen, werden dessen Positionen vom Feature Service abgefragt. Dabei sollen die Punkte der Reihe nach miteinander verbunden werden. Durch den Client soll sich der Zeitraum festlegen lassen, für welchen die Route dargestellt wird. Die dargestellte Route soll sich anschließend im Client exportieren lassen.

Entwurf der Dienste-Kette innerhalb der GeoEvent Extension

Aufbauend auf den vereinbarten Funktionen wurde ein Entwurf für den Teil der GeoEvent Extension innerhalb der gesamten Dienste-Kette erarbeitet. Bei diesem Entwurf wurde davon ausgegangen, dass Positionsdaten mit zusätzlichen Attributen, wie bspw. einem Zeitstempel oder dem aktuellen Akkustand, an die GeoEvent Extension gesendet werden. Der entworfene GeoEvent Service wird anhand eines Aktivitätsdiagramms beschrieben.

Im GeoEvent Service sind Daten eines Sensors notwendig und eine vordefinierte GeoEvent Definition. Die GeoEvent Definition beschreibt die Struktur, der vom Sensor gesendeten Daten. Nach dem Empfang der Daten werden sie, mit der in dieser Aktion zugeordneten GeoEvent Definition, verarbeitet. Zunächst wird das aktuelle GeoEvent mit dem vorherigen verglichen, sodass die aktuelle Bewegungsgeschwindigkeit des Sensors berechnet werden kann (Abbildung „Speed berechnen“). Bevor die weitere Verarbeitung des GeoEvents erfolgt, werden unerwünschte Attribute eliminiert. Nach der Zuordnung einer bestimmten GeoEvent Definition zur besseren Prozessierung, wird das GeoEvent folgendermaßen ausgewertet: Im Aktivitätsdiagramm werden die unterschiedlichen Analysen der GeoEvents durch den Parallelisierungsknoten ab „1“ dargestellt. In dem ersten Aktionsablauf soll das GeoEvent in dem Feature Service gespeichert werden und gleichzeitig in einem Stream Service veröffentlicht werden. Im Aktivitätsdiagramm wird dies verdeutlicht durch die Verknüpfungsknoten „2“ und „3“. In zwei weiteren Aktionsabläufen soll die Topologie der GeoEvents zu den GeoFences überprüft werden. Dabei werden die im Feature Service gespeicherten GeoFences abgerufen und mit den Positionen der GeoEvents verglichen. Sollte ein GeoEvent einen GeoFence verlassen oder betreten haben, dann wird eine Meldung erzeugt. Die Meldung enthält Information zur Position, der Art der Meldung sowie einer Bezeichnung des GeoFence. Die Meldung soll anschließend sowohl, für eine Echtzeitverarbeitung, mit einem Stream Service veröffentlicht, als auch in einem Feature Service im Benachrichtigungs-Layer gespeichert werden. Des Weiteren wird in einer Analyse, das zuvor berechnete Attribut „speed“ geprüft. Da auch diese Benachrichtigung Positionsinformationen besitzt, soll diese ebenso in einem Feature- bzw. Stream- Service gespeichert bzw. veröffentlicht werden. Zusätzlich sollen der Akkustand und das vorhandene GNSS-Signal kontrolliert werden. Die Benachrichtigung hierbei erfolgt in Textform, sodass die Information später in einem Client präsentiert werden kann. Das Aktivitätsdiagramm soll den Verlauf der ankommenden Daten innerhalb der GeoEvent Extension bzw. einem spezifischen GeoEvent Service verdeutlichen.