Bachelorarbeit. Universität Rostock Fakultät für Informatik und Elektrotechnik Institut für Informatik

Transkript

1 Konzept für Events auf mobilen Geräten mittels publish-route Infrastruktur Bachelorarbeit Universität Rostock Fakultät für Informatik und Elektrotechnik Institut für Informatik vorgelegt von: Heiko Hoffmann Matrikelnummer: Gutachter: Prof. Dr. rer. nat. Clemens H. Cap Betreuer: Dipl.-Inf. Martin Garbe Abgabedatum: 22. August 2011

2 Inhaltsverzeichnis 1 Einleitung 1 2 Positionsdaten auf mobilen Geräten Ermittlung von Positionsdaten auf mobilen Geräten Global Navigation Satellite Systems (GNSS) Global System for Mobile Communications (GSM) Radio-Frequency Identification (RFID) Wireless Local Area Network Quick Response Code (QR-Code) Fazit Positionsdatenmodelle Kontext Klärung des Kontextbegriffs Kontextarten Kontextquellen für mobile Geräte Herausforderungen der Kontextverarbeitung auf mobilen Geräten Formate zur Modellierung und zum Austausch von Kontext JavaScript Object Notation (JSON) Extensible Markup Language (XML) Web Ontology Language (OWL) Bewertung Mobile Frameworks und Middlewares zur Kontextbehandlung Widgetbasierte Architektur am Beispiel Context Toolkit Networked Services am Beispiel der Mobile Collaboration Architecture Blackboards Möglichkeiten zur Verteilung von Event- und Kontextdaten auf mobilen Geräten Aspekte der Verteilung von Event- und Kontextdaten Polling

3 5.3 Socketverbindungen Publish-Subscribe Systeme Vergleich mobiler plattformunabhängiger Frameworks Kriterien für Cross-Plattform Frameworks Phonegap Rhomobile Titanium Mobile Zusammenfassung Konzept für ein mobiles Verteilungssystem von Eventdaten Events - Möglichkeiten und Anforderungen Services - Möglichkeiten und Anforderungen Verteilung der Event- und Kontextdaten Architektur Implementation eines Prototypen: Event Distributor App (Eda) Verwendete Frameworks und Bibliotheken Benachrichtigungen Speichern von Daten Registrierungsprozess Komponenten von Eda Events und EventHandler Services und ServiceHandler uihandler LogHandler Beispielszenario Bewertung und Ausblick Literaturverzeichnis 66

4 1 Einleitung Durch immer stärker verbesserte Fertigungstechniken stehen dem Handy-Nutzer immer mehr Funktionen und Ressourcen der Desktopwelt auch mobil zur Verfügung. So sind Dual-Core CPUs für Smartphones bereits zur Normalität geworden. Zudem beinhalten sie immer mehr Sensoren, die nicht nur neue Möglichkeiten bezüglich der Bedienung bieten, sondern auch ein genaues Bild des direkten Umfelds des Nutzers zeichnen. So stehen dem Gerät Informationen über dessen Neigung, Ausrichtung, Beschleunigung oder der lokalen und globalen Position zur Verfügung. Sämtliche Informationen, die über Sensoren ermittelt werden oder über die Bedienung durch den Nutzer in Erfahrung gebracht werden können, haben dabei etwas mit dem Umfeld zu tun. Rund um diese Informationen, die das direkte Umfeld des Nutzers betreffen, haben sich viele Internetdienste gebildet. Sie aggregieren Informationen, die wir ihnen senden und bieten uns im Anschluss neben zusätzlichen Informationen auch Interaktionsmöglichkeiten mit anderen Nutzern oder sonstige Dienste an. Innerhalb von Sekunden ist der Nutzer so in der Lage, Navigationsdienste zu nutzen oder über sein Smartphone eine Stadttour in München zu planen, so dass ihm anhand seiner Position nahegelegene interessante Orte (POIs) vorgeschlagen werden. Nun sind die Routinen, die innerhalb solcher Anwendungen zum Einsatz kommen, oftmals sehr ähnlich aufgebaut. Zu einem bestimmten Zeitpunkt oder nach Eintreten eines bestimmten Ereignisses wird ein bestimmter Teil unserer Umgebungsdaten an den Dienst gesendet, der sie anschließend auswertet. Dabei ist es sinnvoll ein allgemein nutzbares Framework zu entwerfen, welches die Aggregation der Daten und das Senden an die Dienste übernimmt. Hierfür ist es notwendig eine Vorstellung davon zu bekommen, was diese Daten ausmacht, wie man mit ihnen umgeht und wie man sie verteilen kann. Um eine Vorstellung zu bekommen, wo solch ein Framework Anwendung finden kann werden drei Szenarien gezeigt, in denen die Aggregation und Verteilung von diesen Informationen eine wichtige Rolle spielen. 1

5 1 Einleitung Staumeldungen Ein Smartphonenutzer möchte einem externen Anbieter Geschwindigkeitsdaten mit Hilfe seiner Navigationssoftware zur Verfügung stellen, um die Genauigkeit und Aktualität der Staumeldungen zu erhöhen. Hierzu meldet er sein mobiles Gerät auf der Seite des Anbieters an und erhält im Gegenzug eine Beschreibung der benötigten Daten, um am Dienst teilnehmen zu können. Zudem ist es aus Sicht der Datensparsamkeit und Privatsphäre sinnvoll, die zu übertragenden Daten nur unter bestimmten Bedingung zu versenden. So kann das Senden der Daten über eine Heuristik ausgelöst werden. Weiter ist es verdächtig, wenn das Tempo über einen Zeitraum von vier Minuten im Schnitt niedriger als 15 km/h liegt und das Ziel noch nicht erreicht wurde. Der Dienstleister hat nun die Möglichkeit, die Daten von verschiedenen Anwendern zu aggregieren und auszuwerten. Durch die Einstellungs- und Kontrollmittel wird dem Nutzer die Grundlage dafür geschaffen in den Verteilungsprozess einzugreifen, um seine Privatsphäre sicherzustellen. Gesundheitskontrollsystem Bei vielen Patienten ist es nicht nötig, Körperfunktionen direkt im Krankenhaus zu überwachen. Ein klassisches Beispiel für ein solches Szenario ist das Langzeit-EKG. Hier wird dem Patienten über ca. 24 Stunden eine Gerät zur Aufzeichnung der Herzfunktion angelegt. Durch den Einsatz von Smartphones und die Kopplung solcher Sensoren via Bluetooth lassen sich langfristige Untersuchungen kostengünstiger durchführen. Die Konfiguration wird direkt auf dem Smartphone vorgenommen und die Daten können zeitnah an den Arzt gesendet und ausgewertet werden. Auch groß angelegte Studien mit einer Vielzahl an Teilnehmern können so durchgeführt werden. Entsprechende Sensorschnittstellen können ohne großen Aufwand erstellt und in die Applikation integriert werden. Stimmungskarten An vielen Orten innerhalb einer Stadt interagieren Menschen miteinander. Dabei suchen sie diese Orte aus bestimmten Motiven auf. Es entstehen Szeneviertel oder Ballungsgebiete, in denen Menschen aufeinandertreffen oder bestimmte Dinge erledigen. Über den Aspekt des Ortes bzw. der Einrichtung hinaus ist es auch möglich, dass Menschen ihre Stimmung kund tun. So kann der 2

6 1 Einleitung Nutzer auf seinem mobilen Gerät aus Begriffen wie entspannt, gestresst, amüsiert oder aggressiv auswählen. Diese Daten werden mit einer groben Position versehen und ohne weitere Kennung an einen oder mehrere externe Dienste gesendet. Im Laufe der Zeit entsteht so eine Emotionskarte, die verschiedene Stimmungen abbildet. Diese wiederum kann für andere Menschen als Grundlage für die Freizeitplanung dienen oder auch zur Optimierung der Stadt- und Raumplanung genutzt werden. 3

7 2 Positionsdaten auf mobilen Geräten Mit dem großen Angebot an mobilen Geräten heutzutage ist es dem Nutzer möglich, seine Position zu bestimmen. Die Quellen dieser Positionsdaten sind vielseitig. Sie können direkt über Sensoren im Smartphone oder Notebook ermittelt werden oder auch externe Quellen nutzen, die für Anwender nicht unmittelbar erreichbar sind. Darüber hinaus liegen diese Daten, abhängig von Sensoren und verwendeter Technik, in unterschiedlichen Formaten vor. Im Folgenden werden deshalb verschiedene Verfahren zur Bestimmung von Positionsdaten vorgestellt, die für mobile Geräte relevant sind und anschließend Möglichkeiten aufgezeigt, wie die gewonnen Daten zur weiteren Nutzung strukturiert und modelliert werden können. 2.1 Ermittlung von Positionsdaten auf mobilen Geräten Eine Möglichkeit der Unterscheidung von Positionsverfahren ist, sie nach der Art des Bezugssystems in globale und lokale Positionierungstechniken zu unterteilen. Eine andere Möglichkeit ist es, sie mit Hilfe ihrer zugrundeliegenden physikalischen und mathematischen Prinzipien voneinander abzugrenzen: Trilateration (Berechnung über Abstand, geschätzt aus Signallaufzeit oder Signalstärke) Triangulation (winkelbasiert) Mustererkennung der Signalcharakteristik (fingerprinting) Kombinationen aus obigen Ansätzen In [Ma04] und [DrMaSc98] werden, zusätzlich zu den beiden aufgezählten Möglichkeiten der Klassifizierung, weitere Ansätze detailliert erläutert. Heutige mobile Geräte wie Smartphones und Netbooks sind in der Regel nicht auf eine einzige Positionierungstechnik beschränkt. Teilweise ergänzen sich diese Verfahren, um höhere Genauigkeiten zu erzielen oder eine schnellere Ortung zu erreichen. Klar wird dies, wenn man die folgenden Techniken betrachtet, die häufig im mobilen Bereich eingesetzt werden und charakteristisch für diese Anwendungsgebiete sind Global Navigation Satellite Systems (GNSS) Globale Navigation via Satellit zeichnet sich dadurch aus, dass sie die Positionsbestimmung weltweit ermöglicht [DoHö10]. Die bekanntesten, in der Praxis verwendeten Systeme sind GPS und GLONASS. In der Umsetzung befindet sich zudem Galileo, das ein europäisches Projekt 4

8 2 Positionsdaten auf mobilen Geräten darstellt, welches eine zukünftige Alternative zu den beiden genannten Systemen darstellen soll. Alle drei Systeme funktionieren nach dem gleichen Prinzip [DoHä10]: 1. Die Satelliten senden ein elektromagnetisches Signal aus. Dieses Signal enthält Informationen über die Uhrzeit der Abstrahlung und die Koordinaten des Satelliten. 2. Mittels physikalischer Kenntnis über die Geschwindigkeit elektromagnetischer Signale kann der Empfänger aus der Laufzeit die Entfernung zu den einzelnen Satelliten berechnen. 3. Um die mitgesendeten dreidimensionalen Koordinaten der Satelliten werden nun die Entfernungen als Radien angesetzt, um Kugeln zu formen. 4. Aus dieser Modellierung kann man unmittelbar ein Gleichungssystem formen, das drei Unbekannte enthält (die x,y und z Komponente der gesuchten Position) und nun nur noch gelöst werden muss. Die Position wird also über den trigonometrischen Zusammenhang ermittelt. Nach obiger Klassifikation ist er so der Trilateration zuzordnen. Weiter folgt daraus, dass sich mindestens drei Satelliten im Sichtbereich des Empfangsgerätes befinden müssen, damit dieses Verfahren anwendbar ist. Am Beispiel von GPS lässt sich mit dieser Technik so eine Genauigkeit von ca. 10 m erreichen. Durch Nutzung moderner Satelliten und Endgeräte, Korrektursignalen sowie zusätzlicher Informationen lässt sich dieses Ergebnis aber noch weiter präzisieren. Zusätzliche Daten machen sich beispielsweise Verfahren wie Differential-GPS (dgps), Local-Area Differential GPS (LAG- PS), Wide-Area Differential GPS (WADGPS) oder Wide-Area Augmentation System (WAAS) zunutze [GrWeAn07]. Mithilfe des Satellitenpositionierungsdienstes (SAPOS), welches ein dgps- System darstellt, sind sogar Genauigkeiten von bis zu wenigen Zentimetern möglich. Ermöglicht wird dies durch feststehende Referenzstationen, die ihre tatsächliche Position mit der via GPS ermittelten Position abgleichen und anschließend Korrekturdaten zur Verfügung stellen. Im Allgemeinen nimmt die Ortung der Satelliten einige Minuten in Anspruch. Ist jedoch die ungefähre Position des Nutzers bekannt, kann er über eine Datenverbindung die Position der Satelliten ermitteln. Auch die bereits angesprochenen dgps-korrektursignale sind über eine Internetverbindung abrufbar. 5

9 2 Positionsdaten auf mobilen Geräten Problematisch an dieser Art der Positionsbestimmung auf mobilen Kleingeräten ist jedoch, dass diese in der Regel eine sehr begrenzte Akkulaufzeit haben und GPS-Ortung eine nicht unerhebliche Belastung selbiger darstellt. Ist also im konkreten Anwendungsfall eine relativ ungenaue Positionierung (Stadtteil, Region) ausreichend, so sollte abgewogen werden eine alternative Technik zu verwenden Global System for Mobile Communications (GSM) Die GSM-Ortung macht sich das einfache Prinzip zunutze, dass Handys und Smartphones sich an Funkmasten des GSM-Netzes anmelden. Dabei sind die Position des Funkmastes und dessen Senderadius bekannt. Folglich weiß man, dass sich jedes eingewählte Gerät innerhalb dieses Radius befinden muss. Die Genauigkeit dieses Verfahrens, welches Cell of Origin genannt wird, kann hundert Meter bis mehrere Kilometer betragen. Diese Methodik hat jedoch, wie die Ortung per GPS, einige Optimierungsmöglichkeiten um genauere Resultate zu erzielen. Hier zu nennen sind Time Of Advance und Time Difference Of Advance und weitere, welche zur Berechnung der Entfernung vom Sendemast die Signallaufzeit verwenden und in [De07], p74ff genau erläutert werden. Für mobilfunkfähige Geräte ist diese Art der Positionierung ohne zusätzliche Aufrüstungen und Leistungsaufnahme nutzbar, was ein großer Vorteil dieser Technik ist. Gleichzeitig ist die Genauigkeit mit der Ortung durch GPS nicht vergleichbar, zumal die Verfügbarkeit hier stark schwankt. So ist die Dichte von Sendemasten in ländlichen Regionen viel geringer als in urbanen Gebieten. Durch Gebäude, Bäume und andere Umgebungsmerkmale wird das Signal gedämpft Radio-Frequency Identification (RFID) Die RFID-Technik setzt auf Transponder, welche sich dadurch auszeichnen, dass sie elektromagnetische Signale entgegennehmen und diese automatisch beantworten. Dabei unterscheidet man zwischen aktiven und passiven Transpondern. Aktive Transponder benötigen zwar eine Stromquelle, wie beispielsweise Batterien, können dadurch aber die Signale in hohe Reichweiten ausstrahlen. RFID-Markierungen können an Objekten genutzt werden, um diese zu identifizieren. Führen diese Positionsinformationen mit, so kann eine Positionsbestimmung erfolgen. Interessant 6

