Kommunikation zwischen den Diensten

Zur Auffindung der Sensoren wurden Technologien aus dem Bereich derService Lookup-Protokolle herangezogen.

Zur Kommunikation mit Sensor-Diensten über unterschiedliche Plattformen und Netzwerk-Technologien hinweg kommen Technologien aus dem Bereich der Kommunikations-Middleware zum Einsatz. Die verwendeten Techno-logien wurden hierzu in Abschnitt 4.2.2 eingeführt.

Adressierung von Diensten

Auf der Ebene der Konnektoren gilt es Dienste geeignet zu adressieren. Des Weiteren wird eine Gruppierung von Diensten benötigt, um Dienste zu kategorisieren und auf diesem Wege bestimmte Dienste des Rahmenwerkes von Sensoren zu unterscheiden. Das Sensorverzeichnis muss beispielsweise die Möglichkeit haben, eine Liste aller verfügbaren Sensoren zu erhalten.

In dieser Arbeit wird eine Adressierung der Dienste vergleichbar zu URLs oder Java Package Bezeichnungen durchgeführt. Dies ermöglicht sowohl eine direkte Adressierung einzelner Dienste als auch eine hierarchische Grup-pierung von Diensten. Während sich einzelne Dienste des Rahmenwerkes mit „sn/services/[Bezeichner]” adressie-ren lassen, haben Sensoadressie-ren eine Adresse in Form von „sn/sensors/[Bezeichner]”.

Bezogen auf den in Abschnitt 4.2.1 dargestellten Ablauf kann das Sensorverzeichnis bei der Suche nach Diensten nach „sn/sensors” suchen lassen.

Die komplette Adressierung eines Dienstes setzt sich zusammen aus dem Konnektortyp, dem Dienst-Bezeichner und einer zur Laufzeit gültigen ID (um mehrere Dienste desselben Typs an einem Konnektor zu ermöglichen). Die Adresse sieht dann wie folgt aus:

service:[Konnektor]:[Bezeichner]:[Eindeutige ID]

Die Adresse anhand eines konkreten Beispiels wäre demnach:

service:rmi:sn/sensors/webcam:1

Auffindung

Zur Auffindung von Diensten wurde das SLP-Protokoll integriert (siehe Abschnitt A.2). Es lässt sich unabhän-gig von der Technologie (XML-RPC, RMI oder R-OSGI) in den Basiskonnektoren nutzen. Hierzu wurde die Java-ImplementierungjSLP⁴eingebunden, welche im Rahmen von Concierge OSGI entwickelt wurde und ebenfalls sehr leichtgewichtig und flexibel einsetzbar ist. Es basiert ebenfalls auf der Adressierung von Diensten über URLs und lässt sich gut mit der zuvor beschriebenen Form der Adressierung kombinieren.

Um bei der Entwicklung Verbindungen zu bestimmten Diensten aufzubauen, existiert eine Möglichkeit der direk-ten Adressierung des Zielsystems. Durch Angabe der gewünschdirek-ten IP-Adresse des Zielsystems kann so das Ergebnis der SLP-Suche vorweggenommen werden.

2 http://www.osgi.org

3 http://concierge.sourceforge.net/

4 http://jslp.sourceforge.net/

140 6.1 Plattformen und Architektur

Anfragen an Dienste, Datenaustausch

Es wurde ein Ansatz gesucht, welcher eine gemeinsame Schnittstelle zur Kommunikation auf der Ebene der Dienste bietet und darunter eine auf das zugrunde liegende System angepasste Kommunikation ermöglicht.

Wie bereits in Abschnitt 4.2.3 erläutert wurde, bieten existierende Rahmenwerke zur Kommunikation oftmals nur plattformabhängige Kommunikation oder sind insgesamt relativ schwergewichtig. Da in diesem System eine leichtgewichtige und flexible Möglichkeit der Kommunikation zwischen Diensten benötigt wird, wurde eine ei-gene Schnittstelle entwickelt. DieseKonnektor-Schnittstelle beschreibt die grundlegenden Funktionen zum Aufruf entfernter Methoden und den Transport komplexer Datenstrukturen.

Es wurde eine Reihe vonBasiskonnektoren umgesetzt, welche diese Schnittstelle implementieren und welche direkt auf Technologien zur Spezifikation eines entfernten Methodenaufrufes aufsetzen (siehe Abschnitt A.2):

• RMI:DieRemote Method Invocationist eine Technologie, welche von Java bereitgestellt wird.

• R-OSGI:Das Bundle Remote-OSGI⁵ist ein Dienst, welcher von den Entwicklern von Concierge bereitgestellt wird, um eine transparente Kommunikation zwischen verteilten OSGI-Bundles zu ermöglichen.