10 2 Positionsdaten auf mobilen Geräten ist diese Technik besonders bei der Nutzung innerhalb von Gebäuden. Hier genügen Techniken wie GPS und GSM-Ortung den Anforderungen an Genauigkeit nicht, oder können nur Daten bezüglich eines globalen Bezugssystems anbieten Wireless Local Area Network WLAN-Netzwerke bieten indirekt die Möglichkeit, eine Positionsbestimmung der angemeldeten Nutzer vorzunehmen. Das Prinzip ist dabei mit dem der GSM-Ortung vergleichbar. In Ballungsgebieten stehen durch die Eroberung der Heimnetzwerke durch WLAN-Router viele Drahtlosnetzwerke zur Verfügung, deren Identität sich (theoretisch) eindeutig über die MAC- Adresse bestimmen lässt. Sind nun Positionsinformationen über diese Router vorhanden, so ist die Ortung des Klienten durch Schnittberechnungen der WLAN-Netzwerke, Signalstärkenauswertung usw. approximierbar. Gegenüber satellitengestützter Techniken funktioniert WLAN-Ortung auch innerhalb von Räumen und bietet relativ gute Ergebnisse in Ballungsgebieten, wo GPS- Positionierung meist aufgrund von hohen Gebäuden nicht oder nur eingeschränkt möglich ist. Für eine solche Positionierung wird jedoch eine Internetverbindung und ein entsprechender WLAN- Positionierungsdienst vorausgesetzt. Dieser Dienst nutzt eine Datenbank mit möglichst vielen Routern und deren Position. Es gibt hier zwei verschiedene Ansätze diese Datenbanken zu erstellen. Die erste Möglichkeit ist, dass die Routerbesitzer ihr Gerät und dessen Position in die Datenbank eintragen. Ein Projekt, dass dieses Prinzip nutzt und die gewonnen Daten frei zur Verfügung stellt ist OpenWLAN- Map.org [OWM11]. Die zweite Möglichkeit ist es, die mobilen Geräte selbst zu nutzen, um die WLAN-Netzwerke zu erfassen. So gibt es verschiedene Anbieter wie beispielsweise Skyhook, die mobilen Geräten die Positionierung über WLAN-Netzwerke ermöglichen und gleichzeitig erfasste WLAN-Informationen entgegennehmen, um ihre Datenbank zu erweitern [SKY11]. Vorteile dieser Technik sind die Geschwindigkeit der Positionsermittlung und die guten Möglichkeiten der Positionsbestimmung in Ballungsgebieten. Diese beiden Aspekte sind besonders für Normalnutzer interessant, da viele ortsbezogenen Dienste sich auf urbane Gebiete konzentrieren und in der Regel schnell verfügbar sein müssen. 7

11 2 Positionsdaten auf mobilen Geräten Abbildung 2.1: Beispiel eines QR-Codes Quick Response Code (QR-Code) Eine beliebte Alternative zu RFID für mobile Geräte mit Kameras ist der Quick Response Code (QR-Code). In Abbildung 2.1 ist der Aufbau eines solchen Codes zu sehen. Mit ihm lassen sich viele verschiedenartige Informationen kodieren, unter anderem auch Positionsdaten und Objektbeschreibungen. Dadurch, dass jedes mobile Gerät mit Kamera theoretisch dazu in der Lage ist solche Codes zu lesen und sie sich ohne großen technischen Aufwand erstellen lassen, erfreut sich diese Technik steigender Beliebtheit. Zu berücksichtigen ist aber, dass ein Sichtkontakt zum Code bestehen muss und der Scan dieser Codes ein aktives Eingreifen des Nutzers erfordert. Es minimiert so letztendlich also nur den Aufwand gegenüber der manuellen Eingabe von Positionsdaten Fazit Mittlerweile gibt es eine Vielzahl an verschiedenen Verfahren zur Positionsbestimmung. Häufig werden diese Techniken kombiniert, um die Genauigkeit zu erhöhen oder um die Positionsermittlungsdauer zu verkürzen. Mittels einer Datenbank von Funkmasten kann so zum Beispiel ermittelt werden, wo der Nutzer sich befindet und an welchen Positionen die GPS-Satelliten zu finden sind. Dabei hängt die Entscheidung, welche Techniken man am Besten verwendet von verschiedenen Aspekten ab. Die Anwendungsanforderungen, Einsatzgebiete, die gewählten Zielplattformen und deren vorhandene Sensoren sind hier als Hauptkriterien zu nennen. 2.2 Positionsdatenmodelle Nachdem nun einige Verfahren vorgestellt wurden mit denen sich Positionsdaten ermitteln lassen, ist es aus Entwicklersicht wichtig, die erhobenen Daten zu abstrahieren, um sie sinnvoll in seiner 8

12 2 Positionsdaten auf mobilen Geräten Abbildung 2.2: Beispiel eines semantischen Modells [FlPrRa04] Applikation nutzen zu können. [FLPrRa04] beschreibt aus diesem Grund die grundsätzlichsten Positionsmodelle. Geometrische Modelle Geometrische Modelle beschreiben die Position als Punkt in einem Referenzkoordinatensystem. Hierzu zählen geographische Koordinatensysteme oder einfache dreidimensionale kartesische Koordinatensysteme, die innerhalb von Räumen aufgespannt werden. In geometrischen Modellen hat man eine Vielzahl an Möglichkeiten zusätzliche Informationen zu gewinnen. So sind Abstandsund Schnittpunktberechnungen, Umkreissuchen und weitere elementare Berechnungen in diesen Koordinatensystemen in der Regel möglich. Mengentheoretische Modelle Dieser Modellbegriff orientiert sich an der Mengenlehre. Eine Position oder eine Mehrzahl von Positionen zusammengefasst zu einer Entität, werden einer Menge zugeordnet. Diese Menge besitzt eine Positionsangabe, jedoch in der Regel keine weiteren metrischen Informationen, wie Ausdehnung oder Abstand zu anderen Objekten. Die gesuchte Position der Entität ergibt sich aus der Positionsinformation der bekannten Menge, wenn diese sich im Zuordnungsbereich der Menge befindet. In der Praxis findet dieses Prinzip Anwendung bei der Proximity Detection oder auch der Positionsbestimmung mittels GSM-Ortung. 9

13 2 Positionsdaten auf mobilen Geräten Abbildung 2.3: Graphenbasiertes Modell am Beispiel der Freundschaftsbeziehungen eines sozialen Netzwerks Graphenbasierte Modelle Unter dem Prinzip graphenbasierter Modelle werden Verbindungen von Entitäten zusammengefasst. Sie bestehen in der einfachsten Form aus Knoten und knotenverbindenden Kanten. Sie können sowohl physische als auch abstrakte Netzwerke repräsentieren und müssen sich keineswegs an realen Abmessungen orientieren. Für abstrakte, graphenbasierte Verbindungen wären beispielhaft Verknüpfungen von einzelnen Seiten eines Internetangebots (Sitemaps) oder Freundschaftsbeziehungen in sozialen Netzwerken, die in Abbildung 2.3 veranschaulicht sind, anzuführen. Straßen-, Telefon- oder Wasserversorgungsnetze stehen hingegen für physikalische Netzwerke. In beiden Netzwerkarten können Kanten gerichtet, ungerichtet und/oder gewichtet sein. So ist es möglich, dass die Entfernung zweier Knoten/Entitäten durch die Kantenlänge modelliert wird und eine gerichtete Kante im Beispiel des Straßennetzes eine Einbahnstraße repräsentiert. 10

14 2 Positionsdaten auf mobilen Geräten Semantische Modelle Mit der Erstellung eines semantischen Modells setzt man Daten in einen logischen Bezug zueinander, welcher formalen Kriterien genügt. Vorteilhaft hierbei ist, dass das Modell einfach durch Menschen, als auch durch Rechner interpretiert werden kann. Ein solches Modell wird durch Abbildung 2.2 veranschaulicht. Dieses Modell ist immer bezüglich eines Rahmens und einer Perspektive definiert um unwesentliche Bestandteile auszublenden. Die Perspektive ist in der Regel so gewählt, dass sie der Anwender- oder Administrationssicht entspricht. Zur Erarbeitung semantischer Modelle werden häufig Entity-Relationship-Modelle verwendet, welche sich durch leichte Überführbarkeit in relationale Datenbankmodelle oder objektorientierte Konzepte auszeichnen. 11

15 3 Kontext 3.1 Klärung des Kontextbegriffs Damit Applikationen sinnvoll mit Kontext umgehen können, bedarf es einer Formalisierung des Begriffs. [Kor05], p28 versucht eine Definition: Context is any information that can be used to characterize the situation of entities (i.e., whether a person, place, or object) that are considered relevant to the interaction between user and an application, including the user and the application themselves. Darüber hinaus betont [FlPrRa04] die Notwendigkeit, dass die Daten möglichst effektiv durch Maschinen interpretierbar sein müssen, um sie automatisiert nutzen zu können. Es gilt also der Anwendung zu ermöglichen, den Kontext semantisch zu erschließen. Hierfür müssen strukturelle Anforderungen vorgegeben werden. 3.2 Kontextarten [Kor05] konkretisiert, auf seiner Definition aufbauend, vier elementare Kontextarten, die er folgendermaßen auflistet: 1. Informationen die mit der Identität des Nutzers verbunden sind 2. Standort 3. Momentane Zeit 4. Informationen, die die Aktivität des Nutzers widerspiegeln Neben der Unterteilung nach inhaltlichen Aspekten untersuchte [MoLe09], p26f Kontextinformationen anhand ihrer Quelle. Aus einer anwendungsbezogenen Perspektive wird im Resultat zwischen Nutzerkontext und Einstellungen, Umgebungskontext und datenbankspezifischen Kontext unterschieden. Diese Kategorisierung wurde konkret im Hinblick auf die Entwicklung eines kontextbezogenen Datenbanksystems vorgenommen, dass höhere Relevanz der Antworten durch zusätzliche Kontextinformationen garantieren soll. Weiter wird bei jeder der drei Kontextarten zwischen statischem und dynamischen Kontext unterschieden. 12

16 3 Kontext Nutzerkontext und Einstellungen Der statische Teil dieser Kontextart wird durch die Einstellungen beziehungsweise Präferenzen repräsentiert. Diese Informationen sind personenbezogene Daten, die über einen längeren Zeitraum konstant bleiben. Im Gegensatz hierzu stellt der Nutzerkontext dynamische Informationen dar. Beispielhaft zu nennen sind hier Positionsdaten, Körpertemperatur oder Stimmung der Person. Datenbankspezifischer Kontext Die Kontextinformationen liegen hier in Datenbanken vor und werden nach Anfragen an das Endgerät übermittelt. Die in der Datenbank vorliegenden Datensätze sind dabei grundsätzlich auf den bestimmten Einsatzzweck zugeschnitten. Umgebungskontext Der Umgebungskontext verhält sich in etwa wie der Nutzerkontext, variiert jedoch stetig mit der Position des Nutzers. Verändert der Anwender seinen Standort, ändert sich, je nach Festlegung des Umgebungsbegriffs, auch das Umfeld und damit der zu betrachtende Kontext. Zieht man den Stadttourplaner aus der Einleitung als Beispiel heran, so ist der Umgebungskontext in München ein anderer als in Hamburg. Mit Hilfe dieser Kontextart wird eine höhere Relevanz der Antworten bei Anfragen erreicht, indem zusätzliche Umgebungsinformationen einbezogen werden. 3.3 Kontextquellen für mobile Geräte Nachdem nun zwei verschiedene Kategorisierungsversuche untersucht wurden, ergeben sich zwei Möglichkeiten, die zum Zweck der Gewinnung von Kontextinformationen geeignet sind. Zum einen können Kontextdaten direkt am Gerät ermittelt und zum anderen via Datenverbindung aus Datenbanken ausgelesen werden [KoHeIK08]. Für die Ermittlung direkt am Gerät bieten mobile Geräte eine Vielzahl an Sensoren. Hier zu nennen wären beispielsweise GPS, Mikrofone, Neigungssensoren oder Kameras. In einigen Fällen ist es außerdem möglich, dass der Nutzer Kontextinformationen direkt über das User Interface in die Anwendung einspeist, beispielsweise sein Befinden oder eine Beobachtung die er gemacht hat. 13

17 3 Kontext 3.4 Herausforderungen der Kontextverarbeitung auf mobilen Geräten Möchte man Kontextdaten über den einfachen Anwendungszweck der Präsentation hinaus nutzen, gibt es einige Probleme, die zu lösen sind. Das zeigen schon die oben genannten Versuche einer Definition. So merkt [Kor05], p31 an, dass eine anerkannte Menge von wohldefinierten beziehungsweise genormten Kontextinformationen nicht zu finden ist oder spätestens an zukünftigen Anforderungen scheitern wird. Folgend werden drei wichtige Aspekte von Kontext auf mobilen Geräten aufgezählt, die es zu beachten gilt. Verfügbarkeit Es ist in der Regel nicht sichergestellt, dass Kontextdaten am Endgerät verfügbar sind. Gerade im mobilen Umfeld kann eine Datenverbindung abbrechen oder der GPS-Empfang kann im Wald gestört werden. Im schlechtesten Fall kann es passieren, dass keinerlei Kontextinformationen vorliegen. Diese Problematik ist durch die Verteilung der Kontextquellen bedingt [SaDeAb99], die aber aufgrund der Ressourcenknappheit mobiler Geräte notwendig ist. Im Endeffekt ist zu hinterfragen, was die Mindestanforderungen an die Verfügbarkeit von Kontextinformationen sind, um die Funktionsfähigkeit der Applikation zu garantieren. Struktur Es herrschen hohe Anforderungen an die Strukturierung von Kontext. Eine sinnvoll gewählte Struktur ist maßgeblich verantwortlich für eine einfache und ressourcensparende Verarbeitung. Dabei gibt es nicht das perfekte Format für eine Kontextart, denn dieses ist immer auch abhängig vom Anwendungszweck. Da neben den Kontextdaten aus internen Sensoren viele Informationen aus externen Diensten stammen, sind diese häufig nicht an die Anforderungen der Applikation angepasst. [SaDeAb99] schlägt deshalb eine Normalisierung der Datenstruktur für das Gerät vor. So ist sichergestellt, dass Dienste und Sensoren, die unterschiedliche Datenformate liefern, durch geringe Anpassungen ausgetauscht werden können. 14

18 3 Kontext Semantik Kontext muss nach [Kor05], p35 durch Maschinen interpretiert werden können, damit man basierend auf dessen Inhalt Aktionen durchführen kann. Voraussetzung für eine sinnvolle Interpretation der Kontextdaten sind strukturelle Vorgaben an denen sich die Applikation orientieren kann. Durch die verteilten heterogenen Kontextquellen kann Kontext in unterschiedlichen Formaten vorliegen, selbst wenn sie inhaltlich identisch sind. Idealerweise sollte eine Applikation solche Fälle erkennen. Voraussetzung hierfür ist, dass die Anwendung diese Formate von sich aus ineinander überführen kann, oder diese Aufgabe an externe Dienste delegiert. Die Notwendigkeit solche Umwandlungen zu delegieren kann darauf beruhen, dass zusätzliche Informationen zur Berechnung benötigt werden oder dass die Rechen- und Speicherleistung auf dem betroffenen Gerät einfach nicht ausreichend sind. Diese Anforderung wird deutlich, wenn man die Modellierung von Positionsdaten erneut betrachtet. Es wurden vier Modellarten vorgestellt, die alle mehr oder minder ineinander überführbar sind, wobei dafür jedoch in einigen Fällen zusätzliche Informationen notwendig sind. Auch wichtig zu beachten ist, dass diese Transformationen nicht bijektiv sein müssen. Eine konkrete Koordinate hat in der Regel ein Objekt, in dessen Fläche/Körper sie liegt. Umgekehrt besitzt ein Körper (ein Haus) eine unbegrenzte Anzahl an Koordinaten, die ihm zugeordnet sind. Transformationen sind folglich nicht zwingend sinnvoll und zum Teil abhängig vom Inhalt der Informationen, die auf dem Gerät vorliegen. Darüber hinaus kann Kontext uneindeutig sein, das heißt, es bestehen also verschiedene Interpretationsmöglichkeiten, bedingt durch verschiedene Formate, Uneindeutigkeit der Sprache an sich, oder das Fehlen von wichtigen Informationen [Sa- DeAb99]. Ein passendes Beispiel für Uneindeutigkeit ist die Spracheingabe über das Handy. Das Gerät ist anhand des bloßen Wortes Paar nicht fähig zu entscheiden, ob es sich um paar oder Paar handelt. Durch die zusätzliche Information, dass es sich um das Paar Socken handelt, wird die Aussage eindeutig. Ist diese unsichere Situation nicht aufzulösen, empfiehlt es sich, beide Alternativen in der weiteren Programmausführung mitzuführen und sich nicht voreilig auf eine Interpretationsmöglichkeit festzulegen. Zu einem späteren Zeitpunkt - es sei an die Eigenschaften verteilter Systeme erinnert - ist es durchaus möglich, dass die fehlende Information, die für eine korrekte Deutung notwendig ist, noch eintrifft. 15

19 3 Kontext Kontextdaten, die auf unseren Geräten vorliegen, sind immer durch Modellierung entstanden. Ein Grundmerkmal der Modellierung ist, dass Informationen abstrahiert und vereinfacht werden müssen. Man muss sich also fragen, ob das vorhandene modellierte Abbild der Realität selbiger überhaupt ausreichend entspricht, um diese interpretieren zu können [Kor05], p31. Neben dem Fall, dass die Daten fehlerhaft sind, ist durchaus interessant, wie veraltete Daten behandelt werden. Wichtig ist dabei die Erkenntnis, ob die vorliegenden Daten auf Plausibilität geprüft werden können. In der Datenbank mag das Restaurant noch geöffnet sein - In der Realität existiert es jedoch nicht mehr. An solchen Stellen müssen dem Nutzer manuelle Eingriffsmöglichkeiten zur Verfügung stehen, um Kontextinformationen zu korrigieren oder zu vervollständigen [Gre01]. 3.5 Formate zur Modellierung und zum Austausch von Kontext Anwendungsentwickler müssen im konkreten Fall über die Datenformate entscheiden, in denen die Kontextdaten im Programm letztendlich vorgehalten werden sollen. Dabei muss man zwischen dem Modellierungsprozess und die daraus folgende Repräsentation im Programm und den Austauschformaten unterscheiden. Austauschformate haben die Aufgabe die Kontextdaten von Diensten zu Anwendungen und von Anwendungen zu verschiedenen Diensten zu überliefern. Dabei weisen sowohl Dienste als auch Anwendung Schnittstellen auf, die aufeinander abgestimmt sein müssen. Ein Teil dieser Schnittstellendefinition ist das Datenformat. Beim Datenformat ist es von großer Bedeutung, dass durch die Transformation des internen Datenmodells in das Austauschformat und zurück keine Informationen verloren gehen. Darüber hinaus sind in Hinblick auf die mobile Nutzung des Austauschformats weitere Aspekte zu berücksichtigen. Kompaktheit Das Austauschformat muss eine möglichst geringe Bandbreite in Anspruch nehmen. Das Verhältnis von Auszeichnungs- und Nutzzeichen ist dabei möglichst weit zugunsten der Nutzzeichen auszurichten. Wichtig hierbei ist außerdem, dass weder implizite noch explizite Informationen durch die Komprimierung verloren gehen. 16

20 3 Kontext Flexibilität Um dem Parameter der Flexibilität zu genügen, muss das Format möglichst viele verschiedenartige Inhalte gut fassen können. Dazu zählen auch binäre Daten wie Bilder oder Audiodaten. Auch wichtig ist, dass das Format das Ausgliedern einzelner Informationsteile unterstützt, da oft nicht der komplette Informationsblock von Interesse ist. Robustheit und Zuverlässigkeit Beim Einsatz mobiler Geräte kann es zu Übertragungsfehlern kommen, so dass nur ein Teil der Daten oder leicht fehlerhafte Daten übertragen werden (Was durch das verwendete Protokoll eigentlich ausgeschlossen werden sollte). Auch kann es vorkommen, dass ein angesprochener Dienst eine falsche Zeichenkodierung verwendet hat oder nicht zu hundert Prozent schnittstellengerecht antwortet. Eine wünschenswerte Eigenschaft des Formates wäre es, wenn der Parser fehlerhafte Informationen ignoriert und dabei korrekte Daten auslesen kann. Hohe Verbreitung und Offenheit Das Format sollte in der Praxis eine hohe Verbreitung aufweisen. Das erhöht die Wahrscheinlichkeit, dass externe Dienste diese Formate bereits nutzen und man keine Insellösungen verwendet. Es wird außerdem sichergestellt, dass auf diesem Format aufbauende Lösungen entstehen, welche wiederverwendet werden können. Auch sollte die Nutzung offener Formate bevorzugt werden, da so eine Interoperabilität sichergestellt werden kann, zu mindestens in dem Maß, dass sie durch eigene Ressourcen nachträglich umgesetzt werden kann. Effiziente Verarbeitungsmöglichkeiten Da eine De- und Enkodierung der Daten durch das mobile Gerät vorgenommen werden muss, ist es wichtig, dass dies effizient geschehen kann. Der Nutzer erwartet ein zeitnahes Feedback, wenn er Daten abruft. Durch Wartezeiten und hohe Auslastung des Gerätes kann die Bedienung gestört werden. 17

21 3 Kontext Abbildung 3.1: Strukturierung einer Städteliste mit JSON Manipulierbarkeit Parser potentieller Formate sollten die Möglichkeit bieten, die Daten direkt und umfangreich zu bearbeiten. Dazu gehört das Löschen, Bearbeiten und Hinzufügen einzelner Teile ohne die Daten in eine eigene Repräsentation übertragen zu müssen. Da in den meisten mobilen Anwendungen das Transmission Control Protocol (TCP) zur Kommunikation und zum Austausch von Daten verwendet wird und sich diesbezüglich etabliert hat, wird es in den weiteren Betrachtungen als Übertragungsprotokoll angenommen JavaScript Object Notation (JSON) JSON bietet die Möglichkeit Daten zu strukturieren und zu verschachteln. Besonderes Merkmal dieses Datenformats ist, dass es sehr kompakt daherkommt und sich deshalb für Umgebungen, in denen eine geringe Bandbreite oder Rechenkraft vorhanden ist, eignet. Es ist folglich sehr gut zugeschnitten für den Einsatz auf mobilen Geräten und deren Kommunikation mit externen Diensten. Zu beachten hierbei ist aber, dass binäre Daten nicht Teil der Beschreibung sein können. Es ist aber möglich diese mit Hilfe von Verweisen zu referenzieren um sie dynamisch synchron oder asynchron nachzuladen. Auch sonst stehen nur die wesentlichsten Datentypen zur Verfügung. Hier zu nennen sind Zahlen, boolesche Werte, Strings, Arrays, Nullwerte und Unterobjekte [JSON11]. Dabei lässt sich die Struktur eines JSON-Objekts nicht weiter beschränken. Das führt zu der Notwendigkeit, dass der Aufbau eines solchen Objektes auf der Empfängerseite durch das Programm geprüft werden muss und es dafür keine einfachen Automatismen gibt, die diese Validierung von der Programmlogik trennen. Ein Beispiel für ein JSON-formatiertes Objekt ist Abbildung 3.1 zu entnehmen. 18

22 3 Kontext Abbildung 3.2: Beispiel einer XML-Datei (links) mit DTD (rechts) Extensible Markup Language (XML) Die Extensible Markup Language ist eine Sprache, die häufig zu Modellierungszwecken genutzt wird. XML besteht aus Nutz- und Auszeichnungsdaten (Tags), wobei den Nutzdaten durch die Auszeichnungsdaten eine Bedeutung gegeben wird [Mo08]. Dazu werden die Nutzdaten von Auszeichnungsdaten, die einen beschreibenden Charakter haben, eingerahmt. Ein Beispiel dafür ist in Abbildung 3.2 dargestellt. XML lässt sich alternativ auch als Baum darstellen. Das heißt es bildet eine hierarchische Struktur in der die Nutzdaten eingeordnet werden. In seiner einfachen Form ist XML sehr flexibel, aber wenig restriktiv und detailliert bezüglich seiner Struktur. Jedoch besteht die Möglichkeit mittels Document Type Definition (DTD) verbindliche Regeln für die Struktur einer XML-Datei festzulegen. So kann ein konkretes XML-Dokument gegen eine DTD geprüft und validiert werden [XML11]. Dieser Aspekt ist besonders in Bezug auf den Datenaustausch sehr interessant, da Absender und Empfänger plattform- und applikationsunabhängig eine Definition der XML-Struktur besitzen. So kann die Validation weitgehend aus der Programmlogik herausrationalisiert werden. Neben der DTD gibt es das XML-Schema (XSD), welches eine detaillierte Definition der Nutzdaten mittels regulärer Ausdrücke erlaubt und Namensräume unterstützt. Dabei ist XML-Schema, im Gegensatz zu DTD, selbst in XML verfasst. 19

23 3 Kontext Mit der Extensible Stylesheet Language (XSL) existiert eine Möglichkeit XML in viele verschiedene andere Repräsentationen umzuwandeln. [BoAu05] beispielsweise verwendet diese Technik um XML in OWL zu transformieren Web Ontology Language (OWL) Die Web Ontology Language dient der Beschreibung von Informationen, so dass sie von Computern entsprechend ihrer Semantik interpretiert und behandelt werden können. Mit Hilfe dieser Sprache kann man beispielsweise das einfache semantische Modell in Abbildung 2.2, für Maschinen interpretierbar, umsetzen. OWL stammt aus dem Bereich des Semantic Web und wird durch das World Wide Web Consortium (W3C) seit 2004 empfohlen. Die OWL ist dabei an die Resource Description Language (RDF) angelehnt, welche der Repräsentation von Metadaten dient. Die OWL erweitert dessen Aussagekraft jedoch deutlich. So ist es mit RDF nicht möglich Verbindungen zwischen Eigenschaften und Ressourcen zu definieren [RhMo09]. Im Jahr 2009 wurde die OWL durch die OWL 2 abgelöst, welche strukturell wenig Neuerungen mit sich brachte, jedoch einige funktionale Erweiterungen einführte [OWL11b]. OWL besitzt drei Untersprachen, die verschiedenen Ansprüchen genügen: OWL Lite - Eine eingeschränkte Version der Web Ontology Language, die beispielsweise nur Klassen mit Namen erlaubt oder Kardinalitäten von 0 oder 1 zulässt. Der Vorteil bei dieser Untersprache ist, dass sie einen überschaubaren Implementationsaufwand bedeutet und für bestimmte Anwendungen vollkommen ausreichend ist. OWL DL - Diese Version bietet das gleiche Vokabular an, dass OWL Full zur Verfügung steht. Kann jedoch nicht alle Typen miteinander in Verbindung bringen. So können Klassen nicht mit Eigenschaften verglichen werden. OWL Full - Ermöglicht die vollständige Nutzung der Möglichkeiten der Web Ontology Language. Dabei ist jede OWL Lite eine gültige OWL DL und jede OWL DL ist eine gültige OWL Full [OWLa]. 20

24 3 Kontext OWL eignet sich sehr gut als Repräsentation und zur Modellierung von Kontextinformationen. Zum Austausch der Daten in ressourcenbeschränkten Umgebungen ist es jedoch, ähnlich wie XML, nur bedingt nutzbar. Es besteht jedoch die Möglichkeit, die Informationen in JSON oder ähnliche Formate zu transformieren, um sie zwischen den verschiedenen Diensten und mobilen Geräten auszutauschen. Für eine kontextabhängige Anwendung sind semantische Zusammenhänge zwischen Informationen besonders wichtig, wenn sie basierend auf inhaltlichen Kriterien Entscheidungen fällen oder Aktionen durchführen müssen. Dies ist ab dem Punkt entscheidend, ab dem rein strukturelle Untersuchungen der Kontextinformation nicht mehr genügen. Eine gute Interpretierbarkeit ist vor allem im mobilen Umfeld sinnvoll, da hier häufig heterogene Informationenarten auflaufen, die aus dynamisch verteilten Quellen stammen. Da durch OWL einzelne Objekte und Eigenschaften logisch miteinander verknüpft werden können, lassen sich auch dementsprechende Operationen auf selbige ausführen. Ein weiterer besonderer Aspekt von OWL ist die Standardisierung der Interpretation, mit dessen Hilfe verschiedene Geräte und Services gleiche Daten auch wirklich gleich interpretieren können [PeCo05] Bewertung Bei Betrachtung der oben genannten Formate und Sprachen zur Strukturierung, Modellierung und zum Austausch von Kontextdaten fällt auf, dass momentan keine perfekte Lösung für ein mobiles Umfeld existiert. Zwar kann man mit OWL und XML die Daten sehr gut modellieren, auswerten und interpretieren, jedoch sind bezüglich der Kompaktheit im Nachteil gegenüber der Javascript Object Notation. Diese hat wiederum den Nachteil, dass besonders implizite Informationen, die beispielsweise durch die Struktur der OWL vorgegeben werden, zusätzlich in das konkrete JSON-Objekt hinein modelliert werden müssen, damit die ursprüngliche Semantik nicht verloren geht. Gleichzeitig bietet es auch verschiedene Möglichkeiten der Optimierung der Formate. Da oftmals Informationen nicht im vollen Umfang von externen Diensten oder Geräten benötigt werden, sondern nur einzelne Bestandteile, die dann automatisch in Gesamtkontext eingeordnet werden, ist eine Transformation oder Manipulation der Daten ohnehin von Nöten. Grundsätzlich 21