• XML-RPC:Der XML-RPC Konnektor erlaubt die Kommunikation zu Diensten auf anderen Plattformen, wel-che nicht auf Java basieren.

• LOCAL: Der LOCAL Konnektor ermöglicht eine Kommunikation zwischen Diensten, welche in derselben virtuellen Maschine von Java (Java-VM) ausgeführt werden.

DieseBasiskonnektorenermöglichen die Kommunikation zwischen Diensten. Je nach Bedarf können unterschied-liche Konnektoren eingesetzt werden. Die Eigenschaften der Konnektoren können auch kombiniert und erweitert werden. Hierzu wurden eine Reihe weitererMetakonnektorenumgesetzt, welche auf die Basiskonnektoren aufset-zen. Diese Metakonnektoren bieten dieselbe Schnittstelle wie die Basiskonnektoren, wodurch der Zugriff transpa-rent erfolgen kann (gleichermaßen wie auf einen Basiskonnektor).

• MULTI:Der MULTI Konnektor erlaubt die Kombination mehrerer Konnektoren. So können beispielsweise das flexible XML-RPC und das effiziente RMI kombiniert und parallel betrieben werden.

• OFFLINE:Der OFFLINE Konnektor kann auf den Endgeräten betrieben werden, um in Situationen Daten zu sammeln, in denen das Endgerät keine Verbindung zum Gesamtsystem hat. Hierzu erfasst der OFFLINE Kon-nektor alle Sensoren, welche auf dem Endgerät über den Sensor angemeldet werden. Sobald die Verbindung zum Gesamtsystem unterbrochen wurde, erfasst und speichert dieser Konnektor die Daten an den lokalen Sensoren. Kann die Verbindung wieder hergestellt werden, so bietet der OFFLINE Konnektor einen weiteren Dienst an, welcher die Zustände der Sensoren in dem Zeitraum mit dem entsprechenden Zeitstempel zur Verfügung stellt.

• REPLAY: Der REPLAY Konnektor zeichnet alle Sensorzustände auf und bietet die Möglichkeit diese später wieder in das System einzuspielen. So können die Zustände aller Endgeräte aufgezeichnet und für Tests und Analysen zu einem späteren Zeitpunkt wieder in das System eingespielt werden. Dies kann auch beschleunigt in simulierter Zeit erfolgen (siehe Abschnitt 6.1.3).

Durch den gewählten Ansatz der Konnektoren ist es möglich verschiedene Plattformen an das Rahmenwerk an-zubinden. Wie in Abbildung 6.1 dargestellt wird, kann für jede Plattform ein geeigneter Konnektor gewählt und eingesetzt werden. Die umgesetzten Konnektoren setzen direkt auf Basistechnologien zur Kommunikation auf und sind daher sehr leichtgewichtig. Der Ansatz ist darüber hinaus flexibel und kann um weitere Plattformen erweitert werden, indem ein entsprechender Konnektor hinzugefügt wird. Ebenso kann der Funktionsumfang der Konnek-toren erweitert werden, indem ein Metakonnektor hinzugefügt wird, welcher auf einem Konnektor aufsetzt und ihn um die benötigte Funktionalität erweitert (wie beispielsweise der OFFLINE Konnektor in der Darstellung 6.1 links).

Vergleich der Konnektoren

Die implementierten Basiskonnektoren weisen alle die gleiche Funktionalität auf. Sie unterscheiden sich jedoch zum einen in den Plattformen, auf denen sie eingesetzt werden können, und zum anderen haben sie unterschiedli-che Eigenschaften im Bezug auf den Aufwand und die Verzögerung, welunterschiedli-che sie bei der Verarbeitung von Anfragen erzeugen. Um das Laufzeitverhalten zu analysieren wurde ein Dienst umgesetzt, welcher es erlaubt, eine Vielzahl

5 http://r-osgi.sourceforge.net/

6 Realisierung 141

SmartPhone Windows Mobile

XML-RPC Gumstix

Linux/Java

R-OSGI

PC Windows/Java

R-OSGI OFFLINE

RMI XML-RPC

MULTI Sensor A

Sensor B Diensteverzeichnis Kontextdienst

Abbildung 6.1:Anwendungsbeispiel: Nutzung von Konnektoren

von Anfragen an einen entfernten Dienst abzusetzen. DieserAnfragengeneratorbietet die Möglichkeit, den anzu-fragenden Dienst, die aufzurufende Methode, die Dauer des Tests und die durchschnittliche Anzahl von Anfragen pro Sekunde festzulegen. Die Anfragen werden jeweils von einem gesonderten Thread ausgeführt und mit einem (gleich verteilten) Jitter von +/- 500ms versehen, um ein unregelmäßiges Eintreffen von Anfragen nachzubilden.