25 3 Kontext wird aber klar, dass eine Transformation/Abstraktion zwischen der internen Repräsentation der Kontextdaten und der nach außen hin offenen Schnittstelle vorhanden sein muss. Dass sich verschiedene Formate nicht ausschließen müssen ist [ErMaRa07] zu entnehmen. Hier werden die vorgestellten Formate XML und OWL zur Modellierung der Kontextdaten genutzt und später zum Datenaustausch in XML transformiert. 22

26 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Aufbauend auf den Erkenntnissen, die über Kontext gesammelt wurden, gibt es einige Frameworks, die sich die Behandlung solcher Daten zum Ziel gesetzt haben. Dabei gibt es nach [Wi01] drei verschiedene Architekturen, um mit Kontext umzugehen. 1. Widget-basierte Architekturen, die sich an dem Aufbau von GUI-Frameworks orientieren. 2. Netzwerkorientierte Dienste, die eine lose Koppelung der verschiedenen Komponenten nutzen und Kommunikation über Webtechniken einsetzen. 3. Blackboard Architekturen, welche eine datenzentrische Struktur besitzen, über die ein Informationsaustausch erfolgt. Im Folgenden werden diese Architekturen anhand von konkreten Umsetzungen genauer erläutert. 4.1 Widgetbasierte Architektur am Beispiel Context Toolkit Das Context Toolkit ist ein javabasiertes Framework. Es wurde im Jahr 2001 entwickelt und orientiert sich am Paradigma graphischer Benutzeroberflächen, wobei Kontextdaten das Gegenstück zu den UI Widgets darstellen [CoTo11]. Entsprechend werden die Komponenten, die einzelne Kontextdaten repräsentieren, als Context Widgets bezeichnet. Diese Designentscheidung begründet [SaDeAb99] mit folgenden Eigenschaften von Widgets: Die Komplexität verschiedener Kontextquellen werden durch Abstraktion versteckt. Technische Aspekte von Sensoren sind für die Programmlogik in der Regel unwichtig und sollten deshalb von ihr klar getrennt sein. Auch die Kenntnis über technische Details ist so für die konkrete Anwendung nicht mehr als Voraussetzung notwendig. Auch Veränderungen der internen Arbeitsweise von Diensten oder Sensoren haben somit geringe bis gar keine Konsequenzen für die Umsetzung der Anwendung. Widgets verfügen über Events, welche einen Callback auslösen. So können sich verschiedene Teile der Applikation über Veränderungen der Kontextinformationen oder bestimmte Ereignisse informieren lassen und angemessen auf diese reagieren. Widgets lassen sich hervorragend wiederverwenden und ineinander verschachteln. Dabei spielt es für die übergeordneten Widgets keine Rolle, welche untergeordneten Widgets sie 23

27 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Abbildung 4.1: Schematischer Aufbau des Context Toolkit (links) und Beispiel eines Widgets (rechts) [Kor05] besitzen und umgekehrt, solange diese ein bestimmtes Protokoll implementieren. Diese Unabhängigkeit erlaubt es dem Widget über die aktuelle Applikation hinaus in andere Programme integriert zu werden. Der Aufbau des Context Toolkits im Konkreten lässt sich der Abbildung 4.1 entnehmen, wobei die Pfeile typische Interaktionsrichtungen darstellen. Hier ist die Einordnung der Widgets, Widget Services und Sensoren im Gesamtkontext einer Anwendung zu sehen. Dabei ist es vorgesehen, dass Sensoren und sogar Widgets selbst verteilt sein können. [SaDeAb99] und [Kor05], p35ff abstrahieren aus dem direkten Umfeld des Widgets vier verschiedene Komponenten: Sensoren und andere Quellen, die Rohdaten für die Applikation liefern. [SaDeAb99] fasst diese als Generatoren zusammen. Interpreter bereiten diese Rohinformationen auf und abstrahieren sie, um sie den Widgets zur Verfügung zu stellen. Sie können aber auch dazu dienen Kontextinformationen von Repräsentation A nach Repräsentation B zu transformieren [Kor05], p36. Der Aggregator ist die Sammelstelle der aufbereiteten Daten für die Anwendung. Er nimmt die Rohdaten entgegen und reicht sie weiter an die Interpreter, um nützliche Daten für die Anwendung zu erhalten. Dabei repräsentiert der Server auch die Schnittstellen des Widgets nach außen, um mit anderen Widgets oder Applikationen zu kommunizieren. Der Server 24

28 4 Mobile Frameworks und Middlewares zur Kontextbehandlung hat ebenfalls die Aufgabe, eine Mehrzahl an Widget-Instanzen zu verwalten. Am Discoverer können sich die Widgets, Server und Interpreter registrieren. Eine Applikation kann beim Start nun über den Discoverer ermitteln, wo die benötigten Komponenten zu finden sind. Das Widget und der Widget Service bilden außerdem eine Einheit, wobei die Kommunikation der Applikation mit dem Widget nur über den Widget Service stattfindet. Der Widget Service stellt also die Schnittstelle des Widgets nach außen dar. Ein Beispielszenario kann folgendermaßen aussehen: Die Widgets, Aggregatoren und Interpreter haben sich über den Discoverer registriert, so dass sie für die anderen Komponenten sichtbar sind. Das Widget weist den Widget Service regelmäßig oder eventbasiert an Sensorinformation abzurufen und sie dem Widget, via Interpreter abstrahiert, zu übermitteln. Zu einem bestimmten Zeitpunkt fragt der Aggregator, stellvertretend für die Applikation, über die Schnittstelle des Widget Service nach dieser Information, erhält die entsprechenden Kontextdaten und speichert diese ab. Dadurch muss die Applikation nicht verschiedene Quellen ansprechen, wenn sie die Informationen benötigt, was zu längeren Verzögerungen führen würde. Das Context Toolkit nutzt zur Kommunikation zwischen den einzelnen Komponenten XMLformatierte Datensätze, die über das Hypertext Transfer Protocol (HTTP) versendet werden. Das hat den Vorteil, dass möglichst viele Plattformen unterstützt werden. Bewertung Das Context Toolkit legt besonderen Wert auf Wiederverwendbarkeit und Abstraktion der Sensoren. [SaDeAb99] weißt aber auch auf die konstruktionsbedingten Schwächen von widgetbasierten Architekturen hin. So neigen Widgets dazu, trotz Abstraktion noch immer zu komplex zu sein und vor allem den Flexibilitätsansprüchen von Kontextinformationen nicht komplett zu genügen. Das Context Toolkit bietet zwar Möglichkeiten Kontextinformationen zu abstrahieren, auszutauschen und zu manipulieren, aber gerade das Zusammenspiel von Kontextdaten aus verschiedenen Quellen und von verschiedenen Widgets, die sich dynamisch ändern, sollte mit dieser Architektur schwer umsetzbar sein. 25

29 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Insgesamt weist dieses Framework eine relativ komplexe Struktur mit Komponenten auf, die verschiedene heterogene Bestandteile besitzen und sich unterschiedlich verhalten. Dies muss bei der Umsetzung beachtet werden. Zudem ist der Aspekt der Verteilung von Context Widgets und deren Komponenten nicht so stark ausgeprägt, dass er über bandbreitenschwache Netzwerkverbindungen performant ist. Das ist mit der ursprünglichen Umsetzung des Prinzips von Widgets zu begründen, bei der zwar Kommunikation zwischen mehreren Komponenten (die auch räumlich verteilt sein können) stattfindet, diese aber nicht die Charakteristika einer Verbindung von mobilen Geräten mit externen Sensoren und Datenbanken voll entspricht. Bei konkreten Anwendungen des Context Toolkit hat man häufig die volle Kontrolle über Sensoren und Dienste, die man anspricht. Durch die zügige Entwicklung von Webservices verändert sich dieser Sachverhalt aber zusehends. Man könnte zwar für jeden Webservice ein eigenes Widget implementieren, das die Kommunikation mit der Applikation regelt, der direkte Weg des Datenaustauschs ist jedoch im Allgemeinen zu bevorzugen. 4.2 Networked Services am Beispiel der Mobile Collaboration Architecture Networked Services ist eine Architektur, die sich am Aufbau von Netzwerken und deren Mechanismen orientiert. Folglich wird hier ein besonderer Schwerpunkt auf die Verteilbarkeit der einzelnen Komponenten gelegt. Die Services sind dabei so organisiert, dass sie unabhängig voneinander funktionieren [Kor05], p37. Sie sind somit lose gekoppelt. Die Mobile Collaboration Architecture (MoCa) ist ein Beispiel für diese Architektur, die basierend auf einer Reihe von APIs das Sammeln, Speichern und Verarbeiten von Kontextinformationen auf mobilen Geräten ermöglicht [ViSaRoBa08]. Die einzelnen Dienste existieren dabei unabhängig voneinander und kommunizieren via Netzwerkverbindung, beispielsweise (Wireless) LAN. Nach [ViSaRoBa08] verfügt jeder Dienst dabei über die Möglichkeit synchron oder asynchron angesprochen zu werden. 26

30 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Abbildung 4.2: Aufbau einer typischen MoCa-Anwendung [ViSaRoBa08] Aufbau MoCa teilt sich in benötigte und optionale Dienste sowie den Monitor-Dienst auf. Dabei ist es vorgesehen neue Dienste hinzuzufügen oder optionale nicht zu nutzen. Die Services sind entweder direkt miteinander verbunden oder werden durch den Ubiquitous Discovery Service koordiniert, so dass sie miteinander Informationen austauschen können. Das macht die einzelnen Dienste selbst zur Laufzeit austausch- und anpassbar. Im Folgenden werden einzelne benötigte und optionale Dienste kurz erläutert. Eine Anordnung der Komponenten lässt sich aus Abbildung 4.2 entnehmen. Bei dieser Darstellung ist jedoch darauf zu achten, dass der Aufbau beispielhaft ist und bestimmte Komponenten und Dienste anders gebündelt werden können und somit auch direkt auf dem mobilen Gerät vorliegen können. Monitor und Client Der Monitor sitzt im mobilen Gerät und ist für die Verwaltung der Sensoren zuständig. Dabei normalisiert er die Sensorwerte, um sie für die weitere Verwendung bereitzuhalten [ViSaRoBa08]. 27

31 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Hier sind als typische Vertreter zu nennen: Wireless Signalstärke IP-Adresse und Maske Aktueller Access Point ID und weitere erreichbare Access Points Freier Speicher GPS Positionsdaten Diese Sensordaten werden in regelmäßigen Abständen an den Context Information Service gesendet. Darüber hinaus ist eine Transformation der Positionsdaten mit Location Inference Service möglich. Momentan liegt nur eine Implementation des Monitors in ANSI C vor, da für bestimmte Hardwarekomponenten Treiber vorausgesetzt werden. Eine schnittstellengerechte Implementation ist jedoch grundsätzlich in jeder Programmiersprache möglich [MoCa11]. Der Client übernimmt die Kommunikation mit dem Applikationsserver und stellt das eigentliche Programm dar. Er organisiert also Anfragen und kümmert sich um die Behandlung der Daten auf dem Endgerät Context Information Service (CIS) Der Context Information Service empfängt und sammelt in regelmäßigen Abständen Kontext- Informationen von den Monitoren der Endgeräte. Er stellt diese Daten gleichzeitig anderen Services wie dem Location Inference oder Hybrid Positioning Service zur Verfügung. Anfragen an diesen Dienst werden entweder direkt gestellt oder es können eventbasierte Benachrichtigungen angefordert werden. Beispielsweise kann ein Dienst eine Benachrichtigung verlangen, wenn die restliche Akkulaufzeit eines bestimmter Clients fünf Prozent unterschritten hat. Location Inference Service (LIS) Der Location Inference Service hat im Allgemeinen die Aufgabe ortsbezogene Informationen anzubieten. Zum Beispiel liefert er zu einer Koordinate die Adresse oder die Stadt, in der sich der Client befindet. 28

32 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Event Communication Interface (ECI) Dieser Dienst ist elementar für die Kommunikation zwischen den verschiedenen Services und bietet einige Möglichkeiten des Informationsaustausches. Das Interface unterstützt eine subjectbased Subscription Methodik mit der Anfragen einmalig, wiederkehrend oder auch eventbasiert beantwortet werden können. Symbolic Region Manager (SRM) Der Symbolic Region Manager ist eine optionale Komponente der Mobile Collaboration Architecture, mit der es möglich ist, symbolische Regionen zu strukturieren. So lassen sich zum Beispiel ortsbezogene Regionen und Punkte erstellen, hierarchische Anordnung von Formen vornehmen oder symbolische Regionen verwalten. Diese Regionen können atomar vom LIS stammen und zusammengesetzt werden, oder andere Quellen haben [ViSaRoBa08]. Symbolische Positionsdaten werden somit in Bezug zueinander gesetzt, was weitere Operationen auf Positionsdaten ermöglicht. Zu nennen wäre hier eine Vergröberung von Positionsdaten oder die Transformation von Positionsdaten in eine andere Repräsentation. Hybrid Positioning Service (HPS) Verschiedene Daten können kombiniert werden, um (genauere) Positionsdaten zu gewinnen. Dabei ist es möglich verschiedene Sensoren oder Kontextinformationen zu nutzen. Der Hybrid Positioning Service besitzt die Fähigkeit verschiedene Daten auszuwerten und damit eine symbolische (via LIS) oder geografische (via CIS) Position zu liefern. Über Vektorberechnungen ist hier eine Überführung von symbolischen Regionen in geographische Positionen möglich. Ubiquitous Discovery Service (UDS) Dieser Dienst ermöglicht es den Klienten oder Diensten miteinander zu kommunizieren, falls diese nicht direkt miteinander verbunden sind. Dies wird durch das Speichern verschiedener Informationen wie Namen, Einstellungen und Adressen der angemeldeten Dienste und Clients erreicht 29

33 4 Mobile Frameworks und Middlewares zur Kontextbehandlung [SaEnRu04]. Besonders in dynamischen Umgebungen bietet dieser Service Vorteile. So kann je nach Konnektivität ein Service durch einen äquivalenten anderen Dienst ersetzt werden, ohne dass dritte Dienste oder Klienten davon etwas merken. Auch lässt sich die An- oder Abwesenheit verschiedener Dienste als Kontextinformation nutzen. Befindet sich beispielsweise ein bestimmter lokal beschränkter Dienst im Umkreis eines Nutzers, kann ihm dieser Service angeboten werden. Context Privacy Service (CoPS) Aus obigen Ausführungen wird ersichtlich, dass durch den Monitor und den Informationsaustausch ein Datenschutzproblem entstehen kann. Der Context Privacy Service soll dem Nutzer eine Möglichkeit geben seine preisgegebenen Kontextinformationen zu schützen. Dabei wird festgelegt, welche Informationen der CIS und LIS weitergeben darf und welche nicht. Der Nutzer kann frei bestimmen welche Anwendungen oder welcher Nutzer Zugang zu den Kontextdaten hat oder nicht. Bewertung Mit dem Mobile Collaboration Architecture lassen sich Anwendungen gut modularisieren und Ressourcen auf verschiedene Geräte verteilen. Die Kommunikation der Klienten mit den Servern kann durch die Querverbindungen der Serverdienste minimiert werden. So muss eine spezielle Kontextinformation nicht an drei verschiedene Dienste gesendet werden, sondern nur einmal an den CIS übermittelt werden. Der Informationsaustausch erfolgt dann, entsprechend des CoPS, über bandbreitenstärkere direkte Verbindungen zwischen den Servern der Dienste. Vorteilhaft ist auch die Kopplung von Informationen an Dienste. So steht nicht nur der reine Datensatz zur Verfügung, sondern auch eine Reihe an Funktionalitäten, die dem Gerät selbst nicht zur Verfügung stehen müssen. Darüber hinaus wird der Wartungsaufwand für eine Applikation minimiert, da bei Updates häufig nur der betroffene Service aktualisiert werden muss. Es ist weiter möglich, dass ein Dienst Daten gegen verschiedene Schnittstellen und Schnittstellenrevisionen liefert, so dass die Nutzung eines Services möglichst vielseitig geschehen kann. Kritisch zu betrachten ist trotz der Möglichkeit den Context Privacy Dienst nutzen zu können, dass Daten in jedem Fall an den Context Information Service und den Location Inference Service 30

34 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Abbildung 4.3: Kommunikationswege bei widget- und netzwerkbasierten Architekturen (a) und blackboardbasierten Architekturen (b) [Kor05], p81 gesendet werden. Deshalb ist eine Vertrauenswürdigkeit dieser Dienste wichtig. 4.3 Blackboards Blackboard-Architekturen wurden ursprünglich im Bereich der künstlichen Intelligenz genutzt [Wi01]. Dabei werden Nachrichten und Informationen über einen gemeinsamen Server (Blackboard) ausgetauscht, der dabei alle relevanten Daten vorhält und verwaltet [Jo07]. Die Prozesse können Nachrichten mit Mustern versehen, auf dem Board ablegen oder über ein Muster verschiedene Nachrichten und Informationen abrufen. Dabei gibt es verschiedene Möglichkeiten diese Muster zu definieren sei es über Tupel, reguläre oder logische Ausdrücke. Dabei unterscheidet [Kor05] zwischen Kontextdaten, die durch Sensoren auf dem Gerät gewonnen werden und Kontextdaten, die durch sonstige Quellen zur Verfügung stehen. Die Bedienung des mobilen Gerätes hängt unmittelbar von der Reaktionsgeschwindigkeit der Software ab. Schickt diese die Rohdaten der Sensoren zur Auswertung extra an den Server und wartet auf dessen Antwort, vergeht wertvolle Zeit. Deshalb ist die Kontextverwaltung der Sensoren durch das mobile Gerät zu übernehmen. 31

35 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Abbildung 4.4: Aufbau des blackboardbasierten Context Frameworks nach [Kor05], p99 Durch Abbildung 4.3 werden die unterschiedlichen Kommunikationswege zwischen den verschiedenen Architekturen verdeutlicht. So findet die Kommunikation von Server und Client, Dienst und Dienst oder Applikation und Widget miteinander bei widget- und netzwerkbasierten Architekturen immer direkt statt. Im Gegensatz dazu dient das Blackboard als Abstraktion und Vermittler zwischen Konsument und Produzent der Kontextdaten. Das macht einen Discovery- Service, wie er in der netzwerkbasierten Architektur genutzt wird, überflüssig. Auch wird der Zugriff auf die Daten zentral gesteuert und kontrolliert. So werden Kausalitätsfehler und Synchronitätsprobleme vermieden, die zum Beispiel bei der gleichzeitigen Manipulation von Kontextinformationen in netzwerkbasierten Architekturen auftreten können. Aufbau [Kor05], p98 ff teilt die Architektur in drei Schichten ein: die Applikations-, Server- und Produzentenschicht. Die Blackboard-Architektur ist dabei so konstruiert, dass die Serverschicht ohne weitere Veränderungen in anderen Anwendungen wiederverwendet werden kann und nur Konfigu- 32

36 4 Mobile Frameworks und Middlewares zur Kontextbehandlung rationen an ihr durchgeführt werden müssten. Die Applikations- und Produzentenschicht werden um dieses Blackboard herum implementiert, wobei die Kopplung dieser beiden Komponenten mit dem Server auch hier relativ lose realisiert wird. Abbildung 4.4 zeigt, wie die Schichten detailliert aussehen und miteinander verbunden sind. Applikationsschicht In der Applikationsschicht befinden sich die verschiedenen Anwendungen und der Customizer. Die einzelnen Applikationen können direkt mit dem Context Manager kommunizieren, um Kontextdaten abzufragen oder sie lassen sich eventgesteuert über bestimmte Ereignisse informieren. Die Art und Weise, wie sie die Daten letztendlich nutzen, ist der Programmlogik überlassen. Mit Hilfe des Customizers lässt sich steuern, bei welchen Ereignissen, die Applikation durch die Serverseite informiert wird [Kor05], p109. Dies ist nicht nur zum Implementationszeitpunkt möglich, sondern auch zur Laufzeit. Über persönliche Einstellungen kann der Nutzer sich so für bestimmte Events an- und abmelden. Serverschicht Die Serverschicht besteht aus dem Context Manager, der Script-Engine und dem Activator. Die beiden letzteren Komponenten werden zusammengefasst als Application Controller bezeichnet. Der Context Manager nimmt die Daten der Kontextquellen entgegen und verteilt sie an die Anwendungsinstanzen [Kor05], p100f. Der Application Controller kann Events auf Server- und Produzentenseite entgegennehmen und entsprechend Aktionen ausführen. Dabei ist es auch möglich, dass er diese an die Applikations- Instanzen weiterreicht, wenn sie über bestimmte Veränderungen informiert werden möchten. Produzentenschicht Zur Produzentenschicht zählen die Kontextquellen, Kontext-Abstraktoren und der sogenannte Change Detector. Die Aufgabe der Kontextquellen ist es, Daten, die über eine interne oder externe Quelle gewonnen werden, an den Context Manager weiterzureichen. Dabei übernehmen die Abstraktoren die Aufgabe die gewonnenen Daten in verschiedene Formate zu transformieren, um sie beispielsweise für Menschen oder Maschinen lesbar zu machen. 33

37 4 Mobile Frameworks und Middlewares zur Kontextbehandlung Damit die Kontextdaten, die dem Context Manager vorliegen auch immer denen der realen Welt entsprechen, ist es nötig bei Veränderungen der Datensätze in den externen Quellen, den Context Manager darüber zu informieren. Dabei sieht [Kor05], p106 vor, dass dies eventbasiert umgesetzt wird. Nachdem ein solcher Event den Context Manager erreicht, aktualisiert dieser seine Datenbasis über die Kontextquelle. Bewertung Ziel des blackboardbasierten Ansatzes ist es, die Kommunikation zwischen den verschiedenen Instanzen zu minimieren und die Komplexität zu senken. Dabei wird im Gegensatz zum netzwerkbasierten Ansatz die Anzahl der Protokolle, Formate und geöffneten Netzwerkverbindungen möglichst klein gehalten. In Hinblick auf den mobilen Einsatz hat dieses Vorgehen den Vorteil, dass das portable Endgerät noch weniger Kommunikationslogik implementieren muss. So bestehen weniger Synchronitätsprobleme und die Daten sind mit höherer Wahrscheinlichkeit immer noch gültig, wenn sie das Gerät erreichen, da alle Repräsentationen der Daten zentral berechnet werden und ohne Umwege direkt an das Gerät gesendet werden. Nachdem der netzwerkbasierte Ansatz gegenüber dem widgetbasierten Prinzip, vor allem die Kontextquellen und Berechnungen auf externe Dienste verteilt hat, um Ressourcen auf dem mobilen Gerät zu schonen, erweitert der Blackboard-Ansatz diese Einsparungen noch auf den Kommunikationsaufwand. Das mobile Gerät muss so nur gegen eine externe Schnittstelle implementiert werden, was sich positiv auf die internen Ressourcen und die Leistungsaufnahme auswirkt. 34

38 5 Möglichkeiten zur Verteilung von Eventund Kontextdaten auf mobilen Geräten Ein mobiles Gerät erzeugt eine Vielzahl von Kontextdaten. Gleichzeitig existieren viele potentielle Dienste, die mit diesen Daten arbeiten möchten. Aus diesem Grund ist es notwendig, eine sinnvolle Verteilung der Informationen zu ermöglichen. 5.1 Aspekte der Verteilung von Event- und Kontextdaten Nachdem Eventdaten ermittelt wurden, ist es wichtig, diese Informationen intelligent an die verschiedenen Dienste zu verteilen. Hierbei solltea auf die Eigenheiten der mobilen Umgebung geachtet werden. Gleichzeitig müssen die Anforderungen der Services möglichst genau erfüllt werden. So stehen mitunter Echtzeitübermittlung im Widerspruch zu den begrenzen Ressourcen des Smartphones. Im Folgenden werden Kriterien angeführt, die die Auswahl einer geeigneten Verteilungsarchitektur erleichtern sollen. Kontrolle über die Inhalte der versendeten Daten Sowohl für den empfangenden Dienst, als auch für den Nutzer ist es wichtig, entscheiden zu können, welche Informationen gesendet werden. Der Nutzer muss entscheiden oder zumindestens nachvollziehen können, welche Daten wohin gesendet werden. Darüber hinaus sind für ihn auch die Bedingungen, unter denen ein Datensatz versendet wird von Belang, denn auch diese können implizite Informationen enthalten. Sendet ein Nutzer seine kompletten Kontextdaten an einen externen Dienst, der diese Daten weiter nutzt, muss dieser auch vertrauenswürdig sein. Ist der Dienst an speziellen Daten interessiert, sollte er die Möglichkeit haben, auch nur diese zu erhalten. So können zum Beispiel auch bereits bestehende Schnittstellen ohne Anpassung angesteuert werden, so dass Veränderungen nicht notwendig sind. Der Umfang der versendeten Daten kann durch eine genaue Abstufung der benötigten Informationen minimiert werden. Besonders im Hinblick auf die beschränkte Netzwerkanbindung mobiler Geräte ist dieser Aspekt wichtig. 35

39 5 Möglichkeiten zur Verteilung von Event- und Kontextdaten auf mobilen Geräten Kontrolle über den Verteilungszeitpunkt Nicht nur in den geforderten Inhalten unterscheiden sich die Dienste. Auch die Frequenz, in der Daten angefordert werden kann variieren. So können Daten einmalig, in bestimmten Intervallen, aber auch beim Eintreten von Ereignissen gesendet werden. Besonders die ereignisgesteuerte Verteilung sollte sehr flexibel sein, um den jeweiligen Anforderungen zu genügen. Auch die Entkopplung von versandauslösenden Ereignissen und den versendeten Daten sollte ermöglicht werden. So können die Daten sowohl in Echtzeit (beim Eintreten des Events), als auch zeitlich verzögert (falls keine Internetverbindung möglich ist) gesendet werden. Verfügbarkeit Einem mobilen Gerät ist es in einigen Situationen nicht möglich intervall- oder eventgesteuerte Daten an den Service abzusetzen. In der Regel tritt dies ein, wenn zum einen keine Netzwerkverbindung verfügbar ist und zum anderen, wenn Sensoren aus verschiedensten Gründen keine Werte liefern können. Eine geeignete Verteilungsarchitektur muss diese Aspekte berücksichtigen und entsprechend reagieren können. Richtung der Kommunikation Es gibt grundsätzlich drei Möglichkeiten, wie Verbindungen zwischen dem mobilen Gerät und dem Service gestaltet werden können. 1. Vom Service ausgehend - Dem mobilen Gerät ist es nicht möglich eine Verbindung zum Dienst selbständig aufzubauen. Er kann nur auf Anfragen des Dienstes antworten. 2. Vom mobilen Gerät ausgehend - Die Entscheidung, wann Daten gesendet werden, wird allein vom Endgerät übernommen. Der Service besitzt nur geringe Eingriffsmöglichkeiten. 3. bidirektionale Verbindung zwischen mobilem Gerät und Dienst - Hier können Service und Gerät direkt miteinander kommunizieren. Dabei wird vorausgesetzt, dass die Geräte jeweils die Identität des Anderen kennen. Im Folgenden werden verschiedene Lösungsansätze vorgestellt, die für die Verteilung von Kontextdaten in Betracht kommen und hinsichtlich der bereits definierten Kriterien beurteilt werden. 36

40 5 Möglichkeiten zur Verteilung von Event- und Kontextdaten auf mobilen Geräten Dienst t=1 t=2 t=3 t=4 t=5 t=6 neuer Event? Nein! Neuer Event? Neuer Event? Ja! + Daten mobiles Gerät Abbildung 5.1: Informationsaustausch via Polling mit Verbindungsunterbrechung 5.2 Polling Beim Polling werden Daten in festen Intervallen abgefragt. Ursprünglich wurde dieses Verfahren vor allem im hardwarenahen Bereich genutzt, wo innerhalb von Sekundenbruchteilen geprüft wird, ob ein bestimmter Zustand eingetreten ist. Im konkreten Szenario fragt der Service zyklisch beim mobilen Gerät an, ob dieses neue Kontextinformationen ermittelt hat. Liegen neue Informationen vor, werden diese entsprechend gesendet. Das führt dazu, dass mehr Anfragen als nötig gesendet werden müssen und somit einen überflüssigen Overhead erzeugen. Zudem ist dieses Verfahren sehr einfach zu implementieren. Durch implizite Annahmen lässt sich der Mehraufwand enorm reduzieren. Erfasst das mobile Gerät Kontextdaten in festen Intervallen, so kann sich der Service an diesen Zeitabständen orientieren und sein Polling darauf einstellen. Das Pollingverfahren kann in diesem Zusammenhang gleichzeitig prüfen, ob das Endgerät überhaupt verfügbar ist. Dadurch entsteht die Möglichkeit, auf eine Verbindungsunterbrechung zu reagieren und das Pollingintervall anzupassen. Ein großer Nachteil dieses Lösungsansatzes ist, dass eventgesteuert ermittelte Kontextdaten ineffektiv verteilt werden, insbesondere, wenn zusätzliche komplexe Bedingungen an den Versand der Daten geknüpft werden. Auch selten eintretende Ereignisse am Gerät sind entweder mit erhöhtem Overhead (kleine Pollingintervalle) oder starken Verzögerungen (lange Pollingintervalle) verbunden. 37