Jeder Test wurde 30 Sekunden lang durchgeführt, wobei eine Methode am entfernten Dienst aufgerufen wurde, welche eine einfache Abfrage eines Wertes nachbildet, ohne auf der Seite des entfernten Dienstes zusätzlichen Bearbeitungsaufwand zu generieren. Die Anfragen wurden von einem PC (gleicher Bauart wie in der Analyse aus Abschnitt 5.4.5) aus an verschiedene Endgeräte gesendet.

0 5 10 15 20

0 20 40 60 80 100 120 140

Zeitbedarf (ms)

Anfragen pro Sekunde PC XML-RPC

RMI R-OSGI

Abbildung 6.2:Vergleich der Konnektoren am PC

In Abbildung 6.2 wurden die Anfragen an einen anderen PC gleicher Bauart gesendet. Bei einzelnen Anfragen benötigen RMI und R-OSGI mit 2ms im Durchschnitt 4ms weniger Zeit als XML-RPC. Bis zu einem Aufkommen von bis zu 100 Anfragen pro Sekunde konnten alle Konnektoren, ohne merkliche Veränderungen an ihrem Lauf-zeitverhalten, arbeiten. Ab diesem Punkt bis hin zu 150 Anfragen pro Sekunde zeigten XML-RPC und RMI einen geringen Anstieg der Verzögerung bei der Verarbeitung der Anfragen. R-OSGI übertrifft diese Leistung durch gleich-bleibende Verzögerung bei bis 150 Anfragen pro Sekunde. Mit gemessen Verzögerungen von durchschnittlich rund drei bis sieben Millisekunden und bei einer Anzahl von bis zu 100 Anfragen pro Sekunde ist dieses Laufzeitverhal-ten für das angestrebte Anwendungsszenario gut geeignet. Im nächsLaufzeitverhal-ten Szenario wurden vergleichbare Tests mit ressourcenbeschränkten Systemen wie der Gumstix-Plattform oder dem Nokia N810 (für Hardwaredetails siehe Abschnitt 6.2.1) durchgeführt. In Abbildung 6.3 werden die Ergebnisse dieses Tests dargestellt.

Diese ressourcenbeschränkte Systeme zeigen weitaus höhere Latenzen im Vergleich zu den Messungen mit zwei PCs. Einzelne Anfragen an den Gumstix per WLAN benötigen beispielsweise mit R-OSGI 15ms, mit RMI 66ms und mit XML-RPC ganze 135ms. Steigt die Anzahl von Anfragen pro Sekunde, so steigt auch der Aufwand zur Verarbei-tung auf dem Endgerät. Es gibt jedoch deutliche Unterschiede zwischen den Konnektoren. Bei XML-RPC sind die Endgeräte ab einer Rate von 5 bis 15 Anfragen überfordert, was zu starken Verzögerungen und fehlgeschlagenen Anfragen führen kann (siehe Abbildung 6.3). RMI hingegen ermöglicht eine Rate von bis 10 bis 20 Anfragen pro Sekunde.

R-OSGI hebt sich klar gegenüber den anderen Ansätzen hervor. Mit R-OSGI sind auch Raten jenseits von 25 Anfragen pro Sekunde ohne merklichen Anstieg in der Verzögerung möglich.

142 6.1 Plattformen und Architektur

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

0 5 10 15 20 25

Zeitbedarf (ms)

Anfragen pro Sekunde GUMSTIX / N810 GUMSTIX RMI (LAN) GUMSTIX RMI (WLAN) GUMSTIX RMI (OSGI,WLAN) GUMSTIX R-OSGI (WLAN) GUMSTIX XML-RPC (WLAN) N810 R-OSGI N810 XML-RPC

(a)Geschwindigkeit der Verarbeitung von Anfragen

0 20 40 60 80 100

0 5 10 15 20 25

Anteil verlorener Pakete in %

Anfragen pro Sekunde GUMSTIX / N810 GUMSTIX RMI (LAN) GUMSTIX RMI (WLAN) GUMSTIX RMI (OSGI,WLAN) GUMSTIX R-OSGI (WLAN) GUMSTIX XML-RPC (WLAN) N810 R-OSGI N810 XML-RPC

(b)Fehlgeschlagene Anfragen

Abbildung 6.3:Vergleich der Konnektoren an ressourcenbeschränkten Endgeräten

Ein weiteres interessantes Ergebnis zeigt der Vergleich vom RMI, welches innerhalb von OSGI verwendet wurde und der normalen Verwendung außerhalb von OSGI (siehe Abschnitt 6.1.3). In dem Testaufbau zeigt RMI innerhalb von OSGI ein deutlich besseres Laufzeitverhalten als ohne.

Die Wahl des geeigneten Konnektors hat also gerade bei ressourcenbeschränkten Systemen einen maßgeblichen Einfluss auf die Menge der möglichen Sensoranfragen bei zeitbeschränkten Suchanfragen.