41 5 Möglichkeiten zur Verteilung von Event- und Kontextdaten auf mobilen Geräten Polling benötigt eine minimale Schnittstellendefinition und ist dementsprechend einfach umzusetzen. Zudem gibt es keine weiteren Restriktionen für die konkreten Inhalte, die übermittelt werden sollen, vor. Es findet in diesem Zusammenhang also auch keine Kontrolle der Daten statt, sondern muss manuell erfolgen. 5.3 Socketverbindungen Sockets werden in der Regel für längerfristige bidirektionale Verbindungen verwendet. So stellen beide Kommunikationsteilnehmer sowohl Sender als auch Empfänger dar. Das ermöglicht zum einen einen komplex gearteten Informationsaustausch und zum anderen sowohl eine event-, als auch zeitgesteuerte Kontextdatenübermittlung. Einer der großen Vorteile von Socketverbindungen ist, dass sie anders als beim Polling, im Verlauf der Kommunikation verschiedene Zustände annehmen können. Das ermöglicht einen komplexen Informationsaustausch. Gerade im mobilen Betrieb kann es zu Unterbrechungen der Verbindung kommen. In diesem Fall können die zuvor übermittelten Daten unbrauchbar werden, da der aktuelle Zustand ungültig ist beziehungsweise einige essentielle Informationen zur weiteren Bearbeitung fehlen. Das kann dazu führen, dass ein erhöhter Implementationsaufwand auf beiden Seiten notwendig wird. In Hinblick auf das Datenaufkommen und den Energiebedarf bedeutet eine permanente Verbindung für das mobile Endgerät einen erhöhten Ressourcenverbrauch. Auch ist die Kopplung, trotz Abstraktion der Schnittstellen, enger als beim Polling. Dafür kann eine Verteilung der Daten nahezu in Echtzeit stattfinden und Veränderungen auf der Dienstseite für das mobile Gerät kenntlich gemacht werden. 5.4 Publish-Subscribe Systeme Publish-Subscribe Systeme dienen als einfache Möglichkeit unbekannte Objekte über eine minimale Schnittstelle eventbasiert miteinander zu verknüpfen. Dabei wird zum einen eine Abstraktion erreicht und zum anderen eine lose Kopplung realisiert. 38

42 5 Möglichkeiten zur Verteilung von Event- und Kontextdaten auf mobilen Geräten Publish-Subscribe Systeme bestehen aus zwei Komponenten: 1. Das Subject ist das Objekt oder die Komponente, die beobachtet werden soll. 2. Der Abonnent möchte über die Veränderungen des Subjects informiert werden und meldet sich deshalb bei diesem an. Die lose Kopplung besteht nicht nur zwischen den Komponenten, sondern es wird auch die zeitliche Kopplung gelöst. Da eine Kommunikation im Gegensatz zum Polling oder zur Socketverbindung nur dann notwendig ist, wenn auch wirklich neue Informationen anliegen, ist der Overhead dieser Art des Datenaustausches sehr gering. Da ein Publish-Subscribe System nur beim Eintreten eines Ereignisses den Abonnent informiert ist eine einfache Kopplung an die Events auf dem mobilen Gerät denkbar und sinnvoll. Weiter kann man nach [LiPl03] push-basierte Systeme und pull-basierte Systeme unterscheiden. Push-basierte Architekturen bieten den Vorteil, dass alle Abonnenten zeitnah informiert werden. Gleichzeitig kann es bei einer Vielzahl an Abonnenten zu einem erhöhten Aufwand führen. Auch kann das Interesse des Abonnenten an bestimmten Ereignissen eines Kanals von seinem internen Zustand abhängen. Für diese Fälle sind Pull-basierte Systeme interessant. Sie orientieren sich stärker an den Bedürfnissen der Abonnenten und lassen sie bestimmen, wann sie neue Nachrichten abrufen möchten. Zu berücksichtigen ist hierbei jedoch, dass die Informationen vom Subject länger vorgehalten werden müssen und die Unterschiede zum Polling gering sind. In der Praxis sollte das mobile Gerät entscheiden können, wann Daten gesendet werden, weshalb der push-basierte Ansatz zu bevorzugen ist. Die Anzahl der Abonnenten hält sich bei den meisten Szenarien in Grenzen. So werden vorgehaltene und versendete Daten minimiert. Neben der Unterscheidung von pull- und push-basierten Systemen kann man auch die Art des Abonnements unterscheiden. Neben der klassischen Methode, sich für bestimmte Kanäle anzumelden (subject-based) findet auch die Filterung nach inhaltlichen Aspekten (content-based) eine breite Anwendung. 39

43 5 Möglichkeiten zur Verteilung von Event- und Kontextdaten auf mobilen Geräten Subject-basierte Systeme Subjekt-basierte Systeme konzentrieren sich auf thematische Abonnements. So werden Kanäle, Tags oder Gruppen abonniert. Dabei spielt der Inhalt der konkreten Nachricht keine Rolle, sondern nur deren thematische Einordnung. Dies führt zu einer einfachen Auswertungslogik und einem geringeren Ressourcenverbrauch beim mobilen Gerät. Auch wird die Auswertung der Daten zum Abonnenten ausgelagtert. Negativ ins Gewicht fällt hier jedoch, dass auch Daten gesendet werden, die unter bestimmten Umständen nicht benötigt werden. Gerade bei der begrenzten Netzwerkanbindung mobiler Geräte ist dieser Faktor kritisch. Content-basierte Systeme Inhaltsbasierte Systeme untersuchen die vorliegenden Informationen nach den vom Abonnent vorgegeben Kriterien und versenden die Informationen, falls die Kriterien erfüllt sind. Dabei kann auf die Semantik der Daten zurückgegriffen werden oder es können spezielle Query-Sprachen genutzt werden. Auch einfache Formulierungen in disjunktiver oder konjunktiver Normalform sind hier beliebt. Dieses Vorgehen erfordert zum einen besondere Anforderungen an die Struktur der Informationen und zum anderen ist eine komplexe Auswertung notwendig. Auf der anderen Seite lassen sich Abonnements sehr präzise formulieren und minimieren somit den Overhead versendeter Nachrichten. Auch der Umfang der übermittelten Daten kann so auf ein kleinstmögliches Maß reduziert werden. Hybride Systeme In konkreten Anwendungen findet sich häufig eine Kombination aus subject- und contentbasierten Systemen. So Wird beispielsweise ein bestimmter Kanal abonniert. Zusätzlich werden jedoch Kriterien übermittelt, die bei jeder Veränderung des Kanals spezifisch für jeden Abonnent ausgewertet werden müssen. Die inhaltsbasierte Filterung wird also der subject-basierten Filterung nachgeschaltet. Weitere Aspekte Im bisherigen Verteilungsprozess bestand das Publish-Subscribe System aus zwei Komponenten. Eine weitere Möglichkeit das System zu Abstrahieren und die Kommunikation zu steuern ist 40

44 5 Möglichkeiten zur Verteilung von Event- und Kontextdaten auf mobilen Geräten es, einen Vermittler einzusetzen. Er wird zwischen die beiden Parteien gestellt und verwaltet die Abonnements und die Verteilung der Daten an die Abonnenten. Somit müssen sowohl am Objekt als auch am Abonnent keine Anpassungen vorgenommen werden. Ein weiterer Aspekt ist die Optimierung der Verteilung durch das Sammeln der Daten und gemeinsame Senden in Blöcken. Dies kann genau dann sinnvoll sein, wenn keine sofortige Verteilung notwendig ist. Einem Abonnenten werden die gepackten Daten so nur alle fünf Veränderungen des Kanals oder in einem festen Intervall zugesendet. 41

45 6 Vergleich mobiler plattformunabhängiger Frameworks Innerhalb der letzten Jahre hat sich der Marktverteilung mobiler Betriebssysteme stark verändert. Das liegt zum einen an der zunehmenden Verbreitung von Smartphones, die viele neue Funktionen mit sich bringen und zum anderen daran, dass die Plattformen sich weg von starren unveränderlichen Gerüsten hin zu dynamischen Systemen entwickelt haben. So verhalten sich die Systeme immer mehr wie die ihre Pendants aus der Desktop-Welt: Sie bieten die Möglichkeit Applikationen zu installieren und das OS zu aktualisieren, um es später nach eigenem Wunsch anzupassen. Gleichzeitig drängen weitere Anbieter mit eigenen Lösungen auf den Markt. In Abbildung 6.1 ist die momentane Marktverteilung aufgeschlüsselt. Unabhängig von den Vorteilen für den einzelnen Nutzer, dem eine größere Auswahl an Plattformen zur Verfügung steht, ist es für den Applikationsentwickler zum Teil unmöglich, mit seinen begrenzten Ressourcen alle Plattformen zu versorgen. Eine Lösung für dieses Problem ist die Nutzung von Cross-Plattform-Frameworks, die es ermöglichen ein Programm auf mehreren mobilen Betriebssystemen zu verteilen und zu verkaufen. Darüber hinaus bieten diese Frameworks weitere Vorteile: Die Applikationen wirken auf den verschiedenen Plattformen einheitlich, da derselbe Quellcode zu Grunde liegt Kleine Entwickler können trotz begrenzter Ressourcen eine breite Zeilgruppe ansprechen. Mit den im weiteren Verlauf vorgestellten Frameworks können die Apps über den platt- Abbildung 6.1: Marktanteile mobiler Betriebssysteme nach Gartner

46 6 Vergleich mobiler plattformunabhängiger Frameworks formeigenen Store verkauft werden. Sie setzen zum Teil auf breit zugängliche und bekannte Techniken wie HTML, CSS und Javascript. Im Folgenden werden drei verschiedene Ansätze vorgestellt, die eine plattformübergreifende Applikationsentwicklung ermöglichen. Sie werden anhand vordefinierter Kriterien untersucht, um anschließend beurteilen zu können, inwiefern sie für die Erstellung einer Applikation zur Verteilung von Eventdaten an externe Dienste geeignet sind. 6.1 Kriterien für Cross-Plattform Frameworks Um die Frameworks bewerten zu können werden nun einige Kritierien angeführt, die ein plattformübergreifendes Framework erfüllen muss. Anzahl unterstützter Plattformen Ein solches Framework ist nur dann sinnvoll, wenn ausreichend Zielplattformen unterstützt werden. Wäre eine Implemenation für die gewollten Plattformen nativ schneller umzusetzen und einfacher zu erledigen, würde sich die Nutzung eines solchen Framework nicht lohnen. Lizenz Die Beschränkungen für die Entwicklung einer Applikation, basierend auf dem jeweiligen Framework, müssen weitgehend gering bis nicht vorhanden sein. So sollte eine Nutzung ohne Verpflichtungen für sowohl freie als auch kommerzielle Projekte möglich sein. Zugriffsmöglichkeiten auf die Hardware Die zu untersuchenden Lösungen sollten den Zugriff auf die Hardware möglichst nicht einschränken. Gleichzeitig müssen sie spezifische Eigenheiten der Plattformen berücksichtigt werden, ohne den Einsatz von Weichen im Quellcode notwendig zu machen. Modularität Durch die Kappselung der einzelnen Bestandteile eines Frameworks entstehen weniger Abhängigkeiten. Dadurch kommt es zu weniger Problemen bei der Veränderungen der nativen APIs. 43

47 6 Vergleich mobiler plattformunabhängiger Frameworks Performance Die zusätzliche Abstraktionsschicht und Verwendung nicht-nativer Programmiersprachen kann zu Geschwindigkeitseinbusen führen. Diese Auswirkungen fallen besonders beim Rendern der graphischen Oberfläche oder rechenintensiven Applikationen ins Gewicht. Dokumentation Da Cross-Plattform Frameworks auf fremde APIs aufsetzen, ist es wichtig die Vorgehensweise und Verwendung des Frameworks gut zu dokumentieren. Das erleichtert zum einen Fehler bei der Verwendung der Framework API und zum anderen sind Bugs leichter verifizierbar, da das gewollte Verhalten genau aufgezeichnet wurde und so mit dem Ist-Zustand abgeglichen werden kann. Workflow Dieser Aspekt beschäftigt sich mit dem Entwicklungsprozess und den Mitteln, die dem Entwickler durch das Framework zur Verfügung gestellt werden. So wird bei einigen Frameworks eine Entwicklungsumgebung für den Benutzer bereitgestellt, die genutzt werden kann oder muss. Auch ist es für den Entwickler wichtig, wie komplex sich die Implementation und Verwaltung des Projektes gestaltet. 6.2 Phonegap Mit Phonegap erstellte Applikationen laufen in einem Webcontainer innerhalb einer nativen Applikation. Im Webcontainer können alle bekannten Webechniken wie HTML, CSS und Javascript genutzt werden. Um auf gerätspezifische Funktionen zugreifen zu können, wird eine Schnittstelle bereitgestellt, die via Javascript erreichbar ist. Aus Abbildung 6.2 lässt sich entnehmen, dass dieses Framework stark modular aufgebaut ist und sich über eine Plugin-API erweitern lässt. Dafür wird jeweils eine native Schnittstelle und das passende Gegenstück in Javascript-Code benötigt. Für die Schnittstellenbeschreibungen setzt Phonegap auf die vom W3C festgelegten Standards für den Zugriff auf Geräte-Funktionen [API11]. In der Wahl der Entwicklungsumgebung macht Phonegap keine Einschränkungen. Hier müssen lediglich die SDKs der verschiedenen Plattformen 44

48 6 Vergleich mobiler plattformunabhängiger Frameworks Webview <div data-role="content"> <h3>settings</h3> <p>${service.description}</p><br /> <div data-role="fieldcontain"> <label for="slider">active</label> <select id="slider" data-role="slider"> <option value="off">off</option> Javascript Schnittstellen Geolocation Compass Plugin Geolocation Compass Plugin native Schnittstellen Nativer Applikationscode nativ cross-plattform Abbildung 6.2: Aufbau einer Phonegap-Applikation zum Erstellen der Applikationspakete zur Verfügung stehen. Durch den minimalistischen Ansatz sind nur geringe Abhängkeiten zu anderen Techniken gegeben, so dass der Entwickler hier nicht weiter eingeschränkt wird. Phonegap bietet die breiteste Plattformunterstützung der drei vorgestellten Frameworks an. Details hierzu lassen sich aus Abbildung 6.3 entnehmen. Da Phonegap-Applikationen mit Webtechniken implementiert werden, können Entwickler auf bestehende webbasierte Lösungen zurückgreifen und auch direkt für mobile Geräte und Touchbedienung ausgelegte Frameworks nutzen. 6.3 Rhomobile Mit Rhomobile ist es möglich, mobile Anwendungen basierend auf Ruby, Javascript und HTML und CSS zu erstellen. Dabei ist das Framework nach dem Model-View-Controller Pattern ge- 45

49 6 Vergleich mobiler plattformunabhängiger Frameworks Abbildung 6.3: Überblick über die Funktionen von Phonegap, Stand Juli 2011 [PHO11] staltet, wobei Model und Controller in Ruby und der View mit Hilfe von Javascript, HTML und CSS realisiert wird. Das Ruby-Backend fungiert hierbei als Server-Umgebung. Der View wird über den nativen Container der jeweiligen Plattform umgesetzt und ermöglicht in dieser Form keinen Zugriff auf Systemfunktionalitäten des mobilen Gerätes. Diese werden erst durch ein System-Objekt vom Ruby-Backend der Javascript-Umgebung zur Verfügung gestellt. Als Lizenz wird die MIT Licence angegeben. Rhomobile bietet somit gute Möglichkeiten der Weiterverwendung für quellcodeoffene und geschlossene Projekte. Darüber hinaus werden viele Plattformen unterstützt. Zu nennen sind hier ios, Android, Windows Mobile und Blackberry. Nachteil der Verwendung von Ruby ist, dass ein Ruby Interpreter mitgeladen werden muss und somit die Applikation unnötig aufbläht. Lässt sich der Ruby Interpreter auf eine bestimmte Plattform nicht portieren, kann die Anwendung dort nicht lauffähig umgesetzt werden. Zudem gestaltet sich die Einrichtung und Entwicklung von Projekten in der Praxis als relativ komplex. So muss der Entwickler, bevor er mit der Implementation seiner Anwendung beginnen kann, einige Tools und SDKs einbinden. Unter anderem Ruby, RubyGems, GNU-Tools, Rhodes 46

50 6 Vergleich mobiler plattformunabhängiger Frameworks gem, die mobilen SDKs und die Konfigurations-Rhodes sind beispielsweise notwendig. Das kann während der Entwicklung oder bei Aktualisierung der eingebundenen Bibliotheken zu Kompatibilitätsproblemen führen und die weitere Entwicklung der Applikation blockieren. Die einheitliche Unterstützung sensorbezogener Systemfunktionalitäten ist bei diesem Framework positiv hervorzuheben. Durch diese umfasssende Unterstützung werden Weichen für spezielle Plattformen vermieden und die Sensoren können so einfacher genutzt werden. Es fällt aber auch auf, dass einige Sensoren, wie zum Beispiel der Accelerometer, nicht unterstützt werden beziehungsweise durch Erweiterungen nachträglich eingebunden werden müssen. Zwar sieht Rhomobile Plugins vor, jedoch bedeutet dies für den Entwickler zusätzlichen Aufwand bei jeder einzelnen Plattform auf die er seine Anwendung portieren möchte. Die Dokumenation ist beispielhaft gehalten, was zu schnellen Erfolgserlebnissen bei der Implementierung führt. Jedoch ist sie wenig einheitlich und bei speziellen Problemen fehlt es an Genauigkeit. 6.4 Titanium Mobile Titanium Mobile steht unter der Apache Open Source Lizenz und generiert aus Javascript zum Teil nativen Code für die ios- und Androidplattform. Die eigentliche Applikation wird durch den Entwickler in Javascript implementiert. Jedoch wird die grafische Oberfläche nicht über einen Webcontainer umgesetzt, sondern zur Laufzeit über nativen Objective-C Code beziehungsweise Java-Code gerendert. Dies wird über eine Brücke in den Javascriptkonstruktoren erreicht, die intern native Funktionen aufrufen. Das führt vor allem zu einer höheren Ausführungsgeschwindigkeit der Applikation und einem nativen Bedienungsgefühl. Da für das Rendern der grafischen Oberfläche native Elemente verwendet werden und somit ein Webview nicht benötigt wird, verzichtet Titanium Mobile gänzlich auf diesen. Stattdessen wird ein eigener webkitbasierter Javascript-Interpreter mitgeladen, der die Javascript-Dateien auswertet. 47

51 6 Vergleich mobiler plattformunabhängiger Frameworks erzeugt via erb Model + Controller View Ruby JS + HTML + CSS Ruby Interpreter + Web Server + Browser Control Sencha Touch jquery jquery Mobile XUI... Rhom Rhosync-Server Abbildung 6.4: Aufbau einer Rhomobile-Applikation Titanium unterstützt die Positionsermittlung, die native Karten-API, Beschleunigungssensoren, den Audiorecorder und die Kamera. Weiter wird eine komplette Entwicklungsumgebung zur Verfügung gestellt, die auf der Aptana IDE basiert und sich automatisch um Aktualisierungen kümmert und eine einheitliche, gut geführte Entwicklung ermöglicht. Damit wird die Einstiegshürde niedrig angesetzt. Bei der Erstellung einer Applikation behält der Entwickler die Möglichkeit über Weichen Zugriff auf spezielle Systemfunktionalitäten der verschiedenen Plattformen zu bekommen. In der API werden diese Funktionen über Titanium.Android beziehungsweise Titanium.App.iOS zur Verfügung gestellt. Darüber hinaus steht als Entwicklungsumgebung eine eclipsebasierte IDE zur Verfügung, die den Entwickler bei der Implementation und beim Deployment unterstützt. Da Titanium Mobile nur die ios- und Androidplattform unterstützt, ist die Bezeichnung als Cross-Platform-Framework optimistisch gewählt, jedoch wird trotzdessen ein großer Teil des 48

52 6 Vergleich mobiler plattformunabhängiger Frameworks Abbildung 6.5: Erstellen grafischer Elemente mit Titanium Mobile in Javascript Phonegap Rhomobile Titanium Mobile Plattformen Performance + o ++ Hardwarezugriff Modularität Lizenz Dokumentation ++ o ++ Workflow o + + Tabelle 6.1: Bewertung der Cross-Plattform-Frameworks Smartphonemarktes erreicht. Für eine möglichst starke Verbreitung der Applikation ist das Framework aber nicht geeignet. 6.5 Zusammenfassung Wenn man sich nicht nur auf die Entwicklung für Android und ios beschränken möchte, so bietet Phonegap die vielseitigsten Möglichkeiten. Durch die stark ausgeprägte Modularität und die extrem breite Unterstützung an Plattformen ist es besonders geeignet für Entwickler, die über geringe Ressourcen verfügen. Rhomobile bietet zwar ein festes Gerüst zur Entwicklung, zeigt jedoch besonders Schwächen bei der Modularität und gibt zu enge Vorgaben bei der Entwicklung. So lassen sich eigene Lösungen nur über die von Rhomobile vorgegebenen Wege einbinden. Die Tabelle 6.1 gibt eine Übersicht über die Bewertung der einzelnen Frameworks nach den zuvor festgelegten Kriterien. Möchte man sich auf die zwei großen Plattfomen beschränken bietet Titanium Mobile ein sehr gutes Paket an, bei dem nur wenige Kompromisse gemacht werden. Es ist abzuwägen, ob eine native Entwicklung für beide Plattformen im Endeffekt günstiger wäre. 49

53 7 Konzept für ein mobiles Verteilungssystem von Eventdaten Nachdem in den vorherigen Kapiteln verschiedene Lösungen für die Verwendung, Behandlung und Verteilung von Event- beziehungsweise Kontextdaten vorgestellt und auch Frameworks beschrieben wurden, mit denen man den Sensorzugriff auf möglichst vielen Plattformen realisieren kann, werden diese Erkenntnisse nun zusammengeführt um ein Konzept für die Gewinnung, Behandlung und Verteilung von Eventdaten auf mobilen Geräten zu erstellen. So wird im Folgenden erläutert, wie Events und Services in diesem Konzept zu verstehen sind und welche Aufgaben, Möglichkeiten, aber auch Einschränkungen sie haben. Weiter wird der Mechanismus zur Verteilung der aggregierten Daten skizziert, um letztendlich eine Implementation basierend auf diesem Konzept durchzuführen. Weiter findet eine Bewertung der vorgestellten Lösungen in Hinblick auf die vier Grundanforderungen statt: 1. Registrierung von Diensten und Events. 2. Sammeln von Sensor- und Eventdaten (Kontextdaten) und Abstraktion dieser. 3. Kontrollmöglichkeiten der (zu übermittelnden) Kontextdaten durch den Nutzer. 4. Evengesteuerte Verteilung der gesammelten Daten aufgrund inhaltlicher Kriterien an externe Dienste. Diese Funktionalitäten sollten durch die gewählten Frameworks und Architekturen bestmöglich umgesetzt werden. Dabei ist aber auch auf eine praktische Realisierbarkeit zu achten und eine Verträglichkeit der Lösungen für die spezifischen Probleme. 7.1 Events - Möglichkeiten und Anforderungen Events auf mobilen Geräten sind Ereignisse, die zum einen durch Sensoren und zum anderen durch bestimmte Geschehnisse hervorgerufen werden. Sie besitzen dabei eine konkrete oder implizite Informationen. Hierbei handelt es sich um eine Kontextinformation, die Aufschluss über die Identität oder die Umgebung des Nutzers beziehungsweise des mobilen Gerätes gibt. Ein Event ist also immer mit einer Kontextinformation beim Eintreten des Ereignisses verbunden. 50

54 7 Konzept für ein mobiles Verteilungssystem von Eventdaten Weiter kann sich ein Event wiederholen. Dabei wird immer eine neue Kontextinformation gewonnen. Jede Kontextinformation ist an einen Moment gebunden und wird deshalb mit einem Zeitstempel versehen. Außerdem müssen sich Kontextdaten kombinieren lassen. Dies kann über zwei Wege geschehen: 1. Die Daten werden gebündelt, um ihre Zugehörigkeit zu zeigen. Dies kann durch einen gemeinsamen Zeitstempel oder eine gemeinsame Eigenschaft geschehen. 2. Ein Event abstrahiert einen Anderen oder ist von diesem abhängig. So nutzt ein Event die Kontextinformationen, die von einem anderen Event gewonnen wurde und manipuliert sie mit Hilfe von zusätzlichen Informationen. Typische Beispiele sind die Transformationen von Positionsdatenmodellen, die in Abschnitt 2.2 erläutert wurden. Das heißt in der Schlussfolgerung, dass ein Transformator in diesem Konzept durch einen Event nachgebildet werden kann. Dadurch, dass der Event seine Kontextinformationen mit Hilfe der Daten eines anderen Events generiert ist eine Abhängigkeitsprüfung notwendig. So muss sich ein Event darauf verlassen können, dass die benötigten Informationen auch vorliegen. Dies kann durch einen Registrierungsprozess sichergestellt werden, bei dem Abhängigkeiten zu anderen Events geprüft werden. Diese Abhängigkeiten müssen explizit angegeben werden. Können diese Events nicht erfüllt werden, so kann auch der Event nicht registriert werden. 7.2 Services - Möglichkeiten und Anforderungen Dienste sind Empfänger der Kontextdaten von Events. Sie können mehrere Events anfordern und diese miteinander kombinieren. Hierbei werden zwei Aspekte beachtet: 1. Dienste haben eine Bedingung (auch Trigger genannt), die festlegt, wann die Eventdaten gesendet werden sollen. Dies kann zeitgesteuert oder durch das Eintreten von Ereignissen geschehen. 2. Die Zusammenstellung der Kontextdaten, die zum Service gesendet werden ist entscheidend. Mehrere Eventdaten können gebündelt werden und unwichtige Bestandteile werden ausgespart. 51

55 7 Konzept für ein mobiles Verteilungssystem von Eventdaten Es ist nun genauer zu spezifizieren, was eine Bedingung zum Senden der Eventdaten überhaupt ist. Eine Bedingung besteht aus Einzelkriterien, die nach dem Schema der disjunktiven Normalform miteinander verknüpft sind. Ein Einzelkriterium ist dabei eine Frage, die dem spezifierten Event gestellt und mit wahr oder falsch beantwortet wird. So hängt die Erfüllung der kompletten Bedingung von den Ergebnissen der Einzelkriterien und deren logischer Verknüpfung miteinander ab. Nun geht ein Service davon aus, dass die geforderten Events vorhanden sind. Das Vorhandensein wird, wie bei den Events auch, durch einen Registrierungsprozess sichergestellt. Sind die vom Service benötigten Events nicht vorhanden, kann er nicht registriert werden. 7.3 Verteilung der Event- und Kontextdaten Zur Verteilung der Daten über ein mobiles Gerät ist ein hybrides Publish-Subscribe System ideal geeignet. Dabei können bestimmte Events durch den Service ausgewählt werden (subjectbasiert), wobei inhaltliche Bedingungen an sie gestellt werden (content-based). Damit ist eine möglichst flexible Auswahl der benötigten Daten möglich und zusätzlich wird der Umfang der zu versendenden Daten minimiert. Die Kommunikation mit den Diensten geht immer von Eda aus. Das heißt, es handelt sich hier um die Pushvariante des Publish-Subscribe Systems. Eine Verbindungsmöglichkeit durch den Service würde von dem mobilen Gerät eine offene Leitung erfordern, was zu einer Verkürzung der Akkuleistung führen würde. Zudem wäre eine komplexe Logik für die Behandlung von Verbindungsabbrüchen, die im mobilen Umfeld nicht unüblich sind, notwendig. Ein anderer Aspekt ist, dass die Kontrolle darüber, wann Daten gesendet werden nicht mehr direkt beim Nutzer beziehungsweise bei der Applikation liegen würden. 7.4 Architektur Als Architektur bietet sich ein leicht modifiziertes Blackboard-Schema an. Die Anpassungen sind durch die spezielle Aufgabe der Ermittlung und Verteilung von Eventdaten bedingt, aber auch durch den Fakt, dass das Konzept sich in den ressourcenkritischen Bereichen vom klassischen 52

56 7 Konzept für ein mobiles Verteilungssystem von Eventdaten Blackboard-Ansatz unterscheidet. So werden die Events direkt auf dem Gerät produziert und nicht von einer externen Quelle über das Netzwerk bezogen. Zudem wird die Kommunikation nur vom mobilen Gerät zum jeweiligen Service initiiert. Eine beidseitige Verbindung wird nicht benötigt. Die Blackboard-Architektur hat gegenüber dem widgetbasierten Ansatz den Vorteil, dass die einzelnen Komponenten sehr lose gekoppelt sind. Zwar bietet auch der netzwerkbasierte Ansatz diese Eigenschaft, ist aber zu dezentral gehalten, was einen höheren Netzwerktraffic verursachen würde und sich so direkt auf die Performance auswirken würde. 53

57 8 Implementation eines Prototypen: Event Distributor App (Eda) Abbildung 8.1: Bildschirmaufnahme der Eda-Applikation Um die praktische Umsetzbarkeit zu zeigen, wurde das Konzept aus dem vorherigen Kapitel als Prototyp umgesetzt. Die Event Distributor App, kurz Eda, ist eine modular aufgebaute Applikation, die der Konzeption entsprechend eine leicht modifizierte blackboardbasierte Architektur darstellt und die gewonnenen Eventdaten via Publish-Subscribe-Verfahren an die externen Dienste verteilt. Über das Konzept hinaus ergeben sich bei der Implemenation neue Aspekte, die zu berücksichtigen sind, die es in diesem Kapitel zu erläutern gilt. 8.1 Verwendete Frameworks und Bibliotheken Phonegap dient als Container für die Entwicklung von Eda. Gegenüber den alternativen Lösungen Titanium Mobile und Rhomobile hat es geringe Abhängigkeiten, berücksichtigt die W3C- Standards und lässt sich für spezielle Einsatzgebiete leicht erweitern. Auch die Nutzungsmöglichkeiten von bestehenden Webtechniken und Javascript-Frameworks sprechen für dieses Framework. Die eigentliche Applikation wird somit in HTML, Javascript und CSS umgesetzt. Auf- 54

58 8 Implementation eines Prototypen: Event Distributor App (Eda) Event 1 Event 2 Event 3 Event 4 registriert Service 1 Service 2 Service 3 ServiceHandler benachrichtigt registriert ruft auf benachrichtigt EventHandler ruft auf benachrichtigt EDA (Schaltzentrale) sendet logs LogHandler ruft auf benachrichtigt Direktaufrufe Indirekte Aufrufe (Benachrichtigungen) Kernbestandteile uihandler Externe Bestandteile Abbildung 8.2: Aufbau von Eda bauend auf diesen Techniken existieren eine Vielzahl von ausgereiften Lösungen, die in der Entwicklung Anwendung finden können. Eda im Konkreten nutzt vier Javascript-Erweiterungen: 1. jquery - jquery bietet erweiterte Möglichkeiten für die DOM-Manipulation und die Selektion einzelner HTML-Elemente. Darüber hinaus werden Unterschiede in den Implementationen der Javascript-Engine verschiedener Browser abstrahiert und einheitlich zugänglich gemacht. Weiterhin bietet jquery eine Vielzahl an Erweiterungen, die sich mit geringem Aufwand integrieren lassen [JQU11a]. 2. jquery Mobile - Das Bereitstellen einer grafischen Oberfläche, die zum einen auf mobile Geräte und zum anderen auf Touchbedienung ausgelegt ist, stellt einen erheblichen Aufwand dar. Hier bietet jquery Mobile eine Lösung an, die sich auf diese beiden Kernaufgaben konzentriert. Dabei setzt es jquery voraus und erlaubt gleichzeitig die Manipulation der UI via DOM [jqu11d] 3. jquery Template - Um die grafische Darstellung von der Programmlogik zu trennen werden in Eda Templates genutzt. Mit jquery Template ist es möglich über Objekte und Arrays zu iterieren und bedingte Ausgaben zu erzeugen. Auch die Wiederverwendbarkeit einer templategestützten Architektur spricht für diese Lösung. jquery Template ist ebenfalls 55

59 8 Implementation eines Prototypen: Event Distributor App (Eda) auslösen #eda benachrichtigen benachrichtigen benachrichtigen benachrichtigen Abbildung 8.3: Mögliche Benachrichtigungswege in Eda von jquery abhängig [JQU11c] 4. jstorage - Um Einstellungen und Zustände auch über die Programmtermination zu Speichern bietet jstorage eine HTML5-basierte Lösung an, die JSON-Objekte beliebiger Struktur speichern kann. Dabei funktioniert sie plattformunabhängig und lässt sich mit geringem Aufwand integrieren [JST11]. Der Entwickler einer Applikation, die auf Eda basiert, kann auf die vorhandenen Bibliotheken zurückgreifen, selbstgewählte nutzen oder einfaches Javascript und HTML verwenden. Er muss lediglich das Benachrichtigungssystem von Eda nutzen, welches im Folgenden erklärt wird. 8.2 Benachrichtigungen Eda verwendet neben direkten Funktionsaufrufen auch Benachrichtigungen, um die Kommunikation zwischen den einzelnen Komponenten wie Handlern und Events zu abstrahieren. Das Benachrichtigungssystem basiert auf der jquery-eigenen Event-API [JQU11b], bei der bestimmte selbst festgelegte Ports überwacht werden können und beim Auslösen alle dafür angemeldeten Listener benachrichtigt werden. Für die Zuweisung der Aktionen ist in diesem Prototypen die Eda-Instanz zuständig. So registriert sie die Ports und bietet gleichzeitig entsprechende Handler für den Fall, dass ein spezielles Ereignis eintritt. Benachrichtungen sind eine sehr gute Möglichkeit asynchrone Kommunikation zwischen einzelnen Bestandteilen der Applikation zu erreichen. Weiter tragen sie zur Entkopplung der Komponenten bei. Mehrere Komponenten können ein und dieselbe Nachricht absetzen und beliebig viele von ihnen sind dazu in der Lage auf diese lauschen. Ein Beispielszenario für die Benachrichtigungswege ist der Abbildung 8.3 zu entnehmen. In Eda 56

60 8 Implementation eines Prototypen: Event Distributor App (Eda) werden vier Ereignistypen unterschieden: 1. Eventbezogen - Hier sind alle Benachrichtungen enthalten, die bei der Behandlung und Verwaltung von Eventdaten auftreten. So wird zum Beispiel eine Benachrichtigung abgesetzt, wenn die Registrierung fehl schlug oder neue Kontextdaten durch einen Event generiert wurden. 2. Servicebezogen - Dieser Typ von Ereignissen betrifft vorallem Vorgänge, die bei der Verarbeitung von externen Diensten ablaufen. So wird Beispielsweise eine Benachrichtigung erstellt, wenn die Daten erfolgreich an den Service gesendet wurden. 3. UIbezogen - Um die grafische Oberfläche zu veranlassen bestimmte Komponenten neu zu zeichnen, werden Ereignis-Callbacks genutzt. Weiter werden diese Benachrichtigungen auch dazu genutzt, Nutzerinteraktionen an Eda weiterzurreichen. So führt das deaktivieren eines Toggle-Schalters dazu, dass ein Service deaktiviert wird - je nachdem, wie Eda diese Benachrichtigung interpretiert. 4. Logbezogen - Hier wird der LogHandler dazu animiert, eine neue Lognachricht zu speichern Die Benachrichtigungstypen werden über eine Namenskonvention unterschieden. So beginnen die Kanäle für eventbezogene Nachrichten mit event_ und servicebezogene Nachrichten mit service_. 8.3 Speichern von Daten Die jstorage-bibliothek wird durch Eda genutzt, um die dynamisch nachgeladenen Servicedaten und ermittelte Eventdaten permanent zu speichern. Es können Listen oder Objekte im JSON- Format über einen einfachen Befehl gespeichert und geladen werden. Das Speichern von Eventdaten übernimmt momentan jeder Event für sich. In der weiteren Entwicklung ist eine Ausgliederung dieser Funktionalität an den EventHandler beziehungsweise einen StorageHandler geplant. Somit soll eine Ersetzbarkeit der jstorage-bibliothek erreicht werden. 8.4 Registrierungsprozess Bevor sie von der Applikation genutzt werden können, müssen Events und Services registriert werden. Um eine erfolgreiche Registrierung zu gewährleisten, müssen zwei Kriterien erfüllt sein: 1. Der Event/Service darf noch nicht registriert sein. Hierbei wird die ID mit den bereits 57

61 8 Implementation eines Prototypen: Event Distributor App (Eda) registrierten IDs abgeglichen. 2. Die Abhängigkeiten des zu registrierenden Events/Services müssen alle erfüllt sein. Die Abhängigkeiten werden als Liste angegeben und besitzen jeweils die ID des Events und optional eine minimale und maximale Version des benötigten Events. Somit ist sichergestellt, dass die Events beziehungsweise Services schnittstellengerecht arbeiten können und sich das Verhalten den Erwartungen entspricht. 8.5 Komponenten von Eda Nachdem Abbildung 8.2 einen Überblick über den Aufbau von Eda gegeben hat und die grundsätzliche Kommunikation zwischen den Komponenten geklärt ist, wird im Folgenden die Funktionsweise der einzelnen Bestandteile erläutert Events und EventHandler Events werden über Javascript-Dateien eingebunden und über den EventHandler nach dem bereits erläuterten Verfahren registriert. Neben einer Identifikation, einem Namen, der Version und den Abhängigkeiten gibt es auch spezielle Schnittstellen, die durch den Event implementiert werden müssen. Hier zu nennen sind beispielsweise eine Start- und Stopfunktion, eine Verbalisierungs- und Prüfungsfunktion für die Trigger der Services und einige weitere Funktionen zur Ermittlung der Werte. Genaue Implementationsdetails lassen sich den zum Quelltext beigelegten Beschreibungsdateien entnehmen. Der einzelne Event hat neben der schnittstellengerechten Umsetzung auch die Aufgabe, Eda über Veränderungen zu benachrichtigen. So werden Fehler in der Durchführung oder die Ermittlung einer neuen Eventinformation über das Benachrichtigungssystem weitergeleitet. Der EventHandler dient der Verwaltungung und Abstraktion der einzelnen Events. So bietet er Zugriffsmöglichkeiten auf alle Events an, um beispielsweise über diese zu iterieren oder bestimmte Events anhand ihrer ID zu ermitteln. 58

62 8 Implementation eines Prototypen: Event Distributor App (Eda) Services und ServiceHandler Externe Dienste können im Gegensatz zu den Events zusätzlich zur Laufzeit über eine externe URL geladen werden. Die Abfrage wird via Ajax realisiert und der Server liefert Daten im JSON-Format an Eda aus. Aus Sicherheitsgründen wird kein ausführbares Javascript übertragen, sondern nur beschreibende Daten. Der ServiceHandler übernimmt die Interpretation dieser Daten und verwaltetet die registrierten Services. Wurde der Dienst einmal registriert, ist er auch nach einem Neustart der Applikation weiter verfügbar und muss nicht neu geladen werden. Die Servicebeschreibung liegt im JSON-Format vor und enthält allgemeine Informationen wie die Service-ID, Beschreibung und URL, an die die Daten gesendet werden sollen. Außerdem beinhaltet die Beschreibung drei wichtige Bestandteile, welche die Verteilung der Events an den Service betreffen: Event-Abhängigkeiten - Hier werden die Events aufgezählt, die benötigt werden und aktiv sein müssen, damit der Dienst mit Daten beliefert werden kann. Ist einer der geforderten Events nicht auf dem Gerät vorhanden, schlägt die Registrierung des Services fehl. Erforderliche Daten - Unter diesem Aspekt werden die von Events ermittelten Daten zusammengefasst, die an den Service gesendet werden sollen. So kann sich jeder Service auf die Daten beschränken, die er wirklich benötigt. Die Trigger-Bedingung - Anforderung, die bei Erfüllung dazu führt, dass der Dienst bedient wird. Eine genaue Beschreibung wird unter dem Punkt Trigger in diesem Kapitel erläutert. Hierbei gilt, dass die Events, die in den Triggern und erforderlichen Daten enthalten sind, auch in den Event-Abhängigkeiten aufgezählt werden müssen. Weiter ist zu beachten, dass nur direkte Abhängigkeiten angegeben werden müssen. Wird beispielsweise ein Event A vorausgesetzt, der wiederum einen Event B benötigt, so muss der Dienst, der Event A nutzen möchte nur Event A als Abhängigkeit angeben. Trigger Wurde ein Service durch den ServiceHandler aktiviert, so können Daten an ihn gesendet werden. Um an dieser Stelle das zu häufige Senden von Daten zu vermeiden kann ein Dienst angeben un- 59

63 8 Implementation eines Prototypen: Event Distributor App (Eda) [ ] [ Kriterium1, Kriterium2, Kriterium3], [ Kriterium4, Kriterium5] == (Kriterium1 AND Kriterium2 AND Kriterium3) OR (Kriterium4 AND Kriterium5) Abbildung 8.4: Repräsentation des Triggers in disjunktiven Normalform durch Eda ter welchen Bedingungen die benötigten Eventdaten gesendet werden sollen. Dabei ist es möglich Einzelkriterien logisch miteinander zu verknüpfen, um so eine komplexe Bedingung zu formulieren. Darüber, ob ein Einzelkritierium erfüllt ist entscheidet der adressierte Event selbst. Eigens für diesen Zweck stellt er eine Funktion zur Verfügung, an die der ServiceHandler das Einzelkriterium zur Auswertung übergeben kann. Abbildung 8.4 veranschaulicht die logische Verknüpfung von Einzelkriterien und deren Repräsentation als Ausdruck. Zum Verständnis wird nun ein Beispiel eines Einzelkriteriums beschrieben: { id : Geolocation, criteria : bbox, ul : { lat : 54.12, lon : 18.7} br : { lat : 42.18, lon : 15.7 } triggerevent : true } An den Event mit der Identifikation Geolocation wird eine Anfrage gestellt. Durch das Kriterium bbox wird eine Prüfung vollzogen, ob der letzte ermittelte Wert in der Boundingbox liegt, die durch ul und br begrenzt wird. Wichtig zu beachten ist außerdem das Attribut triggerevent. Durch dieses Attribut wird zusätzlich geprüft, ob dieser Event auch zu der Prüfung des Triggers geführt hat. Ohne dieses Attribut kann jeder beliebige Event dazu führen, dass der Trigger ausgelöst wird. Übertragung erforderlicher Daten Wenn die Trigger-Bedingung eines Dienstes erfüllt ist, müssen die erforderlichen Eventdaten gesammelt werden. Auch hierfür bietet der jeweilig geforderte Event eine Schnittstelle, um die gewollten Daten abzufragen. Ein direktes Zugreifen auf die Daten ist somit nicht möglich und ungültige beziehungsweise unerlaubte Zugriffe werden vermieden, vergleichbar mit einer rudimentären Datenbankquery. Die einzelnen Datensätze werden anschließend zusammengefügt und als Nachricht an die vom Service angegebene Adresse gesendet. Ein Beispiel für einen solchen Datensatz lässt sich aus Abbildung 8.5 entnehmen. Implizit wird vorrausgesetzt, dass die erforderlichen Daten vorhanden sind. Ist dies nicht der Fall, wird die Routine abgebrochen und es 60

64 8 Implementation eines Prototypen: Event Distributor App (Eda) Abbildung 8.5: Beispiel von an einen Dienst gesendeten Eventdaten werden keine Daten gesendet. Dies gilt es besonders beim Erstellen der Trigger zu beachten uihandler Der UIHandler beinhaltet Routinen, die für die Darstellung der grafischen Oberfläche zuständig sind. Dabei ist er für das Rendern der Templates zuständig und benachrichtigt die Eda- Komponente über Veränderungen der UI, soweit diese eine Reaktion eines Handlers erfordern. Eda setzt hier auf jquery Mobile, welches ebenfalls auf die jquery Event-API setzt und somit gut in den Prototypen integriert ist LogHandler Der LogHandler ermöglicht es interne Vorgänge der Applikation für den Nutzer nachvollziehbar zu machen. Neben den vordefinierten Typen wie info, warning, error oder debug können Events oder auf Eda aufbauende Apps eigene Logtypen registrieren, was auch zur Laufzeit möglich ist. Die einzelnen Typen lassen sich aktivieren beziehungsweise deaktivieren, mit der Folge, dass diese in der Übersicht unsichtbar sind. Bei neu hinzugekommenen Logs wird Eda benachrichtigt, so dass beispielsweise die grafische Oberfläche aktualisiert werden kann. Der Einsatz von Templates trennt zudem die Programmierlogik von der Darstellungslogik, was dazu führt, dass sich die bestehende UI leicht anpassen und auch ersetzen lässt. 8.6 Beispielszenario Nachdem nun die Vorgehensweise von Eda in den jeweiligen Komponenten erläutert wurde wird das Verhalten im Ganzen betrachtet. Abbildung 8.6 zeigt hierfür beispielhaft den Ablauf vom 61