Technische Universität Dresden

Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze

Diplomarbeit:

Ein Framework zur Entwicklung mobiler Social auf Basis von Android

vorgelegt am 15.03.2011 von Robert Lübke Geboren am 28.09.1985 in Schwedt / Oder [email protected] Matrikelnummer: 3296098

Betreuer: Dr.-Ing. Daniel Schuster [email protected]

verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill

Abstract

Abstract Aktuelle mobile soziale Anwendungen wie Facebook Places, Foursquare und Gowalla fördern das Zusammenwachsen der Welten des Social Networking und des Pervasive Computing, woraus der Trend des Pervasive Social Computing entsteht. In dieser Arbeit soll zu Beginn ein Überblick über kommerzielle Mobile Social Software und Forschungsarbeiten aus diesem Bereich gegeben werden. In dieser Analyse wird deutlich, dass viele Anwendungen ähnliche Features aufweisen, die jedes Mal von Grund auf neu entwickelt werden müssen. Daher soll in dieser Arbeit ein Framework zur umfassenden Unterstützung der Entwicklung von Mobile Social Software konzipiert und implementiert werden. Dies beinhaltet sowohl ein clientseitiges Framework für die Android-Plattform als auch generisch nutzbare, serverseitige Dienste. Abschließend wird mithilfe von Umfragen und eines Feldtests der Nutzen des Frameworks evaluiert.

i Aufgabenstellung

Aufgabenstellung

ii Danksagung

Danksagung Ich danke zuallererst dem Betreuer dieser Diplomarbeit, Daniel Schuster, für die Unterstützung, die ich erfahren habe. Ich habe von ihm stets hilfreiches Feedback und wertvolle Hinweise erhalten – sogar während seiner Elternzeit. Mein Dank gilt außerdem allen Studierenden und Mitarbeitern, die in der Vergangenheit zum Mobilis-Projekt beigetragen haben. Ohne die Vorarbeit dieser Personen hätte das Mobilis-Framework zum Abschluss dieser Arbeit nicht einen solch großen Funktionsumfang vorweisen können. Bei Danny Kiefner und István Koren habe ich oft Unterstützung bei verschiedenen Fragestellungen bezüglich des Frameworks und meiner Diplomarbeit erhalten. Außerdem danke ich Christopher Scholz und Thomas Springer für das wertvolle Feedback zum erstellten Fragebogen und zur durchgeführten Umfrage. Ich danke weiterhin den vielen Kommilitonen für die Unterstützung während meines Studiums. Insbesondere möchte ich mich bei Daniel Esser für die Hilfe bei den Prüfungsvorbereitungen bedanken. Abschließend danke ich meiner Familie für die Unterstützung während der 4½ Jahre meines Studiums. Meine Frau Christin hat mir liebe- und rücksichtsvoll über die gelegentlich auftretenden Tiefpunkte meines Studiums hinweggeholfen. Außerdem danke ich Christin dafür, dass sie mir geholfen hat, diese Arbeit mit mehr Kommas, besserem Ausdruck und weniger Rechtschreibfehlern auszustatten.

iii Inhaltsverzeichnis

Inhaltsverzeichnis Abstract ...... i Aufgabenstellung ...... ii Danksagung ...... iii Inhaltsverzeichnis ...... iv 1 Einleitung...... 1 2 Mobile Social Software und Frameworks ...... 4 2.1 Mobile Social Software ...... 4 2.2 Frameworks...... 9 2.3 Fazit ...... 14 3 Anforderungsanalyse ...... 16 3.1.1 Funktionale Anforderungen ...... 16 3.1.2 Geräteanforderungen ...... 18 3.1.3 Nichtfunktionale Anforderungen ...... 19 4 Dienstumgebungen ...... 21 4.1 Extensible Messaging and Presence Protocol ...... 21 4.1.1 Message ...... 21 4.1.2 Presence ...... 22 4.1.3 Info / Query ...... 22 4.1.4 Erweiterbarkeit ...... 22 4.2 Webservices ...... 26 4.3 Fazit ...... 28 5 Konzepte ...... 29 5.1 Allgemeine Architektur ...... 29 5.2 Mobilis Client Services ...... 30 5.3 XMPP Services ...... 31 5.4 Mobilis Services...... 33 5.4.1 Coordinator Service ...... 34 5.4.2 User Context Service ...... 38 5.4.3 Grouping Service ...... 45 5.4.4 Repository Service und Content Service ...... 47 5.4.5 Collaborative Editing Service ...... 48 iv Inhaltsverzeichnis

5.4.6 Anwendungsspezifische Services ...... 49 5.5 Mobilis Beans ...... 51 6 Implementierung ...... 54 6.1 Paketstruktur ...... 54 6.2 MobilisServer ...... 56 6.2.1 Konfiguration ...... 56 6.2.2 Packages ...... 57 6.2.3 Coordinator Service ...... 58 6.2.4 Persistente Speicherung...... 59 6.3 MobilisXMPP ...... 59 6.4 Mobilis Client Services ...... 60 7 Evaluierung ...... 63 7.1 Funktionstest ...... 63 7.1.1 MobilisContext ...... 63 7.1.2 MobilisGroups ...... 66 7.1.3 MobilisMapDraw ...... 67 7.1.4 MobilisMedia ...... 68 7.1.5 MobilisXHunt ...... 69 7.1.6 MobilisLocPairs ...... 71 7.1.7 Social Network Service Example ...... 73 7.1.8 MobilisBuddy ...... 74 7.2 Vergleich mit anderen Systemen ...... 75 7.3 Entwicklernutzen ...... 76 7.4 Fazit ...... 86 8 Zusammenfassung und Ausblick...... 87 Anhang ...... I Abbildungsverzeichnis ...... VII Tabellenverzeichnis ...... X Abkürzungsverzeichnis ...... XI Literaturverzeichnis ...... XII Eidesstattliche Erklärung ...... XVII

v

1 Einleitung

1 Einleitung Als am Ende der 1990er Jahre die ersten Social-Networking-Webseiten eingeführt wurden, war an deren sensationellen Erfolg noch nicht zu denken. Bis heute haben sich weltweit mehrere 100 Millionen Nutzer bei solchen Diensten angemeldet und einige davon pflegen ihre sozialen Beziehungen damit sogar täglich. Sie bleiben in Kontakt mit Freunden, treten Interessensgemeinschaften bei und veröffentlichen ihre Gedanken, Meinungen, Empfehlungen sowie aktuelle Informationen über sich selbst. Da immer mehr Nutzer sozialen Netzwerken beitreten, werden virtuelle Gemeinschaften gefördert und es erhöht sich die soziale Interaktion innerhalb dieser. Die momentan zu beobachtenden Entwicklungen im Bereich mobiler Endgeräte sind ebenso interessant. Vor ein paar Jahren hemmten neben den eingeschränkten Eingabe- und Ausgabemöglichkeiten der Endgeräte noch viele andere Faktoren die Durchsetzung eines 2.0. Heute werden alte Funkübertragungstechnologien mit niedrigen Datenraten zu überhöhten Nutzungspreisen von verbesserten Technologien und datenvolumenbasierten Abrechnungsmodellen abgelöst. Die räumliche Abdeckung von Mobilfunkstandards der dritten Generation wächst rapide an und mit LTE (Long Term Evolution) steht der Nachfolgestandard bereits in den Startlöchern. Heutzutage ist der - und Tablet-PC-Markt so hart umkämpft, dass viele Hersteller regelmäßig neue Geräte mit neuen und verbesserten Features herausbringen. Es sind vor allem die Innovationen beim User Interface zu betonen. Erst die großen, mittels Touch-Eingaben bedienbaren Displays ermöglichten eine komfortable Nutzung von Online- Diensten und führten zu einer großen Akzeptanz der in breiten Bevölkerungsschichten. Im Oktober 2010 konnten knapp 30% aller US-amerikanischen Handybesitzer ein Smartphone ihr Eigen nennen (siehe [NC10b]). Zuvor stiegen diese Zahlen kontinuierlich an und ein Ende dieses Trends ist nicht abzusehen. Nutzer sind heutzutage auch unterwegs online und können somit die angesprochenen Internetdienste nutzen. Das Pervasive-Computing-Paradigma wird zur Realität und durch adaptive, kontextabhängige Anwendungen beginnen die Grenzen zwischen der realen und der virtuellen Welt zu verschwimmen. Anwendungen wie Facebook Places, Foursquare und Gowalla fördern das Zusammenwachsen der zwei Welten: Social Networking und Pervasive Computing. Daraus entstand der Trend, der Pervasive Social Computing oder auch Mobile Social Networking genannt wird. Zusammen mit Spielen, Wetter- und Kartenapplikationen spielen Social-Networking- Anwendungen heutzutage auf allen verfügbaren Smartphone-Betriebssystemen die wichtigste Rolle. 49% der in [NC10a] befragten Smartphone-Nutzer gaben an, in den letzten 30 Tagen eine Social-Networking-Applikation genutzt zu haben. Diese Applikationen können als Mobile Social Software klassifiziert werden. Dieser Begriff beschreibt Anwendungen für mobile Endgeräte mit dem Hauptziel, die soziale Interaktion zwischen den Nutzern zu ermöglichen und zu unterstützen. Auch Mobile Social Games und mobile kollaborative Anwendungen fallen in diesen Bereich.

1 1 Einleitung

Wichtige Punkte bezüglich Social Software sind Datenschutz, Datensicherheit und die Privatsphäre der Nutzer. Aktuelle Tests attestieren den meisten populären sozialen Netzwerken dahingehend nicht vernachlässigbare Mängel (siehe [SW10]). Die Besonderheit beim Social Networking auf mobilen Endgeräten ist, dass meist automatisch zusätzliche Informationen des Nutzerkontextes wie z.B. der aktuelle Aufenthaltsort ermittelt und genutzt werden. Viele Nutzer sind bereit, solche sensiblen Daten preiszugeben, um im Gegenzug von bestimmten Diensten profitieren zu können. Aufgrund der Sensibilität dieser Daten sollte allerdings das Augenmerk beim Mobile Social Networking insbesondere auf den Datenschutz gerichtet werden. Im Rahmen dieser Arbeit soll zu Beginn ein Überblick über kommerzielle Mobile Social Software und Forschungsarbeiten aus diesem Bereich gegeben werden. In der Analyse wird jedoch deutlich, dass viele Anwendungen sich stark ähnelnde Teilfunktionen anbieten, die jedes Mal von Grund auf neu entwickelt werden müssen. Daher soll in dieser Arbeit ein Konzept für ein Framework zur umfassenden Unterstützung der Entwicklung von Mobile Social Software erstellt und implementiert werden. Dies beinhaltet sowohl ein clientseitiges Framework mit generisch nutzbaren Diensten als auch wiederverwendbare serverseitige Dienste sowie Vorgaben für die Client-Server- Kommunikation. Die Client-Komponenten sollen für die Android-Plattform angepasst werden. Android ist ein Betriebssystem für mobile Endgeräte wie Smartphones, Netbooks und Tablet-PCs, das von der entwickelt wird. Es ist freie, quelloffene Software, die eine große Community von Android-Entwicklern vorweisen kann. Da weiterhin auch viele Geräte mit dem Android-Betriebssystem auf dem Markt existieren, gilt es als eines der vielversprechendsten Smartphone-Betriebssysteme der Zukunft. Wie in Abbildung 1 zu erkennen ist, hatte Android im Oktober 2010 einen Marktanteil von 22,7%. Betrachtet man andere aktuelle Statistiken, die lediglich kürzlich verkaufte Geräte (viertes Quartal 2010) einbeziehen, so ist Android mit 32,9% sogar der Marktführer. [Can11]

Abbildung 1: Statistik zu Marktanteilen verschiedener Smartphone-Betriebssysteme in den USA. Quelle: [NC10a]

2 1 Einleitung

Als Grundlage dieser Arbeit dient die am Lehrstuhl Rechnernetze der TU Dresden entwickelte Mobilis-Plattform, die bereits Anwendungen und Server-Dienste für verschiedene Teilbereiche von Mobile Social Software beinhaltet, jedoch noch kein anwendungsübergreifendes Dienstkonzept umsetzt. Nach einer Analyse der Anforderungen an ein Framework für Mobile Social Software folgt der Abschnitt Dienstumgebungen, in dem die für das Framework einsetzbaren Technologien diskutiert und verglichen werden. Konzeptionelle Aspekte und Implementationsdetails werden in den Kapiteln 5 und 6 dargestellt. Zum Abschluss dieser Arbeit wird das fertige Framework evaluiert, indem die einzelnen Funktionen demonstriert werden. Weiterhin wird der Nutzen des Frameworks für Anwendungsentwickler in einem Feldtest nachgewiesen. Dazu werden Studierende verschiedener Lehrveranstaltungen der Professur Rechnernetze, die Mobile Social Software auf der Basis der Mobilis-Plattform bzw. alternativen Wegen erstellen, begleitet und befragt.

3 2 Mobile Social Software und Frameworks

2 Mobile Social Software und Frameworks Dieses Kapitel gibt einen Überblick über den aktuellen Stand von Mobile Social Software. Nach einer Definition von Mobile Social Software werden dazu sowohl kommerzielle Anwendungen als auch Forschungsarbeiten aus diesem Bereich vorgestellt. Im ersten Abschnitt wird außerdem versucht, die in großer Zahl vorhandenen Systeme zu kategorisieren. Im zweiten Abschnitt folgt dann die Behandlung von Frameworks und Middleware Layer, mit denen sich Mobile Social Software entwickeln lässt.

2.1 Mobile Social Software Mobile Social Software (Abk. MoSoSo) ist eine Klasse von Anwendungen für mobile Endgeräte mit dem Hauptziel, die soziale Interaktion zwischen den Nutzern zu ermöglichen und zu unterstützen. MoSoSo ermöglicht also Kommunikation, Koordination und Kooperation innerhalb einer Nutzergemeinde. Da es eine Fülle von Applikationen in diesem Bereich gibt, wird oft versucht Klassifikationen und Taxonomien aufzustellen, in die die einzelnen MoSoSo-Anwendungen eingeordnet werden können. In [CH08] werden drei Modelle für Social Software vorgestellt: intimate, crowd und hybrid. Intimate Social Networks sind solche Systeme, deren Nützlichkeit sich erst zeigt, wenn andere persönliche Kontakte aus der realen Welt ebenfalls das System nutzen. Ein Beispiel für diese Kategorie ist Facebook [FIL11a]. Andererseits gibt es Systeme, bei denen die soziale Beziehung der Teilnehmer untereinander keinerlei Rolle spielt. Ein Beispiel für diese Crowd Networks ist die Auktionsplattform ebay [EI11]. Hybrid Networks verbinden Aspekte von den beiden vorher genannten Modellen. Bei solchen Systemen (wie z.B. Flickr [Yah11]) können sich Nutzer sowohl persönliche Beziehungen zunutze machen, als auch von unbekannten Teilnehmern erstellte Inhalte verwenden. Die Autoren von [JG05] schlagen hingegen eine Einteilung von ortsbasierten sozialen Netzwerken in vier Kategorien vor, abhängig davon ob es sich um synchrone oder asynchrone und nutzer- oder ortszentrierte Systeme handelt. In [ESSS11] wird Mobile Social Software danach klassifiziert, inwieweit der soziale Kontext ausgeprägt ist. Die Autoren betrachten vier Dimensionen des sozialen Kontextes: spatial, temporal, inference und people. Die räumliche Dimension (spatial) gibt Auskunft darüber, wie relevant die geografische Entfernung der Nutzer untereinander ist. Die Dimension temporal bestimmt den zeitlichen Aspekt bei gemeinsamer Interaktion der Nutzer. Weiterhin wird unterschieden, auf welche Art die Systeme den sozialen Kontext des Nutzers ableiten (inference). Letztlich wird die Art der Zielgruppe untersucht, mit der der Nutzer im sozialen Netzwerk interagiert (people). Dabei kann es sich um einzelne Personen, aber auch um Gruppen von Personen oder einen anonymen Nutzerkreis handeln. Die einzelnen Systeme werden anhand der Granularität der entsprechenden Dimensionen eingeordnet und letztlich entsteht für jedes System ein charakteristischer STIP-Vektor. In [RL10] wurde ebenfalls versucht, aktuelle Mobile Social Software in Gruppen einzuteilen. Die vorgeschlagenen Kategorien lauten Nachrichten- & Medienverteiler, Proximity Based

4 2 Mobile Social Software und Frameworks

Services, Geotagging, Partnervermittlungen sowie Mobile Social Games & Location Based Games. Im Folgenden sollen einige kommerzielle Anwendungen aber auch Forschungsarbeiten aus diesen Kategorien vorgestellt werden. Anwendungen aus der Kategorie Nachrichten- & Medienverteiler erlauben dem Nutzer das schnelle und unkomplizierte Senden von kurzen Textnachrichten bzw. verschiedenen Mediendateien an eine große Anzahl von Personen. Ein populärer Vertreter der Nachrichtenverteiler ist Twitter [Twi11]. Es handelt sich hierbei um eine Mikroblogging-Anwendung, die das Publizieren von kurzen Textnachrichten (maximal 140 Zeichen) erlaubt. Nutzer können die Beiträge („Tweets―) anderer Nutzer abonnieren (im Twitterjargon deren „Follower― werden) und werden dann benachrichtigt, falls neue Nachrichten geschrieben werden. Durch dieses Follower-System entsteht ein soziales Netzwerk, innerhalb dessen Kommunikation möglich ist. Ursprünglich war geplant, die Nachrichten am normalen Handy zu verfassen und als SMS zum Twitter-System zu versenden. Heute gibt es aber auch zahlreiche Twitter-Applikationen für die verschiedenen Smartphone-Betriebssysteme. Es existiert weiterhin auch ein Web- Frontend, das von vielen Nutzern intensiv zum Mikroblogging genutzt wird. Bei Proximity Based Services steht die Nähe zu bestimmten Personen oder Orten im Mittelpunkt. Meist wird auf einer Karte die Umgebung des Nutzers angezeigt. In dieser Umgebung wird die Position der Freunde des Nutzers dargestellt. Einige Systeme geben auch Benachrichtigungen bzw. Alarme aus, wenn ein Freund in einen vorher definierten Umkreis des Nutzers gelangt. Diese Funktionalität erlaubt es den Nutzern der Proximity Based Services, spontane Treffen mit Freunden in der näheren Umgebung zu vereinbaren. Manche Anwendungen zeigen in der Kartenansicht auch andere Orte wie Cafés, Bars, Restaurants oder Parks an. So kann gegebenenfalls schon auf der Karte erkannt werden, in welcher Lokalität sich der Freund aufhält. Weiterhin können auch einfach und schnell Treffen an den verzeichneten Orten vereinbart werden. Dodgeball wurde im Jahr 2000 gegründet und zählt als eine der ersten MoSoSo der Kategorie Proximity Based Services. Die Nutzer konnten dem System symbolische Orte mitteilen, an denen sie sich befinden. Dodgeball hat dann mittels Geocoding die exakte geografische Position ermittelt und den Nutzer benachrichtigt, wenn z.B. Freunde oder interessante Orte in der Nähe waren. Dodgeball wurde 2005 von Google aufgekauft und der Dienst wurde 2009 eingestellt, da es von Google Latitude [Goo11b] ersetzt wurde. Latitude ist Bestandteil der mobilen Google Maps Anwendung und somit für fast alle modernen Smartphones erhältlich. aka-aki [AANG11] ist ebenfalls ein kommerzieller Vertreter der Proximity Based Services. Die Anwendung ist vor allem im deutschsprachigen Raum verbreitet, da das Projekt erst 2008 von Berliner Studierenden gestartet wurde. Teilnehmer haben die Möglichkeit, ihre eigenen Interessen in Form von „Stickern― auf ihrem Mitgliederprofil zu präsentieren. Wenn Freunde oder andere Nutzer mit den gleichen Interessen in der Nähe sind, gibt aka-aki eine Benachrichtigung aus. Die Umgebungssuche arbeitet im Normalfall mit . Falls kein Treffer in der näheren Umgebung gefunden wurde, wird die Ortung mittels Cell-ID oder GPS durchgeführt.

5 2 Mobile Social Software und Frameworks

Ein Beispiel aus dem Forschungsbereich ist VENETA [ABKW08]. Es handelt sich um ein serverloses System zur Erkennung von Freunden der eigenen Freunde in der näheren Umgebung. Über Bluetooth werden die Adressbücher der sich nah zueinander befindlichen Nutzer verglichen. Ist in beiden Listen der gleiche Eintrag zu finden, handelt es sich also um „Freundesfreunde―. Sowohl Datenaustausch als auch die Adressbucheinträge selbst sind dabei verschlüsselt. Neben dem beschriebenen Contact Matching unterstützt VENETA auch das normale Profile Matching. Ein ähnliches Projekt ist WhozThat [BGA+08]. Hier werden anstatt Adressbucheinträgen aber IDs von sozialen Netzwerken wie Facebook untereinander ausgetauscht. Diese werden dann benutzt, um die dort angelegten persönlichen Profile abzurufen. Zur Demonstration wurde zusätzlich eine kontextsensitive Musikanwendung namens WZPlaylistGen entwickelt. Es handelt sich dabei um ein Java-Programm, das das Protokoll von WhozThat implementiert und mithilfe von Bluetooth die WhozThat-Nutzer in der Umgebung erfasst. Mit deren Facebook IDs und dem bei Facebook angegebenen Musikgeschmack erstellt WZPlaylistGen nun eine Liste von Liedern, die so weit wie möglich mit den Einstellungen der anwesenden Nutzer übereinstimmt. Auch das in [LSHG08] vorgestellte PeopleTones gehört zur Kategorie der Proximity Based Services. PeopleTones ist ein System zur Erkennung von Freunden in der näheren Umgebung. Der Nutzer wird bei jedem auftretenden Proximity-Ereignis durch ein leichtes Vibrieren des Telefons hingewiesen, sodass er in unpassenden Situationen nicht abgelenkt wird. Das besondere an PeopleTones ist die Art und Weise, wie die Nähe der Nutzer zueinander ermittelt wird, denn es nutzt nicht wie andere Systeme Bluetooth oder WLAN. Vielmehr verwendet der in PeopleTones eingesetzte Algorithmus die vom Handy erreichbaren Mobilfunktürme, um die Entfernung zweier Nutzer zueinander abzuschätzen. Die Ortung der Teilnehmer wird also nur relativ zueinander und nicht absolut durchgeführt, was Vorteile für die Wahrung der Privatsphäre der Nutzer mit sich bringt. Eine weitere Klasse bilden die Geotagging-Anwendungen. Diese sind sehr stark ortsbezogen. Sie erlauben es den Nutzern, Bilder, Texte und andere Nutzerinhalte (engl. User Generated Content, Abk. UGC) mit geographischen Daten und anderen Meta-Daten zu versehen (engl. Tagging) und innerhalb einer Nutzergemeinschaft zu veröffentlichen. Durch die hinzugefügten Informationen ist eine Anzeige des UGC auf einer Karte möglich. Eine weitere Funktion ist die Benachrichtigung, wenn ein getaggter Inhalt in der Nähe der aktuellen Nutzerposition angelegt wurde. Ein populärer Vertreter dieser Kategorie ist Google Buzz [Goo11a]. Es erweitert die Idee der normalen Statusnachrichten, mit denen man innerhalb vieler sozialer Netzwerke mitteilen kann, was man gerade denkt oder tut. Es können nicht nur Texte, sondern auch Bilder, Videos und geographische Daten in eine solche Statusnachricht („Buzz―) integriert werden. Zu einer geschriebenen Neuigkeit sind somit also auch Standortinformationen verfügbar, die sich die Kontakte des Nutzers auf einer Karte (z.B. Google Maps) anzeigen lassen können. Die Kontakte importiert Google Buzz aus dem Adressbuch des eigenen Emaildienstes Google Mail. Eine andere Kategorie von Mobile Social Software stellen Partnervermittlungen dar. Diese Anwendungen funktionieren wie ihre Pendants aus dem Web. Der Nutzer erstellt ein Profil

6 2 Mobile Social Software und Frameworks von sich selbst, indem er eine Reihe von Fragen zu seiner Person und seinen Interessen beantwortet. Dieses Profil wird mit anderen Profilen verglichen. Die ähnlichsten Profile anderer Teilnehmer werden dem Nutzer als potentielle Partner vorgeschlagen und er kann Kontakt zu ihnen aufnehmen. Das besondere an der mobilen Variante von Partnervermittlungen ist der Ortsbezug. So werden dem Nutzer nur Vorschläge von Personen unterbreitet, die sich in seinem direkten Umkreis (z.B. in der gleichen Bar) aufhalten. Weiterhin wird der Nutzer durch einen Alarm benachrichtigt, wenn eine zu ihm passende Person in der Nähe ist, die ebenfalls einen Partner sucht. Anwendungen dieser Kategorie sind daher oft auch bei den Proximity Based Services einzuordnen. Aufgrund der Fülle von solchen Systemen wurde jedoch diese eigene Kategorie geschaffen. MeetMoi [ML11] ist solch eine Location-Based-Mobile--Anwendung für Smartphones. Die oben beschriebenen Merkmale der Partnervermittlungsanwendungen treffen alle auf MeetMoi zu. Die Position kann durch das Programm mittels GPS bestimmt, aber auch manuell gesetzt werden. Es können weiterhin auch bestimmte Orte wie die Heimatadresse oder das Lieblingsrestaurant angelegt und mit geographischen Daten versehen werden. So kann der Nutzer leichter wählen, an welchem Ort er sich befindet. Eine weitere Gruppe bilden die Mobile Social Games. Dazu gehören einerseits Location Based Games (Abk. LBG, zu Deutsch „ortsbezogenes Spiel―). Ein LBG ist ein Spiel, das auf der Veränderung der geographischen Position seiner Spieler beruht. Die Nutzer bewegen sich also in der realen Welt und sind mit mobilen Endgeräten ausgestattet, die die Lokalisierung übernehmen und über den Spielverlauf informieren. In den meisten LBGs sind auch soziale Features wie Chats, Highscore-Listen oder Abstimmungen zu finden. Andererseits gehören aber auch MoSoSo-Systeme mit spielerischen Elementen in diese Kategorie. Populäre Vertreter dieser Kategorie sind Foursquare [Fou11] und Gowalla [Gow11]. Beide Anwendungen haben das gleiche Grundprinzip. Die Nutzer teilen dem System mit, an welchem Ort sie sich gerade befinden, indem sie sich in die entsprechenden Lokalitäten in ihrer Nähe (z.B. Restaurants, Bars, Läden) „einchecken―. Ihnen wird dann angezeigt, welche anderen Nutzer (ggf. eigene Freunde) sich ebenfalls an diesem Ort aufhalten. Bei Foursquare wird der Nutzer für das Einchecken mit Punkten und Abzeichen („Badges―) belohnt, wohingegen man bei Gowalla Auszeichnungen und virtuelle Gegenstände sammelt. Erscheint man häufig an einem bestimmten Ort, so erhält man bei Foursquare das Amt des „Bürgermeisters― („Mayor―), was unter Umständen zu gewissen Vergünstigungen oder Erlassen in der entsprechenden Lokalität führen kann. Den Unternehmen bietet Foursquare ein Analysewerkzeug an, mit dem Statistiken über die Besucher generiert werden können. Die Nutzer haben weiterhin die Möglichkeit, Tipps und Kommentare für andere Nutzer zu hinterlassen. Auch die in [RL10] vorgestellte Klassifizierung ist weder vollständig noch disjunkt, denn nicht jede Mobile Social Software lässt sich in eine Kategorie einordnen und es gibt Anwendungen, die man mehreren Klassen zuweisen kann. Eine solche nicht leicht kategorisierbare Anwendung ist das in [MLF+08] vorgestellte CenceMe. Hier wird der mithilfe verschiedener Sensoren erstellte Nutzerkontext ins soziale Netzwerk gebracht.

7 2 Mobile Social Software und Frameworks

Solche Sensoren wie z.B. Beschleunigungsmesser, GPS-Empfänger, Abstandssensoren, Mikrofon und Kamera sind in modernen Smartphones standardmäßig enthalten. In regelmäßigen Abständen fragt die Anwendung die Sensoren ab, bearbeitet die Rohdaten und sendet die aufbereiteten Sensordaten an einen Backend-Server, auf dem dann komplexere Klassifikationsaufgaben gelöst werden. Die CenceMe-Anwendung wurde vorerst nur für das Nokia N95 Smartphone entwickelt. Um die aufbereiteten Sensordaten zu erstellen, werden Audioaufnahmen des Mikrofons, aktuelle GPS-Daten und in der Umgebung gefundene Bluetooth MAC Adressen verwendet. Weiterhin werden Beschleunigungsmessungen durchgeführt, bei bestimmten Ereignissen automatisch mittels der eingebauten Kamera Fotos gemacht und diese letztendlich ausgewertet. Abbildung 2 veranschaulicht die Architektur der CenceMe-Smartphone-Anwendung und des CenceMe Server. Beide Komponenten wurden mithilfe von Java umgesetzt. Auf dem Server wird für die persistente Speicherung eine MySQL-Datenbank verwendet. Die Kommunikation zwischen Client und Server erfolgt über XML Remote Procedure Calls.

Abbildung 2: Architektur von CenceMe Smartphone Software (links) und Backend Server (rechts). Quelle: [MLF+08]

Die Autoren der CenceMe-Applikation haben außerdem eine große Nutzerstudie mit dreiwöchigem Umfang durchgeführt. Ein Großteil der Nutzer fand die von CenceMe angebotenen Features nützlich. Insbesondere Nutzer anderer sozialer Netzwerke (Facebook) haben sehr häufig ihren CenceMe-Status in diesen veröffentlicht. CenceMe weckte Neugier über die Aktivitäten anderer Nutzer, aber konnte auch helfen, die eigenen Aktivitäten und den eigenen sozialen Status zu verstehen. Eine andere interessante Anwendung ist das in [ASL+09] vorgestellte Friendlee. Hier werden die Anruf- und Chat-Aktivitäten des Nutzers analysiert, um ein enges Netz von sozialen Kontakten des Nutzers zu erstellen. Es werden sozusagen die „wahren Freunde― eines Nutzers aus dessen Telefonbuch herausgefiltert. Jedem Kontakt aus dem Telefonbuch wird ein relatives Gewicht zugeordnet, das die Nähe zum Nutzer repräsentiert. Dieses Gewicht wird u.a. mithilfe der Häufigkeit und der durchschnittlichen Dauer der Anrufe des Kontakts sowie dem Zeitpunkt der letzten Interaktion errechnet. Die Kontakte mit der höchsten Bewertung bilden sein enges soziales Netzwerk und werden für den Nutzer hervorgehoben.

8 2 Mobile Social Software und Frameworks

Wie eine normale Social-Networking-Anwendung unterstützt Friendlee auch das Browsen durch die Freundeslisten der eigenen Kontakte. Der Nutzer kann seine Kontakte in Kategorien einordnen, z.B. Kollegen und Familie. Dies wird allerdings nicht nur der Übersicht halber getan, sondern auch, um für jede Kategorie eigene Privatsphäre-Einstellungen festlegen zu können. Wenn der Nutzer bestimmte Unternehmen anruft oder auf andere Weise mit Ihnen kommuniziert, vermerkt Friendlee dies ebenso. So entsteht eine Liste der favorisierten Unternehmen des Nutzers, die wiederum im engeren sozialen Netzwerk veröffentlicht werden kann. Die Architektur von Friendlee folgt dem Client-Server-Modell. Der Client stellt die Benutzeroberfläche dar und sammelt die Informationen des Nutzers. Diese werden zum Backend Server übertragen, der zentral alle Nutzerdaten verwaltet. Außerdem wird dem Nutzer ein Web Interface angeboten, das die gleiche Funktionalität wie die Smartphone Applikation hat. Als weitere interessante Anwendung sei das in [MSN05] vorgestellte PeopleNet genannt. Personen fragen oft andere Personen, um ein Informationsbedürfnis zu stillen, obwohl ihnen auch andere Wege wie das Internet oder Bibliotheken zur Verfügung stehen. Personen sind nämlich sehr gute Informationsquellen, von denen man orts- und zeitspezifisch angepasste Informationen erhalten kann. PeopleNet versucht diese menschliche Vorgehensweise nachzuahmen. Es ist ein System zum Abgleich von Anfragen und Antworten. Anfragen werden immer an eine Gruppe von Personen an einem bestimmten Ort (Bazaar genannt) weitergeleitet. So lassen sich Anfragen wie die Suche nach einem „guten Italiener in Dresden― lösen. Es wird aber auch ein Matching von Requests und Offers unterstützt, das bspw. in einer Shopping-Anwendung nützlich wäre.

2.2 Frameworks Im Software Engineering ist ein Framework ein Rahmenwerk, das dem Programmierer einen Entwicklungsrahmen für seine Anwendungsprogrammierung zur Verfügung stellt. Die grobe Architektur der damit erstellten Programme wird vom Framework festgelegt. Auch im Bereich von Mobile Social Software gibt es mehrere Frameworks. Diese stammen meist aus dem Forschungsbereich und werden auch Middleware Layer genannt. Frameworks aus diesem Bereich kümmern sich also um Social-Network-Management-Details, wodurch sich die Programmierer von Mobile Social Software auf Entwurf und Entwicklung der eigentlichen Anwendungslogik konzentrieren können. Meist werden in Abhandlungen über diese Frameworks auch Beispielanwendungen gezeigt, die die angebotenen Funktionen nutzen. Oft findet man auch Untersuchungen zur Performanz der Framework-Funktionen. Im Folgenden sollen einige Frameworks für Mobile Social Software vorgestellt werden. SAMOA steht für Socially Aware and Mobile Architecture und wurde von Dario Bottazzi, Rebecca Montanari und Alessandra Toninelli an der Universität von Bologna entwickelt. In [DBRMAT07] beschreiben die Autoren das SAMOA Framework, das die Entwicklung von

9 2 Mobile Social Software und Frameworks

„anytime, anywhere semantic context-aware social networks― [DBRMAT07] unterstützen soll. Mithilfe von SAMOA lassen sich Rückschlüsse auf bisher unbekannte soziale Beziehungen ziehen. Dazu wird ein Vergleich von in Nutzer- und Ortsprofilen angegebenen Attributen und Aktivitäten durchgeführt. Das Ziel ist also das Finden von mobilen Nutzern, die ein ähnliches Profil haben und die sich in geografischer Nähe zueinander befinden. SAMOA kann als nutzerzentriert bezeichnet werden. Jeder Nutzer hat mindestens eine der folgenden Rollen inne. Manager sind die mobilen Nutzer, die ein soziales Netzwerk erstellen wollen. Sie bestimmen die räumliche Reichweite und weitere Kriterien ihres sozialen Netzwerks. Clients sind die Nutzer, die sich innerhalb der örtlichen Grenzen des sozialen Netzwerks eines Managers aufhalten und somit grundlegend die Möglichkeit haben, dort Mitglied zu werden. Members sind die Mitglieder des sozialen Netzwerks eines Managers. Ein weiteres Konzept ist das des Place. Der Manager ist das Zentrum eines Place, der die Menge aller Clients darstellt, die eine räumliche Nähe zum Manager aufweisen. Diese räumliche Nähe lässt sich auch durch die Größe des Routingpfades zwischen Client und Manager ausdrücken. Das Maximum dieser Größe wird auch Place Radius genannt. In der Praxis wird ein Place bspw. durch einen WLAN Access Point beschrieben, zu dem alle Nutzer verbunden sind. Alle Entitäten, die bei SAMOA auftreten, sind Places oder Nutzer. Sie werden durch eindeutige Bezeichner identifiziert und wie schon vorher angedeutet durch Profile beschrieben. So gibt es Place-Profile, die den bestimmten Ort benennen und beschreiben und die die dort durchführbaren Aktivitäten auflisten. In Nutzerprofilen werden persönliche Daten wie Alter und Geschlecht gespeichert, aber auch die Aktivitäten, für die sich der Nutzer interessiert. Die Informationen aus diesen Profilen kann nun der Manager verwenden, um ein ortsbezogenes oder globales soziales Netzwerk aufzubauen. Im ortsbezogenen Netzwerk sind nur die Mitglieder enthalten, die sich gerade am gleichen Ort wie der Manager aufhalten. Das globale soziale Netzwerk eines Managers hingegen besteht aus der Menge aller Nutzer, die zu irgendeiner Zeit bereits Mitglied eines seiner ortsbezogenen Netzwerke waren. Die SAMOA-Architektur (siehe Abbildung 3) besteht aus zwei Schichten: Basic Service Layer und Social Network Management Layer. Der Basic Service Layer ermöglicht sowohl die Kommunikation (Message Transport Manager) als auch die Erkennung in der Nähe befindlicher SAMOA Entitäten (Location / Proximity Manager). Der Social Network Management Layer beinhaltet alle Komponenten zur Verwaltung des sozialen Netzwerkes. Im Profile Manager werden sowohl die Nutzer- als auch die Ortsprofile verwaltet. In der Semantic Matching Engine laufen die Matching-Algorithmen, die basierend auf den Profildaten die Interessens- bzw. Aktivitätsübereinstimmungen zwischen Nutzern bzw. zwischen Nutzern und Places errechnen. Der Place-Dependent Social Network Manager verwaltet die ortsbezogenen sozialen Netzwerke. Daher hält er bspw. eine Tabelle mit allen Mitgliedern. Weiterhin arbeitet er mit dem Profile Manager zusammen, um auf die Informationen der Nutzerprofile der Mitglieder zuzugreifen. Der Global Social Network

10 2 Mobile Social Software und Frameworks

Manager hält eine Liste aller ortsbezogenen sozialen Netzwerke und verwaltet somit das globale soziale Netzwerk.

Abbildung 3: Architektur der SAMOA Middleware. Quelle: [DBRMAT07]

Um die Funktionen des SAMOA Frameworks zu demonstrieren, wurde eine Beispielanwendung aus dem Marketingbereich entwickelt. Sie erlaubt es einem Ladeninhaber, Werbung (z.B. Informationen über Rabattaktionen) an die Mitglieder seines globalen oder ortsbezogenen sozialen Netzwerkes zu schicken. Eine Performanceanalyse hat gezeigt, dass mit dem SAMOA Framework entwickelte Anwendungen durchaus in der Praxis eingesetzt werden können, da sie gut skalieren. MobiSoc steht für Middleware for Mobile Social Computing Applications und wurde von Ankur Gupta, Achir Kalra, Daniel Boston und Cristian Borcea am New Jersey Institute of Technology entwickelt. [GKBB09] Genau wie bei SAMOA handelt es sich bei MobiSoc um eine Plattform, die verschiedene Funktionen bzgl. sozialer Netzwerke anbietet, damit Mobile Social Software einfacher entwickelt werden kann. Auch hier werden Orts- und Nutzerprofile verwendet, um die soziale Welt zu modellieren. Allerdings unterscheiden sich SAMOA und MobiSoc im Grundansatz. SAMOA ist ein nutzerzentriertes System, denn die sozialen Netzwerke werden für die einzelnen Nutzer aufgebaut und errechnet. Auf einem MobiSoc-Server wird allerdings der komplette Social State einer bestimmten Community verwaltet. Daher kann MobiSoc als community-zentriert bezeichnet werden. Aus Gründen der Energieeffizienz auf den mobilen Endgeräten haben mit MobiSoc entwickelte Anwendungen eine Client-Server-Architektur. So kann nämlich die aufwändige Berechnung im MSCA-Service auf dem MobiSoc-Server erfolgen, wohingegen auf dem Endgerät nur ein Thin Mobile Client laufen muss. Weiterhin handelt es sich um einen erweiterbaren service-orientierten Ansatz (Java Services auf einem Apache Tomcat Server).

11 2 Mobile Social Software und Frameworks

Einen Überblick über die grundlegende Architektur von MobiSoc bietet Abbildung 4. Die einzelnen Module können auch auf mehreren Servern verteilt arbeiten, was zu einer guten Skalierbarkeit führt.

Abbildung 4: MobiSoc-Architektur. Quelle: [GKBB09]

Die Data Collection verwaltet alle anfallenden Daten und die Profile von Nutzern und Orten. Das Location-Modul empfängt, speichert und verwaltet alle eingehenden Location Updates. Das Social-State-Learning-Modul repräsentiert die Beziehung zwischen zwei Entitäten (Nutzer oder Orte). Das People-Profiling-Modul verwaltet nutzerzentrierte Informationen wie Profile, soziale Verbindungen und Gruppen. Das Place-Profiling-Modul reichert die Semantik von Ortsentitäten mit sozialen Informationen an, wie z.B. die Frequentierung eines Ortes zu bestimmten Tageszeiten. Das People-People--Learning-Modul errechnet die soziale Zusammengehörigkeit zwischen zwei Nutzern aufgrund von gleichen Interessen, gleicher Herkunft, gemeinsamen Freunden und gleichen besuchten Orten. Das People-Place- Affinity-Learning-Modul analysiert das Bewegungsverhalten der Nutzer, um besondere (z.B. meist abends frequentierte) Orte für bestimmte Personen oder Personengruppen zu identifizieren. Der Event-Manager dient zur asynchronen Kommunikation mittels Pull-Mechanismus mit den Anwendungen. Die mobilen Endgeräte fragen also in bestimmten Abständen bei der Middleware an, ob neue Ereignisse aufgetreten sind. Das Privacy-Management-and-Enforcement-Modul verwaltet die individuellen Privatsphäre- Einstellungen der Nutzer und setzt die entsprechenden Regeln durch. So kann ein Nutzer bspw. entscheiden, dass er erst zustimmen muss, bevor ein anderer Nutzer sein Profil mit den persönlichen Daten ansehen darf. Weiterhin können Anwendungen die zentrale Proximity Detection des MobiSoc-Servers nutzen. Hierbei können Ereignisse ausgelöst werden, wenn sich bestimmte Entitäten innerhalb eines festgelegten Umgebungsradius zueinander befinden. Die Autoren des MobiSoc-Frameworks haben ebenfalls prototypische Beispielanwendungen umgesetzt, die in [GKBB09] näher beschrieben werden. Das Ergebnis einer durchgeführten Nutzerstudie lautet wie folgt: Nutzer sind durchaus gewillt, auch sensible persönliche Daten

12 2 Mobile Social Software und Frameworks wie den aktuellen Aufenthaltsort preiszugeben, um im Gegenzug von den durch Mobile Social Software bereitgestellten Funktionen zu profitieren. Das in [POL+09] vorgestellte MobiClique ist eine weitere Middleware für Mobile-Social- Networking-Anwendungen. MobiClique versucht die virtuelle und die physische Welt näher zusammen zu bringen. Nutzer können ihre virtuellen sozialen Netzwerke auch innerhalb der realen Welt verwalten und erweitern. Die Besonderheit dabei ist der Verzicht auf die klassische Client-Server-Architektur. Es wird auch keine Verbindung zu einer Infrastruktur benötigt, denn MobiClique beruht auf gelegentlichen Ad-hoc-Verbindungen zwischen benachbarten mobilen Geräten über Bluetooth oder WLAN. Die Grundfunktionen ähneln stark denen der bereits vorgestellten Middleware-Systeme. So finden bei MobiClique bspw. auch Nutzerprofile Einsatz. Sie werden auf dem jeweiligen Gerät des Nutzers verwaltet und können mit bestehenden Profilen aus anderen sozialen Netzwerken wie Facebook synchronisiert werden. Für diese Synchronisierung wird ein gelegentlicher Zugang zum Internet vorausgesetzt. Ein mobiler MobiClique Peer führt periodisch die folgenden Schritte aus. Zuerst wird in der eigenen Umgebung nach anderen Peers gesucht. Dies ist natürlich abhängig von der verwendeten Technologie (Bluetooth oder WLAN). Daraufhin werden gefundene Nutzer identifiziert und eventuell auch authentifiziert. In dieser Phase werden die kompletten Nutzerprofile ausgetauscht und auf dem jeweils anderen Gerät persistent gespeichert, um erneute Übertragungen zu verhindern. Danach folgt die Phase des Datenaustauschs, in der auf Applikationsebene Nachrichten gesendet und empfangen werden. Diese Nachrichten können an einzelne MobiClique-Nutzer aber auch an Nutzergruppen geschickt werden.

Abbildung 5: Architektur des MobiClique-Systems. Quelle: [POL+09]

Abbildung 5 zeigt einen Überblick über die Architektur des MobiClique-Systems. Der blaue Kreis symbolisiert das Gebiet innerhalb dessen sich mobile Endgeräte ad hoc verbinden können.

13 2 Mobile Social Software und Frameworks

Auch in MobiClique wurde zugunsten einer schnellen, prototypischen Umsetzung auf Features für Datenschutz und Sicherheit verzichtet. Zusammenfassend ist zu sagen, dass das MobiClique Framework über das reine Profile Matching hinausgeht. Anwendungen können Proximity-based Services nutzen und der Ad- hoc-Ansatz ohne zentralen Server ist durchaus Alleinstellungsmerkmal von MobiClique. SocialAware [Gar08] ist ein Framework zur Erstellung von kontextsensitiven Social- Networking-Diensten. Es basiert auf dem schon vorher angesprochenen WhozThat-Protokoll zum Austausch von Nutzer-IDs sozialer Netzwerke wie Facebook. Auch hier wird zur Kommunikation Bluetooth eingesetzt. Die Architektur folgt dem Client-Server-Modell. Eine stationäre Komponente erkennt die Facebook IDs aller Nutzer in der näheren Umgebung und kann dann mithilfe der abgerufenen Profile eine Anpassung an die Nutzer durchführen. Als Beispiel wurde wie bei WhozThat eine kontextabhängige Musikanwendung umgesetzt. Eine andere Beispielanwendung ist SocialAwareFlicks. Hier werden Filmtrailer abgespielt, die den Filmgeschmack aller anwesenden Nutzer repräsentieren. Es gibt durchaus noch weitere Frameworks für Mobile Social Software, die im Rahmen dieser Arbeit allerdings nicht genauer betrachtet werden sollen. Dazu gehören FLORA [KSJ08], RoadSpeak [SHSI08] und der in [MMC09] vorgestellte Middleware Service für Pervasive-Social-Networking-Anwendungen.

2.3 Fazit In diesem Kapitel wurden sowohl einzelne MoSoSo-Systeme als auch Frameworks und Middleware Layer zur Erstellung dieser vorgestellt. Es wurde außerdem deutlich, dass in der Fülle von verschiedenen Anwendungen trotzdem meist ähnliche Features zu finden sind. So ist innerhalb vieler Systeme die Kommunikation und Anzeige von Verfügbarkeitsinformationen innerhalb der Nutzergemeinschaft möglich. Außerdem werden oft externe soziale Netzwerke in die eigene Anwendung eingebunden. Letztlich sind auch Proximity Detection und die Verwaltung des Nutzerkontextes oft in Mobile Social Software zu findende Features. Aufgrund dieser Ähnlichkeit der MoSoSo-Systeme bietet sich die Verwendung eines Frameworks zur Erstellung neuer Applikationen an. Entwicklungsaufwand kann so reduziert werden, denn die Programmierer können sich auf die Umsetzung der Anwendungslogik konzentrieren, während Social Network Features vom Framework geregelt werden. Abschnitt 2.2 hat gezeigt, dass durchaus schon einige Frameworks und Middleware Layer existieren. Wichtige Aspekte bleiben bei diesen Systemen allerdings oft unbeachtet, z.B. Datenschutz und Datensicherheit. Die in MoSoSo gespeicherten und ausgetauschten Daten sind durchaus sensibel, denn sie enthalten beispielsweise Namen, Kontaktdaten und den aktuellen Aufenthaltsort der Nutzer. Eine Verschlüsselung der Übertragung und der Daten auf dem mobilen Endgerät ist also durchaus gefordert. Weiterhin sind alle vorgestellten Systeme stark plattformabhängig, d.h. die erstellten Anwendungen laufen immer nur auf einem bestimmten Smartphone-Betriebssystem. Aufgrund der Vielfalt der verschiedenen Betriebssysteme (z.B. Apples iOS, Android, Windows Phone, Windows Mobile, Symbian OS, Blackberry OS, WebOS, , Meego, Samsung Bada), die manchmal noch in

14 2 Mobile Social Software und Frameworks verschiedenen inkompatiblen Versionen existieren, ist ein plattformunabhängiger Ansatz wünschenswert. In dieser Arbeit wird im Folgenden versucht, ein eigenes Framework für MoSoSo-Systeme umzusetzen, das einerseits viele der aufgezählten Features unterstützt und andererseits die Unzulänglichkeiten einiger bestehender Frameworks überwindet. In Abschnitt 7.2 erfolgt ein abschließender Vergleich der entwickelten Lösung mit einigen in diesem Kapitel vorgestellten Frameworks.

15 3 Anforderungsanalyse

3 Anforderungsanalyse Im vorigen Kapitel wurde ein allgemeiner Überblick über den Bereich von Mobile Social Software gegeben. Dabei wurde festgestellt, dass viele mobile Anwendungen gleiche oder ähnliche Features haben. Daher ist es durchaus sinnvoll, für die Entwicklung neuer Anwendungen ein Framework zu verwenden, das den Applikationen oft verwendete Dienste und fertige Komponenten zur Integration anbietet. In diesem Kapitel sollen die Anforderungen an solch ein Framework betrachtet werden. Eine Anforderung ist eine Beschreibung dessen, was das fertig gestellte Framework leisten soll und auch wie dieses Ziel erreicht werden soll. Dazu wird zunächst auf die funktionalen Anforderungen eingegangen. Danach folgt eine Auflistung aller Geräteanforderungen, die erfüllt sein müssen, um ein problemloses Ausführen der mit dem Framework entwickelten Anwendungen zu gewährleisten. Abschließend werden die nichtfunktionalen Anforderungen betrachtet.

3.1.1 Funktionale Anforderungen In diesem Abschnitt sollen die Hauptfunktionen des zu entwickelnden Frameworks festgelegt werden. Innerhalb des Frameworks müssen einfache Kommunikationsmöglichkeiten zwischen allen involvierten Entitäten gewährleistet sein (FA-1). Dazu zählt einerseits, dass die Endnutzer der Anwendungen untereinander Textnachrichten austauschen können (von Client zu Client). Andererseits ist aber auch die Kommunikation von Client zum Server und vom Server zum Client zwingend erforderlich. Die Adressierung der einzelnen Entitäten sollte über eindeutige Identifier geschehen. Weiterhin sollen alle beteiligten Kommunikationspartner untereinander Informationen zur Verfügbarkeit (engl. Presence) austauschen und abrufen können (FA-2). Jeder Nutzer soll seinen eigenen Verfügbarkeitsstatus (z.B. available, busy, do-not-disturb) setzen und ihn zu einem Presence Server propagieren können, von wo aus die Informationen an andere berechtigte Nutzer weiter verteilt werden. Context Management spielt im Zusammenhang mit Anwendungen auf mobilen Endgeräten eine wichtige Rolle. Um die Adaptivität der Applikationen zu gewährleisten, muss das Framework den Kontext der Nutzer ermitteln, verwalten und an autorisierte Stellen weitergeben können (FA-3). Zum Kontext zählen in erster Linie Informationen zum Aufenthaltsort, aber auch z.B. Freundesangaben oder Profilinformationen des Nutzers. Die Nutzung bestehender sozialer Netzwerke ist in Mobile Social Software eine Kernkomponente. Daher soll es mithilfe des Frameworks leicht möglich sein, externe Social Networks in die eigene Anwendung zu integrieren (FA-4). Innerhalb von sozialen Netzwerken ist der Austausch von Dateien eine viel benutzte Funktion. Deshalb soll das Framework eine File-Sharing-Funktion bieten, die das Senden und Empfangen von beliebigen Dateien erlaubt (FA-5). Hauptsächlich werden allerdings Fotos und Videos mit den eigenen Freunden ausgetauscht. Daher soll das Framework neben dem allgemeinen File Sharing insbesondere auch Media

16 3 Anforderungsanalyse

Sharing unterstützen (FA-6). Damit ist neben dem normalen Austausch auch eine Tagging- Funktion gemeint, die es ermöglicht, Medien mit bestimmten Metadaten wie Aufnahmeort und –zeit sowie Autor zu versehen. Eine Suche innerhalb dieser Metainformationen ist ebenfalls wünschenswert. Eine weitere Kernkomponente von sozialen Netzwerken ist die Bildung von Gruppen, in denen sich Nutzer mit ähnlichen Interessen organisieren können. Das vom Framework geforderte Group Management (FA-7) beinhaltet neben dem Erstellen und Löschen von Gruppen auch die Verwaltung von Mitgliedern und Gruppenbeitritten. Im Kontext von mobilen Anwendungen sind zwei spezielle Formen der Gruppenbildung denkbar. Die erste ist die Location Based Group Formation. Bei dieser ortsbasierten Gruppenbildung (FA-7.1) ist es Nutzern z.B. nur an bestimmten Aufenthaltsorten möglich, Gruppen zu sehen oder ihnen beizutreten. Die zweite spezielle Form ist die dynamische Gruppenbildung (FA-7.2). Hierbei wird der Nutzer automatisch anhand seiner Position in bestimmten Gruppen ein- oder ausgeschrieben. Beide Formen sollen vom Framework unterstützt werden. Den erstellten Nutzergruppen soll als weitere Kommunikationsmöglichkeit ein Multi-User Chat zur Verfügung stehen (FA-8). In diesem Chat-Raum können mehrere Benutzer untereinander Textnachrichten austauschen. Proximity Detection Services sind Dienste, die den Nutzer darüber informieren, dass in seiner Nähe eine bestimmte Aktion möglich ist. So könnte eine Anwendung beispielsweise Alarm schlagen, wenn ein Freund in der Nähe ist oder wenn ein nahe gelegenes Restaurant ein besonders Angebot hat. Solche Dienste sollen vom Framework ebenfalls unterstützt werden (FA-9). Kollaboration innerhalb sozialer Netzwerke ist ein Bereich mit viel Potenzial. Das Framework soll deshalb das gemeinsame Bearbeiten von Dokumenten (engl. Shared Editing, Collaborative Editing) unterstützen (FA-10). Insbesondere soll auch das gleichzeitige Bearbeiten von XML-Strukturen möglich sein. Weiterhin ist ein generischer Publish-Subscribe-Mechanismus gewünscht (FA-11). Dieser dient zur Weitergabe von Änderungen an einem bestimmten Objekt an alle von diesem Objekt abhängigen Komponenten. Das Objekt verwaltet dazu alle Abonnenten (engl. Subscriber), die an Informationsupdates interessiert sind, und benachrichtigt diese bei einer entsprechenden Zustandsänderung. Die Objektänderung wird sozusagen veröffentlicht (engl. to publish). Es sind zahlreiche Anwendungsfälle denkbar, in denen diese Funktion benutzt werden könnte, z.B. bei erweiterten Verfügbarkeitsinformationen, innerhalb von Auktionsplattformen oder bei Wetter-, Verkehrs- und Aktienkurs-Updates. Mithilfe einer Trading-Funktion (FA-12) können Nutzer bestimmte Angebote an andere Nutzer machen, die diese dann beantworten. Es soll also ein Matching zwischen Requests (Anfragen) und Offers (Angeboten) durchgeführt werden. Dieses Verfahren könnte z.B. in einer Shopping-Anwendung benutzt werden, um im sozialen Netzwerk ein Produktangebot einzustellen. All die bisher genannten Funktionen sollen mithilfe des Service-Paradigmas (FA-13) realisiert werden. Wie in einer serviceorientierten Architektur (Abk. SOA) sollen die Funktionalitäten gekapselt und über wohldefinierte Schnittstellen angeboten werden

17 3 Anforderungsanalyse

(FA-13.1). Die Nutzung der angebotenen Dienste soll transparent zur zugrundeliegenden Implementation erfolgen (FA-13.2). Dienstnutzer und –anbieter sollen mittels asynchroner Nachrichten miteinander kommunizieren und so durch long-lived connections nur lose miteinander gekoppelt sein (FA-13.3). Diese Anforderungen führen zu einer besseren Wiederverwendbarkeit und Interoperabilität (siehe dazu Abschnitt 3.1.3). Die angesprochene Dienstumgebung des Frameworks muss natürlich auch Service Discovery (FA-14) und Service Binding (FA-15) unterstützen. Zuerst müssen die Dienste also durch eine Suche anhand des Dienstnamens auffindbar sein. Das Service Binding beschreibt den Bindevorgang zwischen Dienstnutzer und –anbieter kurz bevor ein Dienstaufruf stattfindet. Weiterhin soll bei der Suche nach verfügbaren Diensten auch immer deren Version berücksichtigt werden (FA-16).

Tabelle 1: Zusammenfassung funktionaler Anforderungen

Beschreibung Priorität FA-1 Einfache Kommunikation hoch FA-2 Verwaltung von Verfügbarkeitsinformationen hoch FA-3 Nutzerkontext verwalten, insbesondere Location hoch FA-4 Nutzung bestehender sozialer Netzwerke hoch FA-5 File Sharing hoch FA-6 Media Sharing hoch FA-7 Gruppenbildung hoch FA-7.1 Lokationsbasierte Gruppenbildung hoch FA-7.2 Dynamische Gruppenbildung niedrig FA-8 Multi-User Chat mittel FA-9 Proximity Detection mittel FA-10 Shared Editing mittel FA-11 Publish-Subscribe-Mechanismus mittel FA-12 Trading-Funktion niedrig FA-13 Service-Paradigma umsetzen hoch Funktionalität kapseln und über wohldefinierte Schnittstellen FA-13.1 hoch anbieten FA-13.2 Transparenz zur zugrundeliegenden Implementation hoch FA-13.3 Asynchronität und lose Kopplung durch Nachrichtenaustausch hoch FA-14 Service Discovery hoch FA-15 Service Binding hoch FA-16 Unterstützung verschiedener Service-Versionen mittel

3.1.2 Geräteanforderungen Bei Geräteanforderungen handelt es sich um die Eigenschaften, die mobile Endgeräte mindestens erfüllen müssen, damit die Ausführung einer mit dem Framework entwickelten Anwendung möglich ist. Da innerhalb des Frameworks auch einige Dienste auf entfernten Servern angeboten werden, muss das Gerät eine konstante Verbindung zum Internet aufweisen (GA-1). Diese Verbindung kann über zellbasierte Telekommunikationsnetze (GSM, UMTS) oder über ortsgebundene Funknetze (WLAN) aufgebaut werden.

18 3 Anforderungsanalyse

Für die Ermittlung des Nutzerkontextes wird auch der aktuelle Aufenthaltsort des Nutzers benötigt. Daher muss das Gerät die geographische Position automatisch ermitteln können (GA-2). Dazu kann sowohl zellbasierte Ortung (Cell ID) als auch satellitengestützte Ortung (GPS, A-GPS) verwendet werden. Die mit dem Framework entwickelten Anwendungen sollen in Java für das Betriebssystem Android implementiert werden. Daher ist es zwingend erforderlich, dass Android mit der dazugehörigen Dalvik Virtual Machine auf dem mobilen Endgerät läuft (GA-3).

Tabelle 2: Zusammenfassung Geräteanforderungen

Beschreibung Priorität GA-1 Konstante Verbindung zum Internet über beliebige Funktechnik hoch Automatische Positionsbestimmung mittels beliebigem GA-2 hoch Ortungsverfahren GA-3 Betriebssystem: Android hoch

3.1.3 Nichtfunktionale Anforderungen Es gibt auch einige nichtfunktionale Anforderungen, die im konzeptionellen Entwurf und in der späteren Implementierung beachtet werden sollen. Das Framework sollte so konzipiert werden, dass neue Komponenten, Funktionen und Features leicht integriert werden können. Erweiterbarkeit ist also eine sehr wichtige Anforderung (NF-1). Das Framework soll wiederverwendbar und austauschbar sein (NF-2). Dies bezieht sich einerseits auf die Dienste, die das Framework den verschiedenen Applikationen leistet. Andererseits sollen aber auch die einzelnen Komponenten innerhalb des Frameworks wiederwendet werden und leicht auszutauschen sein. Weitere Anforderungen ergeben sich durch den Einsatz der mit dem Framework entwickelten Applikationen auf beschränkten mobilen Endgeräten (NF-3). So müssen bspw. schwache Verbindungen und Verbindungsabbrüche berücksichtigt werden (NF-3.1). Die Anwendungen sollten weiterhin auf minimalen Energieverbrauch optimiert sein (NF-3.2). Der Netzwerkverkehr sollte minimiert werden (NF-3.3), denn so lassen sich Wartezeiten verringern und Übertragungskosten senken. Inhalte mit zu vielen Details zur Darstellung auf dem mobilen Endgerät sollten entsprechend adaptiert werden (NF-3.4). Die in Abschnitt 3.1.1 besprochene Dienstumgebung sollte auch einigen nichtfunktionalen Anforderungen genügen. So spielt gerade im Zusammenhang mit den persönlichen Informationen des Nutzerkontextes die Sicherheit eine große Rolle (NF-4). Bevor andere Entitäten diese sensiblen Daten abfragen können, müssen sie sich autorisieren. Die eigentliche Datenübertragung sollte verschlüsselt sein. Die Speicherung der personenbezogenen Daten sollte so weit wie möglich anonym erfolgen (NF-5).

19 3 Anforderungsanalyse

Tabelle 3: Zusammenfassung nichtfunktionaler Anforderungen

Beschreibung Priorität NF-1 Erweiterbarkeit hoch NF-2 Wiederverwendbarkeit, Austauschbarkeit hoch NF-3 Berücksichtigung der Einschränkungen mobiler Endgeräte hoch NF-3.1 schwache Verbindungen, Verbindungsabbrüche mittel NF-3.2 Energieverbrauch hoch NF-3.3 Reduzierung des Netzwerkverkehrs mittel NF-3.4 Adaption niedrig NF-4 Sicherheit (Verschlüsselung, Autorisierung) hoch NF-5 Anonymität mittel

20 4 Dienstumgebungen

4 Dienstumgebungen In diesem Kapitel sollen verschiedene Technologien vorgestellt werden, die für die Bereitstellung der Dienste des zu entwickelnden Frameworks verwendet werden können.

4.1 Extensible Messaging and Presence Protocol Beim Extensible Messaging and Presence Protocol (Abk. XMPP, [xmp11]) handelt es sich um eine auf dem XML-Standard basierende Protokollsammlung für den Austausch von Nachrichten und Presence-Informationen. Ursprünglich hieß das Projekt Jabber und wurde von einer Open-Source Community in den Jahren 1998 bis 2000 entwickelt. 2002 wurde es unter dem Namen XMPP von der Internet Engineering Task Force (Abk. IETF) standardisiert. Seitdem wurden zahlreiche Client- und Server-Implementationen entwickelt. Eine Stärke von XMPP liegt im Bereich Sicherheit, denn der Standard beinhaltet mehrere Verfahren wie Verschlüsselung und Authentifizierung, die dies gewährleisten können. So kann z.B. der Simple Authentication Security Layer (Abk. SASL) für die Authentifizierung und Transport Layer Security (TLS) für die Verschlüsselung benutzt werden. Jeder XMPP-Nutzer verfügt über eine eigene XMPP-Adresse, die ähnlich einer Email- Adresse aufgebaut ist und über die andere Nutzer ihn kontaktieren können. Sie wird auch oft als Jabber-ID (oder kurz JID) bezeichnet und hat die Form Username@XMPP-Server. Auf dem entsprechenden XMPP-Server muss der Nutzer natürlich auch registriert sein und seine Account-Daten hinterlegt haben. XMPP ermöglicht aber auch mehrere gleichzeitige Server-Verbindungen über einen einzigen Account. Um zwischen den verschiedenen Verbindungen zu unterscheiden, wird an die JID durch einen Slash getrennt eine Ressourcen-ID angehangen, wodurch sich Username@XMPP-Server/Resource ergibt. Diese Form wird auch full JID genannt, wohingegen die Variante ohne Ressource bare JID heißt. Jeder XMPP-Nutzer meldet sich zunächst bei seinem XMPP-Server an, woraufhin über eine TCP-Verbindung (Transport Control Protocol) zwei XML-Streams aufgebaut werden – einer für jede Kommunikationsrichtung. Jede Nachricht, die zwischen Client und Server über die geöffneten Streams ausgetauscht wird, ist ein wohlgeformtes XML stanza. Es gibt drei verschiedene Arten von XML stanzas: Message, Presence und Info/Query, die im Folgenden kurz einzeln vorgestellt werden sollen.

4.1.1 Message Das Message stanza ist mit einem Push-Mechanismus zu vergleichen und ermöglicht den Informationsaustausch zwischen XMPP-Entitäten. Das häufigste Einsatzszenario ist das Instant Messaging, wobei ein Message stanza Textnachrichten enthält, die Nutzer einander zukommen lassen wollen. Allerdings wird es auch für Benachrichtigungen über bestimmte Ereignisse verwendet, wie z.B. bei der Erweiterung Publish / Subscribe.

21 4 Dienstumgebungen

4.1.2 Presence Das Presence stanza enthält Verfügbarkeitsinformationen über XMPP-Nutzer. Umgesetzt ist es nach dem Publish-Subscribe-Prinzip, d.h. mehrere Entitäten erhalten Informationen über eine andere Entität, deren Statusinformationen abonniert wurden. Die Statusupdates werden wie in einem einfachen Broadcast-System an alle Abonnenten verteilt. Neben einer textuellen Beschreibung der Verfügbarkeit (z.B. available, do-not-disturb, away) kann ein Presence stanza auch Prioritäten enthalten.

4.1.3 Info / Query Das Info-Query-Verfahren ermöglicht die Realisierung einfacher Request-Response-Dienste innerhalb der XMPP-Architektur. Eine Entität kann darüber wie bei einem Remote Procedure Call eine Anfrage an eine andere Entität stellen, die diese Anfrage dann bearbeitet und mit einem Ergebnis oder einer Fehlermeldung beantwortet. IQs verleihen XMPP den Dienstcharakter, der für die Umsetzung des zu entwickelnden Frameworks benötigt wird. Ein solches IQ stanza hat einen Typ, der kennzeichnet, ob Informationen angefordert (Get) bzw. verändert (Set) werden oder ob es sich um eine positive (Result) oder negative (Error) Antwort handelt. Der Inhalt des IQ ist wohlgeformtes XML und wird Payload genannt. Das Kopfelement des Payload eines IQ stanza heißt auch Child Element des IQ. Der Wert des Attributes xmlns des Child Element wird Namespace des IQ genannt. Unter leeren IQs versteht man solche stanzas, die außer dem Child Element keinen weiteren Payload aufweisen. Abbildung 6 illustriert die eingeführten Begriffe anhand eines Beispiel-IQ.

Abbildung 6: XML-Darstellung eines Beispiel-IQ.

4.1.4 Erweiterbarkeit Eine weitere Stärke von XMPP ist die Erweiterbarkeit. Die drei genannten Stanza-Typen sind so allgemein definiert, dass sie hinsichtlich vieler Aspekte erweitert werden können. Vorgeschlagene Erweiterungen werden als XMPP Extension Protocol (XEP) veröffentlicht und durchlaufen dann einen Standardisierungsprozess in der Community. Innerhalb dieses Prozesses werden die XEPs erst experimental, dann draft und letztlich final genannt. Es existiert momentan eine Vielzahl an XEPs z.B. für Nachrichtenarchivierung, Suche, Microblogging und Roster-Verwaltung. [xmp11]

22 4 Dienstumgebungen

Im Folgenden werden einige XMPP-Erweiterungen beleuchtet, die im Rahmen des zu entwickelnden Frameworks eine wichtige Rolle spielen.

Multi User Chat Der XEP-0045 Multi-User Chat [SA08a] ist ein Protokoll für Chat-Räume, in denen mehrere Benutzer untereinander Textnachrichten austauschen können. Jeder Chat-Raum wird durch eine ID der Form room@service eindeutig identifiziert. Jeder Chat-Teilnehmer wird über room@service/nick identifiziert, wobei nick der Name des Teilnehmers im Chat- Raum ist. Um einen Raum zu betreten oder zu verlassen, werden entsprechende Presence stanzas an diese JID gesendet. Die eigentlichen Nachrichten haben den besonderen Typ groupchat und werden direkt an die Chat-Raum-JID geschickt (siehe Abbildung 7). Im Element ist die Textnachricht zu finden.

Abbildung 7: Senden einer Gruppennachricht.

Alle diese Messages vom Typ groupchat, die von Teilnehmern des Raumes an die Chat- Raum-JID gesendet werden, leitet der Multi-User Chat Service direkt an alle Raumteilnehmer weiter (siehe Abbildung 8). Die ID der Message bleibt gleich. Als Absender wird allerdings die Teilnehmer-JID innerhalb des Chat-Raumes eingesetzt. Außerdem wird die Nachricht auch an den ursprünglichen Absender weitergeleitet, sodass dieser sicherstellen kann, dass die Nachricht den Chat-Raum erreicht hat.

Abbildung 8: Der MUC-Dienst leitet Gruppennachrichten an alle Teilnehmer des Raumes weiter.

Neben dem normalen Nachrichtenaustausch bietet XEP-0045 auch diverse administrative Funktionen. So lassen sich z.B. Moderatoren und Administratoren des Chats bestimmen, die zusätzliche Rechte innehaben. Sie können beispielsweise die maximale Raumgröße festlegen, Teilnehmer vom Chat entfernen und andere Nutzer dazu einladen. Chat-Räume können öffentlich oder nicht sichtbar, persistent oder temporär, passwortgeschützt oder unsicher und nur für Mitglieder oder offen für alle sein. Der Austausch von IQ stanzas zwischen den Teilnehmern eines Multi-User Chat wird von XEP-0045 explizit nicht unterstützt. Ein MUC Service bearbeitet lediglich XMPP- Nachrichten vom Typ Message und Presence, die an die Raum-JID eines Teilnehmers gesendet werden. IQ-Nachrichten werden einfach verworfen. Ist trotzdem der Austausch von

23 4 Dienstumgebungen

IQ-Paketen gewünscht, so schlägt der Standard vor, die echte JID des Teilnehmers vom Chat-Raum zu erfragen und die IQs direkt an diese Adresse zu versenden. Ob diese Auskunft möglich ist, hängt allerdings von den Anonymitätseinstellungen des Chat-Raums ab.

Service Discovery XEP-0030 [HMESA08] ermöglicht das Auffinden von Informationen über bestimmte Entitäten innerhalb des XMPP-Netzwerks. Dazu gehören Aussagen über unterstützte Protokolle, Erweiterungen, Features und angebotene Dienste sowie entsprechende Versionshinweise. Es können aber auch zusätzliche Entitäten, die in irgendeiner Art mit der ursprünglichen Entität verknüpft sind, erfragt werden. Diese Protokollerweiterung spielt in Dienstumgebungen wie dem zu entwickelnden Framework eine große Rolle. Das in Abbildung 9 gezeigte IQ kann beispielsweise für die Abfrage von Informationen zu einem bestimmten XMPP-Nutzer verwendet werden.

Abbildung 9: Service Discovery IQ zur Abfrage von Informationen zu einem XMPP-Nutzer.

Eine Beispielantwort auf dieses IQ vom Typ Get ist in Abbildung 10 dargestellt. Das Antwort-IQ hat den Typ Result und die gleiche ID wie die Anfrage. Weiterhin enthält es Informationen über die Identität des XMPP-Nutzers und die unterstützten Features.

Abbildung 10: Antwort auf ein Service Discovery IQ.

Publish Subscribe XEP-0060 [MSAM10] definiert die Grundfunktionalitäten eines generischen Publish- Subscribe-Dienstes, der in zahlreichen Anwendungsfällen benutzt werden kann, z.B. bei erweiterten Verfügbarkeitsinformationen, Verwaltung von Profilen, Systemen für Netzwerkverwaltung und Auktionsplattformen. Dabei wird das klassische Observer Design Pattern verwendet. Ein Nutzer veröffentlicht bestimmte Informationen und eine Benachrichtigung über dieses Ereignis wird an alle autorisierten Abonnenten zugestellt. Das Protokoll beinhaltet ebenfalls den Ablauf des Abonnierens von solchen Informationsupdates und die dafür benötigte Autorisierung. Der grundsätzliche Ablauf von XEP-0060 soll im Folgenden kurz erläutert werden. Der Subscriber schickt das in Abbildung 11 dargestellte IQ, um Informationsupdates des angegebenen Knotens auf dem Publish Subscribe Server zu abonnieren.

24 4 Dienstumgebungen

Abbildung 11: Subscribe IQ zum Abonnieren von Informations-Updates. Vgl. [MSAM10]

War die Subscription erfolgreich, so erhält der Subscriber ein entsprechendes IQ vom Typ Result. Will nun der Publisher ein Informations-Update veröffentlichen, so schickt er ein entsprechendes Publish IQ wie es in Abbildung 12 gezeigt wird. Dieses wird an den Publish Subscribe Server gesendet und enthält auch den Knoten auf dem es veröffentlicht werden soll. Das Element enthält einen Eintrag, der in diesem Beispiel gemäß Atom Syndication Format aufgebaut ist. Hier sind u.a. ein Titel, eine Zusammenfassung und ein Link angegeben.

Abbildung 12: Publish IQ zum Veröffentlichen eines Informations-Updates. Vgl. [MSAM10]

War das Veröffentlichen des Informationsupdates erfolgreich, erhält der Publisher ein entsprechendes IQ vom Typ Result und alle registrierten Subscriber erhalten eine XMPP Message, die das veröffentlichte Item im Payload enthält (siehe Abbildung 13).

Abbildung 13: Benachrichtigung über ein Informationsupdate. Vgl. [MSAM10]

Im Allgemeinen werden bei der Publish-Subscribe-Erweiterung für alle Benachrichtigungen über Ereignisse immer Messages verwendet. Für Nachrichten, bei denen eine Bestätigung erforderlich ist, werden hingegen die IQs benutzt.

25 4 Dienstumgebungen

Weitere nützliche Erweiterungen Es gibt durchaus noch weitere XMPP-Erweiterungen, die für Mobile Social Software interessant sein könnten. Einige davon sollen im Folgenden kurz aufgelistet werden. In XEP-0080 (User Location, [SAH09]) wird ein Protokoll für den Austausch von diversen geografischen Positionsangaben (z.B. Längen- und Breitengrad, Höhe über NN, Land, Straße, Stadt, Gebäude, Raum) definiert. XEP-0255 (Location Query, [TTS09]) spezifiziert eine XMPP Protokollerweiterung zur Abfrage von Geo-Diensten. Solche Dienste bieten eine Reverse-Geocoding-Funktion, die dem Nutzer anhand von GPS-Koordinaten oder gemessenen Signalstärken zu Access Points weitere textuelle Informationen (z.B. Straße, Stadt) zu seinem Aufenthaltsort liefert. XEP-0128 (Service Discovery Extensions, [SA04]) stellt eine Ergänzung zu dem in diesem Abschnitt vorgestellten Service-Discovery-Mechanismus dar. Damit werden beispielsweise beliebige Zusatzinformationen beim Auffinden von Diensten unterstützt. XEP-0277 (Microblogging over XMPP, [SAH10]) spezifiziert ein Protokoll zum Veröffentlichen und Abonnieren von Posts innerhalb von Microblogging-Umgebungen. In XEP-0286 (XMPP on Mobile Devices, [Cri10]) wird die Nutzung von XMPP auf mobilen Endgeräten innerhalb zellularer Netze (GSM, UMTS) untersucht. Entwicklern mobiler XMPP-Anwendungen gibt dieses Dokument Hinweise wie Energie gespart und Netzwerkverkehr reduziert werden kann. XEP-0286 ist allerdings momentan noch als Experimental gekennzeichnet. D.h. die aufgezeigten Hinweise werden momentan von der Community begutachtet und eventuell verändert und erweitert, bevor ein erster Draft dazu erscheinen wird. Dieser wird dann auch sicherlich einen größeren Umfang als die aktuelle Version aufweisen. Es gibt auch Erweiterungen die festlegen, wie Informationen über Nutzer ausgetauscht werden sollen. So beschreibt XEP-0118 (User Tune, [SA08b]) ein Payload-Format, um zu kommunizieren, welche Musik ein Nutzer zurzeit hört. Mittels des in XEP-0107 (User Mood, [SAM08]) definierten Formats kann ausgetauscht werden, in welcher Stimmungslage sich ein Nutzer gerade befindet.

4.2 Webservices Webservices sind gekapselte Software-Komponenten, die Schnittstellen zum entfernten Aufruf ihrer Funktionen anbieten und die mittels Nachrichtenaustausch lose miteinander gekoppelt werden können. Im Folgenden sollen die Komponenten eines Webservice näher beleuchtet werden. Abbildung 14 demonstriert deren Zusammenspiel und veranschaulicht die allgemeine Architektur.

26 4 Dienstumgebungen

UDDI Verzeichnisdienst

2. Dienst 1. Dienst finden veröffentlichen

3. Dienst aufrufen WSDL Dienstnutzer SOAP Dienstanbieter

Abbildung 14: Architektur von Webservices

Zur Beschreibung eines Webservice wird die Web Services Description Language (Abk. WSDL) verwendet, die 2007 in der zweiten Version vom World Wide Web Consortium (Abk. W3C) standardisiert wurde [CMRW07]. WSDL beschreibt die vom Webservice angebotenen Funktionen, die ausgetauschten Daten mit ihren Datentypen sowie die verwendeten Austauschprotokolle. Mithilfe der WSDL-Angaben ist es dem Dienstnutzer möglich, automatisch den Quellcode zur Zusammensetzung der vom Dienstanbieter gesendeten Objekte zu generieren. Für den eigentlichen Aufruf einer in WSDL gelisteten Funktion wird SOAP (ursprünglich für Simple Object Access Protocol) verwendet. SOAP wurde 2007 in der aktuellen Version in einer W3C-Empfehlung [GHM+07] spezifiziert. Es handelt sich hierbei um ein Protokoll zum Austausch von XML-Nachrichten. Das Senden der Nachrichten kann über verschiedene Transportprotokolle realisiert werden. Die häufigste in der Praxis anzutreffende Kombination ist allerdings mittels HTTP über TCP. Alternativ zu SOAP kann auch der XML-RPC verwendet werden. XML-RPC definiert einen entfernten Prozeduraufruf (engl. Remote Procedure Call) in einem verteilten System, der programmiersprachen- und plattformunabhängig ist. Auch hier werden die übertragenen Daten in XML dargestellt und für den Transport wird HTTP benutzt. Da es für viele Programmiersprachen XML-RPC-Module gibt, ist der Ansatz durchaus interoperabel. Allerdings muss man sich wie beim normalen Remote Procedure Call auf synchrone Kommunikation beschränken, wodurch Flexibilität verloren geht. Um Webservices aufzufinden gibt es den Verzeichnisdienst Universal Description, Discovery and Integration (Abk. UDDI). Dieser Dienst verwaltet drei verschiedene Arten von Informationen. In den White Pages sind Basisinformationen zu finden, die Auskunft über den Dienstanbieter geben. In den Yellow Pages werden die verzeichneten Webservices hinsichtlich ihres Zwecks kategorisiert, um das Finden eines passenden Webservice zu ermöglichen. Die Green Pages enthalten die speziellen Schnittstellenspezifikationen eines jeden Webservice. UDDI wurde ursprünglich als eine zentrale Instanz bei der Verwendung von Webservices geplant. Allerdings hat es sich nie zu einem weltweiten Verzeichnisdienst für Webservices durchgesetzt, sondern wird heutzutage lediglich in kleineren Unternehmenslösungen verwendet.

27 4 Dienstumgebungen

4.3 Fazit In diesem Kapitel wurden zwei mögliche Technologien vorgestellt, die in Dienstumgebungen eingesetzt werden können. Im Rahmen dieser Arbeit wird für die Bereitstellung der Dienste (FA-13) des zu entwickelnden Frameworks XMPP benutzt. Insbesondere der IQ-Mechanismus und die damit ermöglichten Request-Response-Dienste werden Anwendung finden. Für XMPP sprechen weiterhin die Möglichkeit des einfachen Nachrichtenaustauschs zwischen allen Entitäten (FA-1), die Plattformunabhängigkeit und die enge Bindung zwischen den Kommunikationspartnern. Diverse XMPP-Erweiterungen wie der Multi-User Chat (FA-8), der File Transfer (FA-5) und der Publish-Subscribe-Dienst (FA-11) lassen sich in mobilen sozialen Anwendungen einbinden und sollten daher vom Framework unterstützt werden. Die im Kernstandard von XMPP verankerten Sicherheitsaspekte stellen einen weiteren Vorteil dar. So ermöglicht der XMPP Roster bspw. eine Autorisierung von Dienstnutzer und –anbieter vor der eigentlichen Verwendung des Dienstes. Der große Overhead innerhalb von XMPP wirkt sich allerdings nachteilig auf die Kommunikation aus. Diesen Overhead verursacht vor allem die Forderung nach Plattformunabhängigkeit und die dafür eingesetzte Kodierung der Daten im XML-Format. Es handelt sich hierbei allerdings nicht um einen spezifischen Nachteil von XMPP, sondern vielmehr um eine allgemeine Eigenschaft plattformunabhängiger Dienstumgebungen.

28 5 Konzepte

5 Konzepte In den vorigen Kapiteln wurden die Anforderungen an das zu entwickelnde Framework festgelegt und aus den möglichen einsetzbaren Technologien XMPP ausgewählt. In diesem Kapitel sollen nun die Aspekte des konzeptionellen Entwurfs des Frameworks betrachtet werden. Dazu wird anfangs die allgemeine Architektur des Frameworks erläutert. Daraufhin folgt eine detaillierte Betrachtung der einzelnen Komponenten.

5.1 Allgemeine Architektur Die allgemeine Architektur der zu entwickelnden Dienstumgebung wird in Abbildung 15 gezeigt. Der MobilisServer bietet den Client-Applikationen verschiedene Dienste an, z.B. um Mediendaten zu verwalten und zu speichern, um kollaborativ an Dokumenten zu arbeiten und um ortsbasierte Gruppenbildung durchzuführen. All diese Dienste verfügen über eine eigene XMPP-ID und sind über XMPP-Nachrichten anzusprechen. Für die Kommunikation wird die XMPP Client Library Smack eingesetzt. Sie erleichtert das Senden und Empfangen von XMPP-Nachrichten innerhalb von Java-Programmen. Als XMPP-Server kommt der ebenfalls in Java geschriebene und quelloffene Openfire Server von Ignite Realtime zum Einsatz. Es kann aber auch ein beliebiger anderer XMPP-Server verwendet werden.

Mobilis Applications MobilisXHunt MobilisMedia MobilisGroups MobilisTrader MobilisMapDraw MobilisBuddy Mobilis Services Coordinator Service Grouping Service UserContext Service Mobilis Beans

C Content Service P I Mobilis Client Services Repository Service Social Network Service Shared Editing Service

XMPP Services Mobilis Beans MXA FileTransfer Service (Mobilis XMPP Mobilis ServiceDiscovery Service Server On Android) MultiUserChat Service PublishSubscribe Service Openfire XMPP- Smack Smack (XMPP Client Library) XMPP Server XMPP (XMPP Client Library)

Android Java Abbildung 15: Allgemeine Architektur

Um die Kommunikation mithilfe der Smack-Bibliothek auch auf der Android-Plattform zu gewährleisten, müssen gewisse Anpassungen vorgenommen werden. Die Smack- Funktionalität wird daher in den Diensten der Anwendung MXA (Mobilis XMPP on Android) gekapselt. Über eine angebotene AIDL-Schnittstelle (Android Interface Definition Language) greifen die verschiedenen Mobilis-Applikationen auf die Services der MXA- Anwendung zu und können somit mit dem MobilisServer kommunizieren. Das MXA bietet jedoch noch weitere Dienste an: die sogenannten XMPP Services. Diese realisieren bestimmte XMPP-Erweiterungen, z.B. um Dateien zu übertragen, Mehrbenutzer-Chats zu verwalten und um Dienste im XMPP-Netzwerk aufzufinden.

29 5 Konzepte

Die Komponente Mobilis Beans ist eine Sammlung von Strukturen, mithilfe derer die verschiedenen XMPP-Nachrichten erstellt werden können, die zwischen Client und Server ausgetauscht werden. Hier sind also die einzelnen Bestandteile der Protokolle zu finden, in denen die Nutzung der Framework-Dienste festgelegt ist. Daher nutzen Entwickler die Mobilis Beans, um konkrete Anfragen an die Dienste durchzuführen. In der Bibliothek Mobilis Client Services finden Entwickler von Android-Applikationen Dienste, die sie leicht in ihre Anwendungen integrieren können. Dazu gehört auch der Social Network Service, der die Einbindung von externen sozialen Netzwerken erleichtert. Alle angesprochenen Dienste und Komponenten des zu entwickelnden Frameworks sollen im Folgenden detailliert besprochen werden.

Mobilis Applications 5.2 Mobilis Client Services MobilisXHunt MobilisMedia MobilisGroups MobilisTrader MobilisMapDraw MobilisBuddy Mobilis Services Die Mobilis Client Services sollen Coordinator Service Grouping Service UserContext Service Mobilis Beans

C Content Service

Anwendungsentwicklern typische Funktionalitäten P I Mobilis Client Services Repository Service Social Network Service Shared Editing Service mobiler sozialer Anwendungen anbieten. Diese XMPP Services Mobilis Beans MXA FileTransfer Service (Mobilis XMPP Mobilis ServiceDiscovery Service Server Dienste sollen in mehreren Anwendungen On Android) MultiUserChat Service PublishSubscribe Service Openfire XMPP- Smack einsetzbar und leicht integrierbar sein. Daher wird Smack (XMPP Client Library) XMPP Server XMPP (XMPP Client Library) Android Java diese Komponente als Android Library Project umgesetzt. Wie in einer Bibliothek üblich, lassen sich die Mobilis Client Services in anderen Android-Anwendungen referenzieren und nutzen. Es ist momentan der allgemeine Trend zu beobachten, dass soziale Netzwerke sich untereinander immer stärker verknüpfen. Entwicklern, die das Mobilis Framework nutzen, soll es daher auch möglich sein, auf bestehende Systeme zuzugreifen. Außerdem haben neue soziale Netzwerke meist das Problem von geringen Nutzerzahlen. Erst wenn eine bestimmte kritische Masse an Teilnehmern überschritten wird, ist ein echtes Vernetzen unter den Nutzern möglich. Die Einbindung von bestehenden mitgliederstarken Systemen würde helfen, diesem Problem entgegenzuwirken. Aus den genannten Gründen ist die Integration externer sozialer Netzwerke die Hauptaufgabe der Mobilis Client Services. Umgesetzt wird diese Funktionalität innerhalb des Social Network Service. Hier werden die Programmierschnittstellen (engl. application programming interface, kurz API) verschiedener sozialer Netzwerke gekapselt und dem Entwickler an einer zentralen Stelle angeboten. Die allgemeine Architektur der Mobilis Client Services ist in Abbildung 16 dargestellt. Der Social Network Service soll als echter Android Service umgesetzt und seine Funktionalität über eine AIDL-Schnittstelle (Android Interface Definition Language) zur Verfügung stellen. Er verwaltet mehrere Social-Network-Manager-Komponenten, die die jeweiligen API-Funktionen der unterstützten sozialen Netzwerke kapseln. Zu den unterstützten Systemen gehören Foursquare und Gowalla. Dies sind Mobile-Social- Networking-Anwendungen mit Spielcharakter. Nutzer teilen dem System mit, an welchem Ort sie sich gerade befinden, indem sie sich in die entsprechenden Lokalitäten „einchecken―. Dies wird mit Punkten oder bei häufigem Wiederkehren mit einem virtuellen „Bürgermeister―-Titel belohnt. Beide Systeme bieten über ihre APIs die hauptsächlich von

30 5 Konzepte

Nutzern erstellten und gepflegten Daten zu verzeichneten Orten an, z.B. Restaurants, Bars, Clubs, Geschäfte und Sehenswürdigkeiten. Mithilfe des Foursquare Manager und des Gowalla Manager lassen sich diese Orte auch in eigenen Anwendungen verwenden.

Mobilis Client Services

Social Foursquare Network Manager Service Qype OAuth Manager Gowalla Manager

Facebook Manager

Twitter Manager

Abbildung 16: Architekturkonzept der Mobilis Client Services

Qype ist ein Empfehlungsportal, dessen Nutzer verschiedenste Unternehmen, Orte und Dienstleistungen bewerten können. Die dort verzeichneten Einträge haben meist auch eine Referenz auf eine geographische Position und lassen sich über den Qype Manager in eigenen Anwendungen benutzen und z.B. auf einer Karte visualisieren. Facebook Manager und Twitter Manager ermöglichen z.B. das Auslesen von Freundeslisten aus dem entsprechenden sozialen Netzwerk und auch das Schreiben von Pinnwandeinträgen. Um die angesprochenen APIs der verschiedenen Systeme zu nutzen, muss sich die Anwendung dafür autorisieren. Das in den meisten Systemen dafür eingesetzte Verfahren ist OAuth. Ein Endnutzer kann mit diesem Protokoll eine Anwendung autorisieren auf Daten zuzugreifen, die von einem anderen System (in diesem Fall dem sozialen Netzwerk) verwaltet werden, ohne der Anwendung Details seiner Zugangsberechtigung (z.B. Passwörter) preiszugeben. Die OAuth-Komponente verwaltet diesen kompletten Autorisierungsprozess und ist daher ein wichtiger Bestandteil des Social Network Service.

Mobilis Applications 5.3 XMPP Services MobilisXHunt MobilisMedia MobilisGroups MobilisTrader MobilisMapDraw MobilisBuddy Mobilis Services Die XMPP-Services wurden ursprünglich als Teil Coordinator Service Grouping Service UserContext Service Mobilis Beans

C Content Service P der MXA-Anwendung von István Koren und I Mobilis Client Services Repository Service Social Network Service Shared Editing Service

XMPP Services Mobilis Beans Benjamin Söllner entwickelt. Auf alle Dienste MXA FileTransfer Service (Mobilis XMPP Mobilis ServiceDiscovery Service Server On Android) MultiUserChat Service kann über eine zentrale Stelle des MXA PublishSubscribe Service Openfire XMPP- Smack zugegriffen werden. Neben der eigentlichen Smack (XMPP Client Library) XMPP Server XMPP (XMPP Client Library) Android Java XMPP-Kommunikation gehören auch spezielle XMPP-Erweiterungen zu den nutzbaren Diensten. Eine dieser Erweiterungen ist der in

31 5 Konzepte

[SA08a] spezifizierte Multi-User Chat (MUC). Mithilfe des MUC-Dienstes kann man einem solchen Mehrbenutzer-Chat beitreten und ihn verlassen, auf Einladungen reagieren, Informationen zum Chat-Raum abrufen und natürlich auch Nachrichten an alle MUC- Teilnehmer zustellen. Im Rahmen dieser Arbeit soll der MUC Service um zusätzliche Funktionen erweitert werden. Dazu zählen das Abrufen von Informationen eines Chat- Raums und diverse administrative Funktionen, wie z.B. das Erstellen eines neuen MUC, das Entfernen von Nutzern aus dem Raum und das Versenden von Einladungen. Eine komplette Auflistung aller Hauptfunktionen des MUC-Dienstes ist in Abbildung 17 zu finden.

XMPP Services

MultiUserChat Service FileTransfer Service · Chat-Raum betreten und verlassen · Datei senden · Gruppennachricht senden · Für Dateiempfang registrieren · Rauminformationen abrufen und deregistrieren · User-Informationen abrufen · Nickname ändern · Raum erstellen PublishSubscribe Service · Eigene Einladungen verwalten · Abonnement für bestimmte · Einladungen versenden Informationsupdates erstellen · Teilnehmer aus Raum entfernen bzw. kündigen

ServiceDiscovery Service · Discovery-Anfrage an XMPP-Entität schicken

Abbildung 17: Hauptfunktionen der XMPP Services

Der FileTransfer Service wurde im Rahmen der Belegarbeit von Benjamin Söllner [BS09] entwickelt und in die MXA-Applikation integriert. Dem Dienst liegt die XMPP-Erweiterung XEP-0096 namens SI File Transfer [TMMMRE04] zugrunde. Der FileTransfer Service ermöglicht Client-Applikationen das Senden von beliebigen Dateien an andere Nutzer sowie die Verwaltung von eingehenden Dateitransfers. Der ServiceDiscovery Service setzt die XMPP-Erweiterung XEP-0030 um, die in [HMESA08] spezifiziert wurde. Der Dienst ermöglicht es, Anfragen an XMPP-Entitäten zu senden, um in Erfahrung zu bringen, welche Protokolle, Erweiterungen und Features in welcher Version von der entsprechenden Entität unterstützt werden. Innerhalb der Mobilis- Plattform wird dieser Dienst im Zusammenhang mit dem Coordinator Service (siehe 5.4.1) benutzt, damit die Client-Anwendungen alle auf dem MobilisServer aktiven Dienste auffinden können. Der PublishSubscribe Service setzt Teile der XMPP-Erweiterung XEP-0060 um. Diese spezifiziert die Grundfunktionalität eines generischen Publish-Subscribe-Dienstes [MSAM10]. Der Service unterstützt sowohl das Abonnieren von Informationsupdates als auch deren Kündigung.

32 5 Konzepte

5.4 Mobilis Services Mobilis Applications MobilisXHunt MobilisMedia MobilisGroups MobilisTrader Die Mobilis Services sind serverseitige Dienste und MobilisMapDraw MobilisBuddy Mobilis Services Coordinator Service Grouping Service UserContext Service stellen die Hauptkomponente der zu entwickelnden Mobilis Beans

C Content Service P I Mobilis Client Services Repository Service Dienstumgebung dar. Client-Applikationen haben Social Network Service Shared Editing Service XMPP Services Mobilis Beans MXA FileTransfer Service (Mobilis XMPP Mobilis die Möglichkeit über den Coordinator Service ServiceDiscovery Service Server On Android) MultiUserChat Service PublishSubscribe Service Openfire XMPP- Smack Informationen über alle aktiven und aktivierbaren Smack (XMPP Client Library) XMPP Server XMPP (XMPP Client Library) Dienste des MobilisServer zu erlangen. Die Android Java generischen und wiederverwendbaren Dienste sind die Grundlage des MobilisServer. Dazu gehören z.B. Dienste zur Verwaltung und Speicherung von Mediendaten, zur Speicherung von Nutzerkontextinformationen und zur ortsbasierten Gruppenbildung. Ihre Daten speichern sie persistent in einer Datenbank. In einer darüber liegenden Schicht sind anwendungsspezifische Dienste (engl. App-specific Services) zu finden, die allerdings auch Zugriff auf die generischen Dienste haben. Sie vermitteln zwischen den Mobilis Client Applications und den Generic Mobilis Services. Die Client-Applikationen können entweder direkt die generischen Mobilis Services verwenden oder dafür einen eigenen App-specific Service benutzen.

Mobilis Server D S i s e c r o v v Coordinator Service i c e e r

Mobilis y

Client A p S p

MobilisLocPairs Service MobilisBuddy Service e -

Appli- r s v p i c cations e e MobilisXHunt Service MobilisTrader Service c s i f i c

G e

P User Context Media Repository Media Content n P S e e

Service Service Service r M i r c v X

i M c e o

Shared Editing s Grouping Service Database b i l

Openfire Service i s XMPP- Server XMPP Smack (XMPP Client Library)

Abbildung 18: Dienste auf dem MobilisServer

Alle Dienste auf dem MobilisServer verfügen über eine eigene XMPP-ID (JID), über die sie durch Client-Applikationen ansprechbar sind. Daher besitzt jeder Service auch eine eigene XMPP-Verbindung zum XMPP Server. Die Client-Applikationen können die XMPP-IDs bestimmter Dienste beim Coordinator Service erfragen (mehr dazu im folgenden Abschnitt 5.4.1). Die beschriebene Aufsplittung der Funktionalitäten auf mehrere Dienste ermöglicht auch den Einsatz in einem verteilten Szenario. Jeder Service kann so ohne weitere Anpassungen auf einem eigenen Rechner laufen. Abbildung 18 veranschaulicht die Architektur der verschiedenen Dienste auf dem MobilisServer. Im Folgenden sollen konzeptionelle Aspekte der wichtigsten Komponenten betrachtet werden.

33 5 Konzepte

5.4.1 Coordinator Service Der Coordinator Service ist für die Verwaltung aller angebotenen Dienste auf dem MobilisServer zuständig. So gibt er einerseits über einen Service-Discovery-Mechanismus Auskunft über alle aktiven und aktivierbaren Mobilis Services. Andererseits lassen sich mithilfe des Coordinators auch neue Instanzen von Diensten starten.

Service Discovery Die in Abschnitt 4.1.4 vorgestellte XMPP-Erweiterung Service Discovery (XEP-0030, [HMESA08]) unterstützt leider nicht die Angabe von Versionsnummern zu aufgefundenen XMPP-Entitäten. Aus diesem Grund wird für das Auffinden von Diensten innerhalb der Mobilis-Plattform ein eigenes Protokoll verwendet, das allerdings sehr ähnlich zu XEP-0030 aufgebaut ist. Um alle Dienste eines MobilisServer abzufragen, muss an den Coordinator Service ein leeres MobilisServiceDiscoveryIQ gesendet werden (siehe Abbildung 19).

Abbildung 19: Ein leeres MobilisServiceDiscoveryIQ zur Abfrage aller aktiven Dienste.

Abbildung 20: Die Antwort enthält eine Auflistung aller aktiven Mobilis Services.

Abbildung 20 zeigt die Antwort, die der Coordinator Service auf die Anfrage versendet. Im Payload sind alle aktiven Dienste dieses MobilisServer mit ihrem Namespace und ihrer Versionsnummer zu finden. Außerdem wird auf dem MobilisServer zwischen zwei verschiedenen Arten von Diensten unterschieden. Von den einen Services existiert immer nur eine Instanz pro MobilisServer. Diese Dienste sind in der Antwort mit mode=‘single‘ gekennzeichnet. Weiterhin ist zu jedem dieser Dienste die JID

34 5 Konzepte angegeben, damit der Client die Services direkt ansprechen kann. Andere Services können allerdings auch mit mehreren Instanzen pro MobilisServer vorhanden sein und werden mit mode=‘multi‘ gekennzeichnet. Damit nicht jede dieser Instanzen in der Service- Discovery-Antwort aufgelistet werden muss, ist immer nur ein Eintrag pro Service Namespace angegeben, der Auskunft darüber gibt, wie viele Instanzen des Dienstes aktiv sind. Weitere Details zu den zwei verschiedenen Dienstarten folgen im nächsten Abschnitt „Erstellen neuer Dienstinstanzen―. Wird allerdings kein leeres MobilisServiceDiscoveryIQ vom Typ Get an den Coordinator geschickt, sondern sind im Payload noch die Elemente oder angegeben, so wird die Antwort nur Mobilis Services enthalten, die genau diesen Namespace bzw. diese Versionsnummer haben. Dieser Mechanismus erlaubt dem Client also die Suche nach Instanzen eines ganz bestimmten Dienstes. Abbildung 21 und Abbildung 22 zeigen Anfrage- und Antwort-IQ bei solch einer Dienstsuche.

Abbildung 21: MobilisServiceDiscoveryIQ zur Suche nach einem bestimmten Dienst.

Abbildung 22: Die Antwort enthält nur Dienste mit dem gesuchten Namespace bzw. der gesuchten Versionsnummer.

Hier wird ebenfalls ersichtlich, dass der Client mithilfe dieses Mechanismus nun auch die speziellen Instanzen eines zuvor mit mode=‘multi‘ markierten Dienstes erfragen kann. Zu jeder dieser Dienstinstanzen ist dann auch die JID und der bei der Erstellung des Dienstes angegebene Name verzeichnet. Wird die in der Anfrage angegebene Kombination aus Namespace und Versionsnummer des Dienstes nicht gefunden, so wird kein Error IQ, sondern ein leeres Result IQ an den Client zurückgeschickt. Der MobilisServer kann über den Coordinator in einen Wartungsmodus versetzt werden. Dieser existiert, damit die Nutzer keine neuen Dienstinstanzen erstellen können und damit keine neuen Nutzer bestehende Dienste aufrufen können. Der Maintenance Mode sorgt also dafür, dass die Dienste des MobilisServer nicht von neuen Nutzern verwendet werden können, damit er heruntergefahren werden kann.

35 5 Konzepte

Befindet sich der MobilisServer im Wartungsmodus, so antwortet der Coordinator Service anstelle des Result IQs mit einem entsprechenden Error IQ (siehe Tabelle 4).

Tabelle 4: Mögliche Fehlerfälle bei MobilisServiceDiscoveryIQs.

Error type Error condition Error text The MobilisServer is currently in maintenance mode. wait unexpected-request Retry later.

Erstellen neuer Dienstinstanzen Der Coordinator hat zusätzlich die Aufgabe der Verwaltung aller Mobilis Services. Dazu gehört auch das Erstellen der Dienste. Bezüglich des Startzeitpunktes gibt es zwei verschiedene Arten von Mobilis Services. Die einen werden automatisch zusammen mit dem MobilisServer gestartet. Von diesen Diensten ist immer genau eine Instanz auf dem MobilisServer aktiv. Ein Beispiel dafür ist der in diesem Abschnitt beschriebene Coordinator Service selbst. Die andere Art von Diensten wird immer nur bei Bedarf gestartet. Es können auch mehrere Instanzen dieser Dienste auf einem MobilisServer laufen. Beispiele dafür sind die anwendungsspezifischen Dienste XHunt Service und LocPairs Service (siehe 5.4.6). Diese sollen bei Spielbeginn von einem Spieler gestartet und nach Spielende automatisch beendet werden. Um festzulegen zu welchem Zeitpunkt ein Mobilis Service gestartet werden soll, muss in den entsprechenden Einstellungen das Attribut start entweder auf auto oder auf ondemand gesetzt werden. Um eine neue Instanz eines Mobilis Service zu starten, muss der Client ein CreateNewServiceInstanceIQ an den Coordinator senden. Dieses muss im Payload den Namespace des zu startenden Dienstes enthalten (siehe Abbildung 23). Weiterhin kann dort ein Passwort angegeben werden, das im Dienst gespeichert werden soll. Der Dienst kann dieses Passwort zur einfachen Autorisierung von Nutzern verwenden. Der Ersteller muss dann dafür sorgen, dass alle anderen Nutzer das Dienstpasswort erhalten, um den Dienst zu nutzen. Außerdem lässt sich für jeden Dienst optional auch ein Name angeben, der später zur Unterscheidung mehrerer Service-Instanzen verwendet werden kann.

Abbildung 23: CreateNewServiceInstanceIQ zum Erstellen einer neuen Dienstinstanz.

36 5 Konzepte

Im Erfolgsfall wird der Coordinator eine neue Instanz des angegebenen Mobilis Service starten. Dieser verfügt dann natürlich auch über eine eigene XMPP-ID, über die der Dienst angesprochen werden kann. Diese Adresse wird dem Client im Result IQ mitgeteilt (siehe Abbildung 24).

Abbildung 24: Die Antwort enthält die JID des neuen Dienstes.

Der komplette Ablauf des Erstellens und Beendens einer neuen Dienstinstanz kann in Abbildung 25 nochmals nachvollzogen werden.

client@xmpp/MXA mobilis@xmpp/Coordinator

IQ set create & start up mobilis@xmpp/Service IQ result

Client uses the created service

Ready delete from list of services OK

shut down

Abbildung 25: Ablauf beim Erstellen einer neuen Dienstinstanz.

Das hier spezifizierte Protokoll sieht lediglich das Erstellen, aber nicht das Löschen von Service-Instanzen vor. Wird ein Dienst nicht länger benötigt, so stellt er selbst einen Ready- Aufruf an seinen Coordinator, der ihn daraufhin aus der Liste aktiver Dienste löscht. Der Coordinator bestätigt den Vorgang mit einer OK-Nachricht und der Dienst kann heruntergefahren werden. Kann der Coordinator Service den im Payload angegebenen Dienstnamen nicht in seiner Lister aller verfügbaren Dienste finden oder befindet sich der MobilisServer gerade im Wartungsmodus, so antwortet der Coordinator Service anstelle des Result IQs mit einem entsprechenden Error IQ (siehe Tabelle 5).

37 5 Konzepte

Tabelle 5: Mögliche Fehlerfälle bei CreateServiceInstanceIQs.

Error type Error condition Error text modify not-acceptable The given service namespace is unknown. modify not-acceptable The service namespace is not set. The MobilisServer is currently in maintenance mode. wait unexpected-request Retry later.

5.4.2 User Context Service Zum Kontext gehören alle Informationen, die benutzt werden können, um die Situation zu charakterisieren, in der sich eine bestimmte Entität befindet. Meist handelt es sich bei diesen Entitäten um Personen, aber es können auch Orte oder andere Objekte gemeint sein, die relevant für die Interaktion von Nutzer und Anwendung sind. [Dey01] Zum physischen Kontext gehören z.B. Temperatur-, Helligkeits- und Lautstärkewerte aus der Umgebung eines Nutzers. Beispiele für technischen Kontext sind Eigenschaften des Netzwerks (Bandbreite, Fehlerrate, Latenz), zu dem der Nutzer verbunden ist, und auch Informationen zur Leistung des mobilen Endgeräts des Nutzers. Jeder Nutzer hat ebenfalls einen persönlichen Kontext. Dazu zählen z.B. seine Adresse, seine Telefonnummer, sein Terminkalender und seine bevorzugte Zahlungsmethode. Darüber hinaus kann man auch den sozialen Kontext definieren. Hierzu gehören Informationen über nahestehende Personen und Gruppierungen zu denen der Nutzer gehört. (Vgl. [TS11]) Der User Context Service dient zur Verwaltung jeglicher Kontextinformationen der Nutzer innerhalb der Mobilis-Plattform. Er soll so generisch konzipiert sein, dass alle beschriebenen Arten von Kontextinformationen unterstützt werden. Für jeden Nutzer verwaltet der User Context Service einen sogenannten Kontextbaum. In jedem Knoten dieses Baumes sind bestimmte zusammenhängende Kontextinformationen angeordnet. Diese bestehen aus einfachen Schlüssel-Wert-Paaren und einer zusätzlichen Variable, die den Datentyp des Eintrags kennzeichnet. Abbildung 26 zeigt ein Beispiel für solch einen Kontextbaum. In jedem Knoten wird weiterhin gespeichert, wann er das letzte Mal aktualisiert wurde und wie lange die Daten gültig sind. Ist die Gültigkeit der Daten eines Knotens abgelaufen, so müssen diese gelöscht werden. Dieser Mechanismus erlaubt dem Nutzer einen sicheren Umgang mit seinen eventuell sensiblen Kontextdaten. Um einen bestimmten Knoten zu adressieren, müssen nur der Eigentümer des Knotens (z.B. client@xmpp) und der Pfad zum Knoten (z.B. device/display) angegeben werden. In einigen der im Folgenden beschriebenen XMPP-Nachrichten wird auch eine kombinierte Schreibweise (z.B. client@xmpp/device/display) verwendet.

38 5 Konzepte

client@xmpp/MXA

location device tune mood Double : longitude : 13,23 String: manufacturer : „HTC“ String: title : „The Hardest Part“ String: moodValue : „happy“ Double : latitude : 51,72 String: model : „Desire Z“ String: album : „X & Y“ String: text : „Yeah!“ Double : altitude : 123,456 String : artist : „Coldplay“

energy display network Integer: batteryStatus : 15 String: resolution : „480*800“ String: type : „EDGE“ Integer: remainingTime : 220 Double: size : 9,4 Double : bandwith : 89,6 Long: traffic : 4530123

Abbildung 26: Kontextbaum mit Beispieleinträgen

Umgesetzt wird User Context Service nach dem Publish-Subscribe-Prinzip. Der Nutzer veröffentlicht also seine aktuellen Kontextinformationen an einem bestimmten Knoten seines Kontextbaumes. Diese Aktualisierung wird dann vom Dienst an alle registrierten Abonnenten weitergeleitet. Der Nutzer selbst kann für jeden Knoten seines Kontextbaumes einzeln festlegen, wer auf die dort hinterlegten Daten Zugriff hat. Die Interessenten können das Abonnement eines bestimmten Knotens bei dessen Eigentümer beantragen. Teile der Kommunikationsabläufe bei der Nutzung des User Context Service entsprechen der bereits in Abschnitt 4.1.4 angesprochenen XMPP-Standarderweiterung XEP-0060 Publish/Subscribe [MSAM10]. Dies hat den Vorteil, dass nicht nur Mobilis-Applikationen den Dienst nutzen können, sondern auch andere Anwendungen, die ebenfalls nach diesem Standard arbeiten. Eine komplette Umsetzung dieser Erweiterung ist aufgrund des enormen Umfangs im Rahmen dieser Arbeit nicht möglich und auch nicht sinnvoll, denn es wird lediglich ein Ausschnitt von XEP-0060 benötigt, zu dem wiederum eine eigene Protokollerweiterung hinzugefügt werden soll. Es existieren durchaus fertige Implementierungen des XEP-0060, aber diese sind für die Nutzung auf einem XMPP-Server gedacht und daher nicht für den Einsatz im User Context Service geeignet. Im Folgenden wird auf die genauen Abläufe beim Abonnieren (engl. to subscribe), Kündigen (engl. to unsubscribe) und Veröffentlichen (engl. to publish) von Kontextinformationen eingegangen. Dabei wird als Subscriber derjenige Teilnehmer bezeichnet, der stets über Informationsupdates eines anderen Nutzers informiert werden möchte. Dieser andere Nutzer veröffentlicht zu bestimmten Zeitpunkten Informationen bzgl. seines Kontextes und wird daher Publisher genannt.

Subscribe Der allgemeine Ablauf des Subscribe-Verfahrens wird in Abbildung 27 dargestellt. Der Subscriber sendet ein Subscribe IQ vom Typ Set an den User Context Service. Mit diesem IQ äußert er die Absicht, bestimmte Informationsupdates abonnieren zu wollen. Aus Gründen des Datenschutzes muss der Eigentümer der Informationen diesem Abonnement zustimmen. Daher sendet der User Context Service ein AuthorizationIQ vom Typ Get an den

39 5 Konzepte

Publisher, in dem die zu abonnierenden Informationen und der Abonnent angegeben sind. Genehmigt der Publisher das Abonnement, so antwortet er mit einem AuthorizationIQ vom Typ Result. Daraufhin fügt der User Context Service den Subscriber in die Liste der Abonnenten ein und antwortet auf dessen Anfrage mit einem SubscribeIQ vom Typ Result. Außerdem wird dem Subscriber in einer weiteren Nachricht der aktuelle Stand der abonnierten Daten mitgeteilt.

subscriber@xmpp/MXA mobilis@xmpp/Context publisher@xmpp/MXA

Subscribe IQ [set]

Authorization IQ [get]

authorize Authorization IQ [result] subscriber

update Subscribe IQ [result] subscriptions

Message with current status

Abbildung 27: Ablauf des Subscribe-Verfahrens

Als Besonderheit dieses Ablaufes ist zu betonen, dass das SubscribeIQ der XMPP- Erweiterung XEP-0060 genügt. Ein Beispiel IQ vom Typ Set ist in Abbildung 28 dargestellt. Im node-Attribut des subscribe-Elements wird der zu abonnierende Knoten des Kontextbaumes angegeben und das jid-Attribut enthält die XMPP-ID des Publishers.

Abbildung 28: SubscribeIQ vom Typ Set.

Das daraufhin vom User Context Service an den Publisher verschickte AuthorizationIQ vom Typ Get zeigt Abbildung 29.

Abbildung 29: AuthorizationIQ vom Typ Get.

40 5 Konzepte

Genehmigt der Publisher das vom Subscriber erbetene Abonnement, so wird als Bestätigung mit einem leeren AuthorizationIQ vom Typ Result geantwortet (siehe Abbildung 30). Soll die Anfrage jedoch abgelehnt werden, wird ein leeres AuthorizationIQ vom Typ Error gesendet.

Abbildung 30: AuthorizationIQ vom Typ Result.

Erhält der User Context Service die positive Bestätigung vom Publisher, so sendet er das in Abbildung 31 gezeigte SubscribeIQ vom Typ Result sowie die ebenfalls dargestellte Nachricht mit den aktuellen Daten des abonnierten Knotens.

Abbildung 31: SubscribeIQ vom Typ Result und die an den neuen Abonnenten gesendete Nachricht mit dem aktuellen Informationsstand.

Empfängt der User Context Service vom Publisher allerdings keine Antwort innerhalb einer bestimmten Zeitspanne (etwa 20 Sekunden) oder erhält er eine explizite Ablehnung der Anfrage, so sendet der dem Subscriber ein SubscribeIQ vom Typ Error. Wird schon beim Empfang des ersten SubscribeIQ ein Fehler festgestellt, so wird mit einem entsprechenden IQ vom Typ Error geantwortet, das den aufgetretenen Fehler näher beschreibt (siehe Tabelle 6) und das Subscribe-Verfahren wird abgebrochen.

Tabelle 6: Mögliche Fehlerfälle bei SubscribeIQs.

Error type Error condition Error text modify not-acceptable You have to provide a valid node. modify not-acceptable This user is unknown. modify not-acceptable This node is unknown. wait not-authorized User is offline. Authorization not possible. auth not-authorized Your subscription request was denied.

41 5 Konzepte

Unsubscribe Um ein bestehendes Abonnement zu kündigen, muss der Subscriber lediglich ein entsprechendes UnsubscribeIQ vom Typ Set an den User Context Service senden. Dieses genügt ebenfalls der Standarderweiterung XEP-0060 und muss die Daten des bestehenden Abonnements enthalten: die JID des anderen Nutzers und den Pfad im Kontextbaum (siehe Abbildung 32).

Abbildung 32: UnsubscribeIQ vom Typ Set.

Kann die Kündigung des Abonnements erfolgreich im User Context Service durchgeführt werden, so erhält der Subscriber ein leeres UnsubscribeIQ vom Typ Result als Antwort. Der beschriebene Ablauf kann in Abbildung 33 nachvollzogen werden. Hier ist außerdem ersichtlich, dass der Publisher gemäß XEP-0060 nicht über die Veränderung seiner Abonnentenliste benachrichtigt wird.

subscriber@xmpp/MXA mobilis@xmpp/Context publisher@xmpp/MXA

Unsubscribe IQ [set]

update Unsubscribe IQ [result] subscriptions

Abbildung 33: Ablauf des Unsubscribe-Verfahrens.

Ist der Pfad zum Knoten syntaktisch falsch, wurde der Knoten des angegebenen Nutzers nicht gefunden oder existiert kein solches Abonnement, das gekündigt werden kann, so wird ein UnsubscribeIQ vom Typ Error mit entsprechenden Hinweisen zum aufgetretenen Fehler an den Subscriber zurück geschickt (siehe Tabelle 7).

Tabelle 7: Mögliche Fehlerfälle bei UnsubscribeIQs.

Error type Error condition Error text modify not-acceptable You have to provide a valid node. modify not-acceptable This user is unknown. modify not-acceptable This node is unknown. modify not-acceptable You are not subscribed to that node.

42 5 Konzepte

Publish Der allgemeine Ablauf des Publish-Verfahrens wird in Abbildung 34 dargestellt. Der Publisher sendet ein PublishIQ vom Typ Set an den User Context Service. Dieser erstellt einen neuen Knoten im Kontextbaum mit den übermittelten Informationen oder aktualisiert einen bestehenden Knoten. Alle Abonnenten des entsprechenden Knotens (in diesem Fall nur subscriber@xmpp/MXA) werden über die Änderung des Knotens durch eine entsprechende Nachricht informiert. Der Publisher selbst erhält zur Bestätigung ein leeres PublishIQ vom Typ Result.

subscriber@xmpp/MXA mobilis@xmpp/Context publisher@xmpp/MXA

Publish IQ [set]

update node Message with information update Publish IQ [result]

Abbildung 34: Ablauf des Publish-Verfahrens.

Der Aufbau eines PublishIQ vom Typ Set wird in Abbildung 35 demonstriert. Unterhalb des angegebenen Knotens können beliebig viele contextitem-Elemente angefügt werden.

Abbildung 35: PublishIQ vom Typ Set.

Zur Benachrichtigung aller eingetragenen Abonnenten wird gemäß XEP-0060 statt eines Info/Query-Pakets eine normale XMPP Message verwendet. Dies hat den Vorteil, dass solche Benachrichtigungen nicht mehr bestätigt werden müssen, denn deren erfolgreiche Zustellung ist nicht so wichtig wie die der Info/Query-Pakete. Somit wird der Netzwerkverkehr reduziert. Abbildung 36 zeigt die XMPP Message, die an alle Abonnenten des veränderten Knotens versendet wird.

Abbildung 36: Die XMPP Message, mit der alle Abonnenten über das Update informiert werden.

43 5 Konzepte

Beim Veröffentlichen eines Informationsupdates mittels PublishIQ kann nur der eine in Tabelle 8 beschriebene Fehlerfall auftreten. Ein entsprechendes IQ vom Typ Error wird dann zurückgeschickt.

Tabelle 8: Mögliche Fehlerfälle bei PublishIQs.

Error type Error condition Error text modify not-acceptable You have to provide a valid node.

Eine Besonderheit des User Context Service ist die Unterstützung bestimmter bereits in Abschnitt 4.1.4 genannter XMPP-Standarderweiterungen. Die XEPs 0080, 0107 und 0118 stellen Erweiterungen dar, um bestimmte Kontextinformationen des Nutzers in standardisierter Form zu übertragen.

location String : country : Germany tune Double : latitude : 51.05 String : artist : „Coldplay“ mood String : city : Dresden Integer : length : 265 String: moodValue : „hungry“ Double : longitude : 13.74 String: title : „The Hardest Part“ String: text : „Would kill for a steak...“ Integer : accuracy : 30

client@xmpp/MXA

Abbildung 37: Die Informationen aus bestimmten Nachrichtenarten werden vom User Context Service automatisch in die passenden Knoten des Context Tree gespeichert.

XEP-0080 User Location definiert ein Nachrichtenformat zum Austausch von Informationen zum aktuellen Aufenthaltsort des Nutzers. Im XEP-0107 User Mood [SAM08] wird ein Payload-Format definiert, mit dem die aktuelle Stimmungslage eines Nutzers ausgedrückt werden kann. XEP-0118 User Tune [SA08b] kann genutzt werden, um zu kommunizieren, welche Musik ein Nutzer zurzeit hört. Der User Context Service erkennt nun also automatisch diese bestimmten Nachrichtenarten anhand der entsprechenden Namespaces und speichert die übertragenen

44 5 Konzepte

Kontextinformationen automatisch in den dafür vorgesehenen Knoten des Nutzerbaumes (siehe Abbildung 37). Die Unterstützung dieser Zusatzfeatures hat den Vorteil, dass der User Context Service nicht nur von entsprechenden Mobilis-Anwendungen verwendet werden kann. Denn so lässt sich der Dienst auch von externen Programmen, die ebenfalls diese XEPs unterstützen, ansprechen und benutzen (z.B. Musik-Player, GPS-Tracker, Instant Messenger).

5.4.3 Grouping Service Der Grouping Service wurde im Rahmen der Belegarbeit „Mobile Social Networking― [RL10] konzipiert und implementiert. Dahinter steckt die Idee der Location Based Group Formation, wonach ein gewisser Ortsbezug in die sozialen Netzwerke und speziell in den Gruppenverwaltungsprozess integriert wird. Der Aufenthaltsort der Nutzer soll als zusätzliche Kontextinformation im Netzwerk verwendet werden können. Die dem Grouping Service zugehörige Mobilis-Applikation ist MobilisGroups. Der Dienst ist jedoch generisch und kann problemlos auch von anderen Anwendungen verwendet werden. Er ermöglicht die Erstellung und Verwaltung von ortsbezogenen Gruppen mit bestimmten örtlichen und zeitlichen Restriktionen bezüglich der Sichtbarkeit der Gruppen und bezüglich der Möglichkeit des Gruppenbeitritts. Einem Nutzer ist es also nicht überall und zu jeder Zeit möglich, alle Gruppen zu sehen und ihnen beizutreten. Vielmehr ist die Gruppenanzeige abhängig von seinen aktuellen Kontextinformationen. Im Folgenden sollen kurz die Grundfunktionen des Grouping Service erklärt werden. Wie in jedem sozialen Netzwerk, lassen sich auch hier Informationen über die eigene Person hinterlegen, die dann von anderen Nutzern abgefragt werden können. Der Grouping Service unterstützt also den Austausch von Mitgliederinformationen. Dazu wird das GroupMemberInfoIQ verwendet. Die nächste Grundfunktion ist natürlich das Erstellen und Aktualisieren der ortsbezogenen Gruppen. In dem dafür benutzten GroupCreateIQ können alle wichtigen Daten der Gruppe eingetragen werden, z.B. Gruppenname, -beschreibung, -homepage, örtliche und zeitliche Restriktionen sowie Privacy-Informationen. Diese detaillierten Gruppeninformationen lassen sich mittels des GroupInfoIQ abrufen. Löschen kann man Gruppen nur, wenn man die entsprechenden Rechte dazu hat, d.h. wenn man als Gruppengründer oder Administrator eingetragen ist. Dazu wird das GroupDeleteIQ verwendet. Beim Erstellen und Aktualisieren von Gruppen ist einstellbar, dass nur Personen mit expliziter Einladung eines Gruppenmitglieds der Gruppe beitreten dürfen. Ist diese Restriktion aktiviert, so muss die JID des Senders in der Liste aller eingeladenen JIDs der Gruppe vorhanden sein. Ansonsten kommt es beim Beitreten zu einem Fehler. Mittels GroupInviteIQ kann ein Gruppenmitglied die JIDs seiner Freunde zu dieser Liste hinzufügen. Jeder Nutzer muss natürlich in der Lage sein, eine Gruppenbeitrittsanfrage zu stellen. Diese Anfrage geschieht durch Senden eines GroupJoinIQ. Mitglieder einer Gruppe haben

45 5 Konzepte jederzeit das Recht, ihre Gruppenmitgliedschaft zu kündigen. Durchgeführt wird dies mithilfe eines GroupLeaveIQ. Ein weiterer wichtiger Bestandteil der Kommunikation ist das GroupQueryIQ, denn es ermöglicht die Umgebungssuche von Gruppen. Da dies wohl die häufigste Anfrage an den Grouping Service ist, wird im Folgenden kurz auf die Kommunikationsabläufe eingegangen. Damit die örtlichen Restriktionen umgesetzt werden können, muss der Client bei jeder Gruppensuche seine eigene Position übertragen. Damit aber nicht immer alle Ergebnisse, sondern nur die für den Nutzer relevanten Daten übertragen werden müssen, kann ein bestimmtes Suchgebiet festgelegt werden. Um dies zu erreichen, werden in den Payload eines GroupQueryIQ vom Typ Get (siehe Abbildung 38) die entsprechenden Latitude- und Longitude-Grenzen eingefügt.

Abbildung 38: GroupQueryIQ vom Typ Get.

Das im Erfolgsfall vom Grouping Service an den Client gesendete IQ vom Typ Result kann mehrere Elemente enthalten, die jeweils einen Treffer bezüglich der Anfrage repräsentieren (siehe Abbildung 39).

Abbildung 39: GroupQueryIQ vom Typ Result.

Eine mögliche Erweiterung des Grouping Service ist das dynamische Gruppenmanagement. Hierbei sendet der Client in regelmäßigen Abständen Location Updates an den Grouping Service, welcher den Nutzer dann automatisch in die für ihn an dieser Position verfügbaren Gruppen einträgt. Der Nutzer müsste sich also in solch einem Szenario nicht mehr selbst um Gruppenbeitritte kümmern. Die Verwaltung der eigenen Gruppenmitgliedschaften geschieht dann dynamisch aufgrund der aktuellen Nutzerposition.

46 5 Konzepte

5.4.4 Repository Service und Content Service Repository Service und Content Service wurden im Rahmen der Belegarbeit [BS09] von Benjamin Söllner konzipiert und entwickelt. Innerhalb der Mobilis-Plattform werden die beiden Dienste bisher nur von MobilisMedia verwendet. Sie sind jedoch durchaus zur Wiederverwendung konzipiert. Die Aufgabe der beiden Services ist das Media Sharing und speziell das Verteilen von Fotos mit hinterlegten Informationen zum Aufnahmeort. Die Anlaufstelle für den Client stellt der Repository Service dar. Hier werden u.a. alle Metadaten zu den Mediendaten verwaltet. Die eigentliche Speicherung der Mediendateien erfolgt allerdings im Content Service. Welche Dienstprimitive beide Services anbieten und welche IQs dabei ausgetauscht werden, ist in Abbildung 40 dargestellt.

Abbildung 40: Aufrufabläufe von Repository Service und Content Service in verschiedenen Anwendungsfällen. Quelle: [BS09]

Zu Beginn muss sich der Content Service beim Repository Service registrieren. Ist diese Bindung erfolgt, kann der Client seine Anfragen an den Repository Service stellen. So sind beispielsweise das Herunterladen, Hochladen und Löschen von Bildern sowie das Browsen durch die Bilderdatenbank möglich. Für den eigentlichen Austausch der Fotos wird der SI File Transfer [TMMMRE04] gemäß XEP-0096 verwendet. Abbildung 41 veranschaulicht grob, welche IQs mit welchem Child Element von beiden Services benutzt werden und welche Informationen im Payload aufzufinden sind.

47 5 Konzepte

Abbildung 41: Ausgetauschte IQs bei Repository Service und Content Service. Quelle: [BS09]

5.4.5 Collaborative Editing Service Der Collaborative Editing Service wurde im Rahmen der Belegarbeit [DH09] von Dirk Hering konzipiert und umgesetzt. Dieser serverseitige Dienst ermöglicht das gemeinsame und gleichzeitige Bearbeiten von Daten durch mehrere räumlich verteilte Personen, das auch Collaborative Editing oder Shared Editing genannt wird. Das Ziel ist es, dass alle Mitglieder einer Collaborative Editing Session sowohl eigene Änderungen an einer Datei als auch die der anderen Teilnehmer sofort sehen können. Für Desktop-Umgebungen gibt es bereits zahlreiche solche Anwendungen aus dem eCollaboration-Bereich. Aber Kollaboration ist auch ein wichtiger Teil von Mobile Social Software und daher liefert der Collaborative Editing Service einen großen Mehrwert für das Mobilis Framework. Der Service wurde besonders unter dem Aspekt konzipiert, für möglichst viele Dokumenttypen und verschiedene Anwendungen einsetzbar zu sein. Dazu sollten keinerlei zusätzliche Anpassungen nötig sein. Dieser Anforderung wird der Dienst gerecht, da er beliebige gemäß dem XML-Standard formatierte Dokumente unterstützt. In der angesprochenen Arbeit wird außerdem untersucht, welche Ansätze sich zur Nebenläufigkeitskontrolle für Real-time Collaborative Editing auf mobilen Endgeräten eignen. Letztlich wurde der Dienst mithilfe des Collaborative Editing Framework for XML (Abk. CEFX, [AG07]) umgesetzt. CEFX gestattet abhängig von den Anforderungen der zu entwickelnden kollaborativen Applikation den Einsatz unterschiedlicher Mechanismen für die Nebenläufigkeitskontrolle, Awareness und das Sperren. CEFX wurde in Java implementiert, aber Anpassungen an die Android-Plattform waren trotzdem notwendig. Die Architektur wird in Abbildung 42 veranschaulicht und lässt sich wie folgt beschreiben: Auf jedem Client ist die benötigte Shared-Editing-Applikation installiert und jeder Teilnehmer verfügt über eine eigene Kopie des kollaborativ bearbeiteten XML-Dokuments, auf der alle lokal ausgeführten Operationen sofort durchgeführt werden. Um alle

48 5 Konzepte

Dokumentenkopien aktuell zu halten, wird jede von einem Teilnehmer ausgeführte Operation an alle anderen Teilnehmer gesendet. Für diesen Zweck wird für jede Collaboration Session ein XMPP Multi User Chat (siehe Abschnitt 4.1.4) angelegt, sodass Änderungen automatisch von allen Sitzungsteilnehmern erhalten werden und die zu übertragende Datenmenge gering bleibt.

Abbildung 42: Überblick über eine Collaboration Session. Quelle: [DH09]

Der Collaborative Editing Service übernimmt die Rolle eines Client und erhält damit ebenso alle Änderungen am Dokument. Vor jeder Ausführung einer Operation werden mögliche Konflikte von jedem Client selbstständig erkannt und durch die Nebenläufigkeitskontrolle automatisch aufgelöst. Der Collaborative Editing Service hat also nicht die Aufgabe der zentralen Koordination aller Operationen, sondern er verwaltet vielmehr eine eigene Kopie des kollaborativ bearbeiteten Dokuments, um dieses an Teilnehmer zu versenden, die der Collaboration Session später beitreten wollen (Late-Join-Problematik). Der Dienst unterstützt weiterhin mehrere Collaboration Sessions zur gleichen Zeit. Sessions können für hochgeladene und bereits beim Dienst hinterlegte XML-Dokumente angelegt werden. Clients können Sessions beitreten und auch verlassen. Als Einsatzzweck des Collaborative Editing Service wird in [DH09] besonders auf das Collaborative Drawing, also das gemeinsame Zeichnen auf einer Karte oder einem Whiteboard, eingegangen. Nutzungsszenarien sind dabei sowohl im Tourismusbereich (Absprachen innerhalb einer Reisegruppe) als auch in Notfallsituationen (Koordination eines Einsatzteams an einer Unfallstelle) zu finden.

5.4.6 Anwendungsspezifische Services Wie der Name schon verrät, stellen die anwendungsspezifischen Services sehr spezielle und nicht wiederverwendbare Dienste für bestimmte Mobilis-Applikationen bereit. Sie dienen als Anlaufstelle der Mobilis-Client-Applikationen und enthalten also deren serverseitige Anwendungslogik. Sie haben allerdings auch Zugriff auf die generischen Mobilis Services und können so auch zwischen diesen und den Applikationen vermitteln. So könnte ein Dienst für Proximity Detection (FA-9) beispielsweise die Funktionalität des generischen User Context Service verwenden, um die Position zweier Nutzer zu verfolgen.

49 5 Konzepte

Unterschreitet deren Entfernung eine vorher festgelegte Grenze, so wird eine entsprechende Benachrichtigung an beide Nutzer gesendet. Auch die bereits in Anforderung FA-12 angesprochene Trading-Funktionalität kann mithilfe des User Context Service umgesetzt werden. Nutzer könnten an vorher festgelegten Knoten ihres Context Tree bestimmte Requests (Anfragen) und Offers (Angebote) mit beliebigen zusätzlichen Informationen wie Verkaufsort oder Preisvorstellungen veröffentlichen. Ein entsprechender Trading Service besäße ein Abonnement dieser Knoten und könnte somit das Matching von Requests und Offers durchführen und die Nutzer bei gefundenen Übereinstimmungen über für sie interessante Inserate benachrichtigen. Diese beiden angesprochenen Beispieldienste, Proximity Detection und Trading, wurden bereits zuvor innerhalb des Mobilis-Projekts umgesetzt. Allerdings erfolgte deren Konzeption ohne jegliche Wiederverwendung generischer Komponenten, da die Generic Mobilis Services zu diesem Zeitpunkt noch nicht existierten. Beispiele für weitere anwendungsspezifische Services sind der XHunt Service und der LocPairs Service. Beide Dienste stellen die serverseitige Anwendungslogik von Location Based Games bereit, die in Komplexpraktika am Lehrstuhl Rechnernetze der TU Dresden entstanden sind. Die serverseitigen Komponenten beider Spiele werden im Rahmen dieser Arbeit und in Zusammenarbeit mit deren Entwicklern in die Dienstarchitektur des MobilisServer überführt. MobilisXHunt (siehe 7.1.5) stellt eine Abwandlung des Brettspiels „Scotland Yard – Auf der Jagd nach Mister X― von Ravensburger in die Realität dar. Das heißt, die Spieler, die in mehrere Agenten und einen Mister X aufgeteilt werden, begeben sich mit Smartphones ausgestattet auf die Jagd in einer realen Stadt und nutzen echte Verkehrsmittel des öffentlichen Personennahverkehrs, um von einem Knotenpunkt des Liniennetzes zum nächsten zu gelangen. MobilisLocPairs (siehe 7.1.6) ist eine Umsetzung des bekannten Kinderspiels Memory (im englischsprachigen Raum Pairs genannt) als Location Based Indoor Game. Die Spieler bewegen sich innerhalb eines Gebäudes, um an bestimmten Orten angebrachte QR-Codes zu scannen. Dieser Scan-Vorgang entspricht dem Umdrehen einer Karte im Memory-Spiel. MobilisLocPairs ist wie das Originalspiel rundenbasiert, aber es wird in Zweierteams gespielt. Neben dem eigentlichen Spiel liefert LocPairs noch folgenden Zusatznutzen: Bei jedem Scan-Vorgang wird außerdem ein Fingerprint aller sichtbaren WLAN Accesspoints mit deren Signalstärken angelegt. Diese Daten können später verwendet werden, um die Indoor-Ortung zu verbessern. Im Falle von MobilisLocPairs wurde neben dem Dienst für die Logik des Spielablaufs auch noch ein zweiter Dienst umgesetzt. Dieser ist dafür zuständig, die Ergebnisse der in den Spielen durchgeführten WLAN-Messungen externen Anwendungen zur Verfügung zu stellen. Von diesem Dienst existiert pro MobilisServer daher auch immer nur eine Instanz. Einerseits startet der Dienst einen Webserver und erlaubt somit den komfortablen Zugriff auf die Messdaten über ein Web Interface. Andererseits wäre die Auslieferung der Daten ebenso effizient über XMPP möglich, denn die Messungen werden sowieso bereits in XML- Strukturen gespeichert.

50 5 Konzepte

Die Ersetzung der Serverkomponenten beider Spiele durch Dienste im MobilisServer hat zuallererst den Vorteil, dass sich mithilfe der in Abschnitt 5.4.1 vorgestellten Mechanismen des Coordinator Service leicht neue Instanzen der Dienste erstellen und bestehende Instanzen verwalten lassen. Für das gleichzeitige Ablaufen mehrerer Spiele ist also gesorgt. Weiterhin wäre auch bei diesen Diensten eine Nutzung der bereits bestehenden wiederverwendbaren Mobilis Services denkbar. Im Bereich der Location Based Games spielen die Aufenthaltsorte der Spieler natürlich die wichtigste Rolle. Diese und andere Informationen könnten die entsprechenden Gaming-Dienste auch leicht über den generischen User Context Service erhalten.

Mobilis Applications 5.5 Mobilis Beans MobilisXHunt MobilisMedia MobilisGroups MobilisTrader MobilisMapDraw MobilisBuddy Mobilis Services Die Kommunikation innerhalb der Mobilis- Coordinator Service Grouping Service UserContext Service Mobilis Beans

C Content Service

Plattform erfolgt wie bereits detailliert besprochen P I Mobilis Client Services Repository Service Social Network Service Shared Editing Service

über XMPP und insbesondere Info/Query- XMPP Services Mobilis Beans MXA FileTransfer Service (Mobilis XMPP Mobilis ServiceDiscovery Service Server Nachrichten. Damit Entwickler von Mobilis- On Android) MultiUserChat Service PublishSubscribe Service Openfire XMPP- Smack Anwendungen nicht jedes Mal erneut das Erstellen Smack (XMPP Client Library) XMPP Server XMPP (XMPP Client Library) Android Java und Auslesen von IQ-Nachrichten selbst umsetzen müssen, wurde die Komponente Mobilis Beans angelegt. Es handelt sich dabei um eine Sammlung von Strukturen, mithilfe derer die verschiedenen XMPP-Nachrichten erstellt werden können, die zwischen Client und Server ausgetauscht werden. Hier sind also die einzelnen Bestandteile der Protokolle zu finden, in denen die Nutzung der Framework- Dienste festgelegt ist. Anwendungsentwickler können die Mobilis Beans nutzen, um konkrete Anfragen an die Dienste durchzuführen. Der Hauptvorteil liegt in der Wiederverwendung von Mobilis Beans in allen Server- und Client-Komponenten. Beide Teile einer Mobilis-Applikation, also der serverseitige Dienst und die clientseitige Anwendung, referenzieren das Mobilis-Beans-Projekt und benutzen einen Teil davon für die Kommunikation untereinander. So ist außerdem sichergestellt, dass beide Seiten die gleiche IQ-Syntax verwenden. Jedes Bean repräsentiert ein bestimmtes XMPP IQ. Es enthält Methoden zur Konvertierung der Bean in ein XMPP IQ, um es zu senden. Außerdem gibt es Methoden zum Parsen einkommender XMPP IQs in das entsprechende Bean (siehe Abbildung 43). Weiterhin verfügt es über IQ-typische Attribute wie Sender und Empfänger, Namespace und Child Element sowie Angaben über den aufgetretenen Fehler, falls es sich um ein IQ vom Typ Error handelt.

XMPP Bean toXML() - type, id, sender, receiver XMPP IQ - namespace, childElement - error information (type, condition, text) fromXML()

Abbildung 43: Übersicht der wichtigsten Attribute und Methoden von Mobilis Beans.

51 5 Konzepte

Ein weiterer Vorteil ist letztlich, dass die Konvertierungsregeln für die Umwandlung von Bean in IQ und zurück an einer zentralen Stelle und übersichtlich innerhalb einer Teilkomponente zu finden sind. Abbildung 44 gibt einen groben Überblick der einzelnen Komponenten innerhalb von Mobilis Beans. XMPPInfo repräsentiert einen beliebigen Ausschnitt von wohlgeformtem XML mit Namespace und Child Element und bietet daher entsprechende Methoden zur Konvertierung an. XMPPBean ist eine spezielle XMPPInfo, denn es hat als weitere Daten z.B. Sender und Empfänger. Im Payload eines XMPPBean können aber beliebig viele XMPPInfos auftreten. Ein Beispiel dafür ist das ConditionInfo-Element, das im Allgemeinen dazu benutzt werden kann, komplexe Bedingungen mithilfe von Schlüssel-Wert-Paaren und Operatoren auszudrücken. Die einzelnen Mobilis-Anwendungen haben innerhalb von Mobilis Beans je ein eigenes Unterpaket für all ihre eigenen Beans, die von XMPPBean abgeleitet werden. Als Beispiel dafür sind in Abbildung 44 die Pakete von MobilisMedia, MobilisXHunt, MobilisGroups und MobilisLocPairs angedeutet. Dies ist jedoch nur ein Ausschnitt der applikationsspezifischen Beans. Außerdem gibt es noch bestimmte Beans, um die generischen Mobilis Services wie z.B. den Coordinator Service und den UserContext Service anzusprechen.

General Mobilis Beans de.tudresden.inf.rn.mobilis.xmpp.beans XMPPInfo XMPPBean + fromXML() ConditionInfo - type, id, sender, receiver + toXML() key, operator, value - namespace, childElement + getChildElement() - error information (type, condition, text) + getNamespace()

Application-specific Mobilis Beans

MobilisMedia MobilisXHunt de.tudresden.inf.rn.mobilis.xmpp.beans.media de.tudresden.inf.rn.mobilis.xmpp.beans.xhunt

ContentTransferBean InitGameBean

MobilisGroups MobilisLocPairs de.tudresden.inf.rn.mobilis.xmpp.beans.groups de.tudresden.inf.rn.mobilis.xmpp.beans.locpairs

GroupQueryBean ShowCardBean

Abbildung 44: Übersicht über Komponenten innerhalb von Mobilis Beans.

Wie bereits erwähnt, werden die Mobilis Beans sowohl auf der Server- also auch auf der Client-Seite benutzt. Um diese Wiederverwendung zu ermöglichen, wurden in [BS09] Adapterschichten konzipiert. Diese Schichten heißen Bean MXA Glue und Bean Smack Glue. Auf dem Client müssen die XMPPIQs aus dem MXA in Mobilis Beans umgewandelt werden. Der Parceller verfügt über solche Konvertierungsmethoden, die allerdings erst

52 5 Konzepte ausgeführt werden können, nachdem ein Prototyp eines entsprechenden Mobilis Beans registriert wurde. Auf der Server-Seite wird direkt die XMPP Client Library Smack verwendet, die die Info/Query stanzas in einer eigenen Java-Klasse verwaltet. Die Umwandlung eines Smack IQ in eine Mobilis Bean erfolgt mithilfe des BeanIQAdapter. Die Deserialisierung von IQ stanzas wird in Smack mithilfe von entsprechenden Provider-Klassen durchgeführt. Diese werden im BeanProviderAdapter an die Mobilis Beans adaptiert. Um einkommende IQ stanzas entsprechend ihres Namespace und Child Element zu kategorisieren und zuzuordnen, verwendet Smack PacketFilter-Klassen. Diese Funktionalität übernimmt im Mobilis-Beans- Kontext der BeanFilterAdapter. Die Zusammenhänge der Komponenten der Adapterschichten auf Server- und Client-Seite sind in Abbildung 45 dargestellt. Mobilis Beans Mobilis Beans e

u A

l BeanFilterAdapter

X Parceller G + accept( packet )

e + registerXMPPBean( prototype ) M k

u l + unregisterXMPPBean( prototype ) c n a G a + convertXMPPBeanToIQ( xmppBean ) BeanProviderAdapter e + convertXMPPIQToBean( xmppIQ) m

S + parseIQ() B

n a

e BeanIQAdapter MXA XMPPIQ B Mobilis XMPP On Android from, to, type, payload, namespace, ... Smack IQ XMPP Client Library Smack (XMPP Client Library) from, to, type, ...

Android Java

Abbildung 45: Adapterschichten in Android und Java zur Nutzung der gleichen Mobilis Beans.

53 6 Implementierung

6 Implementierung Dieses Kapitel behandelt verschiedene Aspekte der Umsetzung der im vorigen Kapitel vorgestellten Konzepte, sodass letztlich das Mobilis Framework entstehen konnte. Anfangs wird ein Überblick über die verschiedenen Pakete des Mobilis-Projektes gegeben. Danach folgen implementationsspezifische Details zu ausgewählten Teilprojekten, die im Rahmen dieser Arbeit bearbeitet wurden.

6.1 Paketstruktur Aufgrund der Vielfalt der bisher für die Mobilis-Plattform umgesetzten Features besteht Mobilis aus mehreren Teilprojekten. Die Zusammenhänge dieser Projekte sind für neue Entwickler meist schwer nachzuvollziehen und sollen daher in diesem Abschnitt erläutert werden.

MobilisXHunt_JavaClient MobilisXMPP smack MobilisXHunt_Android xmlpull

MobilisLocPairs MXA smack

MobilisMedia creates

MXAClient.jar MobilisGroups MobilisServer

xmlpull Mobilis Context hibernate smack

MobilisClient Magnetizer Services gson signpost MobilisMapDraw AndroidCEFX Common SNSExample smack xmlpull

KMLSimulator smack Mobilis MobilisBuddy Common

shared component external library Android App Java application

Abbildung 46: Paketübersicht des kompletten Mobilis-Projektes.

54 6 Implementierung

Abbildung 46 zeigt eine Übersicht aller im Mobilis-Projekt vorhandenen Pakete und deren Abhängigkeiten, so wie sie auch im SVN Repository [MP11] zu finden sind. Alle Komponenten wurden in der Programmiersprache Java implementiert. Generell kann bei den vorhandenen Komponenten zwischen normalen Java Anwendungen, Android Applications und gemeinsam verwendeten Komponenten unterschieden werden. Weiterhin wird illustriert, welche Komponenten welche externen Bibliotheken verwenden. Zu diesen Bibliotheken gehören Smack [IR11] für die XMPP-Kommunikation, GSON [GG10] zum Parsen von JSON-Strings, XML Pull Parser [AS05] zum Parsen von XML-Strings sowie OAuth Signpost [OS10] zum Signieren von HTTP-Anfragen. Wie schon im konzeptionellen Teil dieser Arbeit herausgestellt wurde, stellt der MobilisServer mit seinen generisch nutzbaren Diensten den zentralen Punkt des Frameworks dar. Die Android Applikationen kommunizieren mit diesen Mobilis Services über XMPP und nutzen dafür die Anwendung MXA (Abk. für Mobilis XMPP on Android), die ebenfalls installiert sein muss. MXA stellt die Bibliothek MXAClient.jar bereit, die die Applikationen importieren, um auf das MXA zuzugreifen. Dieser Zugriff erfolgt über Interprozesskommunikation, denn MXA bietet eine entsprechende AIDL-Schnittstelle (Abk. für Android Interface Definition Language) an. In der Komponente MobilisXMPP sind die in Abschnitt 5.5 vorgestellten Mobilis Beans zu finden. Jedes Bean repräsentiert ein XMPP-Info/Query-Paket, das zur Kommunikation zwischen MobilisServer und den Android Anwendungen benutzt wird. Daher wird dieses Paket sowohl vom MobilisServer als auch von den Android Anwendungen referenziert. Im Paket MobilisClientServices sind die in Abschnitt 5.2 beschriebenen clientseitigen Dienste zu finden. Diese Komponente wurde als Android-Library-Projekt umgesetzt, um eine leichte Integration zu ermöglichen. Da im Kapitel 7.1 die verschiedenen Android-Anwendungen genauer vorgestellt werden, sollen sie an dieser Stelle nur kurz aufgelistet werden. · MobilisXHunt (siehe 7.1.5) und MobilisLocPairs (siehe 7.1.6) sind Location Based Games, die im Rahmen von Komplexpraktika am Lehrstuhl Rechnernetze der TU Dresden entstanden sind. Zu Testzwecken wurde beim XHunt-Projekt zusätzlich eine Java-Anwendung implementiert, die im Paket MobilisXHunt_JavaClient zu finden ist. · MobilisMedia (siehe 7.1.4) ist eine Anwendung zum Austausch von Bildern und zur Anzeige georeferenzierter Fotos. · MobilisGroups (siehe 7.1.2) ermöglicht Gruppenbildung mit örtlichen und zeitlichen Restriktionen. · MobilisContext (siehe 7.1.1) wurde im Rahmen dieser Arbeit zur Demonstration des serverseitigen User Context Service entwickelt. · Magnetizer ist ein einfacher Instant Messenger, der Einsteigern in das Mobilis- Projekt demonstriert, wie das MXA genutzt werden kann. Magnetizer wurde von István Koren entwickelt. · Mit MobilisMapDraw (siehe 7.1.3) können mehrere Nutzer gleichzeitig auf einem virtuellen Whiteboard oder einer Landkarte zeichnen. Hiermit wird die Nutzung des serverseitigen Collaborative Editing Service demonstriert. Von der Android App

55 6 Implementierung

und dem Dienst auf dem MobilisServer gemeinsam benutzte Komponenten befinden sich in den Paketen AndroidCEFX_Common und MobilisCommon. · SNSExample (siehe 7.1.7) dient zur Demonstration des clientseitigen Social Network Service. Damit können bestimmte Informationen aus externen sozialen Netzwerken angezeigt werden. · MobilisBuddy (siehe 7.1.8) ist eine mobile Applikation für Proximity Detection, die Benachrichtigungen ausgibt, wenn sich ein Freund in der Nähe befindet. Im Paket KMLSimulator befindet sich ein Hilfsprogramm für MobilisBuddy, das die Bewegung eines Freundes simuliert.

6.2 MobilisServer Mit über 14000 Codezeilen und über 100 Klassen in 19 Packages ist der MobilisServer das umfangreichste Teilprojekt innerhalb Mobilis. Daher fällt Entwicklern der Einstieg meist schwer. In diesem Abschnitt soll ein Überblick über die Einstellungsmöglichkeiten und die verschiedenen Packages gegeben werden, um den Einstieg in den MobilisServer zu erleichtern. Danach werden Details zum Coordinator Service und zur persistenten Speicherung auf dem MobilisServer beleuchtet.

6.2.1 Konfiguration Die Datei MobilisSettings.xml ist die zentrale Konfigurationsdatei des MobilisServer. Hier können vor dem Start Einstellungen der Mobilis Services und der aufzubauenden XMPP- Verbindungen festgelegt werden. Die dazugehörige XSD-Datei (XML Schema Definition) legt die Struktur der Konfigurationsdatei fest. Unterhalb des -Knotens sind mehrere -Elemente zu finden. Jedes dieser Elemente repräsentiert eine Instanz, die beim Start eine eigene XMPP-Verbindung aufbaut. Daher müssen zu jedem Agent die Verbindungsdetails wie Hostname und Port des XMPP-Servers, Benutzername, Passwort und die zu verwendende Ressource angegeben werden (siehe Abbildung 47).

Abbildung 47: Konfiguration der Mobilis Agents.

Die Agents werden von den Diensten des MobilisServer zur Kommunikation benutzt, wobei jeder Mobilis Service genau einen Mobilis Agent verwendet, aber ein Agent kann von mehreren Diensten benutzt werden. Für jeden zu startenden Mobilis Service existiert unterhalb des -Knotens ein -Element, das wie in Abbildung 48 aufgebaut ist. Der Typ gibt an, in welcher Java-Klasse der Programmcode des Dienstes zu finden ist. Außerdem wird hier der zu

56 6 Implementierung verwendende Agent spezifiziert und festgelegt, ob der Dienst automatisch (start=‘auto‘) oder auf Nachfrage (start=‘ondemand‘) starten soll (siehe 5.4.1). Genauso wie beim Agent, kann man mittels der -Elemente einfache Schlüssel/Wert-Paare zur Konfiguration festlegen, auf die der Dienst im laufenden Betrieb zurückgreifen kann.

Abbildung 48: Konfiguration der Mobilis Services.

6.2.2 Packages In diesem Abschnitt sollen die wichtigsten Packages des MobilisServer aufgelistet und kurz erläutert werden, um einen Überblick der Implementation zu geben. Unterhalb des Package de.tudresden.inf.rn.mobilis sind folgende Subpackages zu finden: server

· In diesem Hauptpaket sind GUI-Komponenten und zentrale Instanzen (Singletons) zu finden. Der MobilisManager liest die XML-Konfigurationsdatei aus und bietet Zugriff auf die dort festgelegten Daten. Weiterhin existieren Methoden zum Zugriff auf die laufenden Mobilis Agents und Mobilis Services. Die zentrale Logging- Funktion wird ebenfalls hier verwaltet. server.agents

· Hier findet man den Quellcode der Mobilis Agents, die u.a. für Aufbau und Verwaltung der XMPP-Verbindung verantwortlich sind. server.services

· Die wohl wichtigste Klasse in diesem Paket ist MobilisService. Sie dient allen Diensten des MobilisServer als Oberklasse. Die Klasse AppSpecificService erweitert sie um spezielle Funktionen für anwendungsspezifische Dienste. server.services.collabed

· Dieses Paket umfasst alle Klassen, die für den Collaborative Editing Service (siehe Abschnitt 5.4.5) benötigt werden. server.services.context

· In diesem Paket befinden sich die für den User Context Service (siehe Abschnitt 5.4.2) benötigten Komponenten. server.services.grouping

· Die Implementation des generischen Grouping Service (siehe Abschnitt 5.4.3) ist hier zu finden.

57 6 Implementierung server.services.integration

· Dieses Paket enthält die serverseitigen Dienste von MobilisBuddy (siehe Abschnitt 7.1.8), die die Integration von Facebook und XMPP Roster ermöglichen. server.services.locpairs & server.services.xhunt

· In diesem Paket befindet sich die in Abschnitt 5.4.6 beschriebenen Dienste für LocPairs und XHunt mit allen benötigten Komponenten. server.services.media

· Dieses Paket beinhaltet die für das Media Sharing benötigten Komponenten, insbesondere Repository Service und Content Service (siehe Abschnitt 5.4.4). xmpp.server

· Hier befinden sich die Adapterschichten zwischen den Mobilis Beans und der Smack-Bibliothek (auch Bean Smack Glue genannt, siehe Abschnitt 5.5).

6.2.3 Coordinator Service Der Coordinator Service wurde bereits zuvor in Abschnitt 5.4.1 von der konzeptionellen Seite beleuchtet. Dort wurden auch die beiden Hauptaufgaben verdeutlicht. Einerseits gibt der Coordinator Service Auskunft über die momentan laufenden Dienste (Service Discovery). Anderseits ermöglicht er auch das Erstellen neuer Dienstinstanzen. Die Umsetzung der zuletzt genannten Funktion stellte sich in der Implementierungsphase als komplex heraus und soll daher in diesem Abschnitt näher betrachtet werden. Bei Eingang eines CreateServiceInstanceIQ wird dieses zuallererst auf mögliche Fehlerfälle hin überprüft. Erst wenn sichergestellt ist, dass das IQ alle zur Diensterstellung benötigten Daten enthält und wenn diese valide sind, dann kann die neue Instanz kreiert werden. Da der Name des zu erstellenden Objekts erst im IQ übertragen wird, muss die Instanzerstellung zur Laufzeit geschehen und entsprechend generisch realisiert sein. Ein gewöhnliches Erstellen des gewünschten Objektes mittels des in Java dafür verwendeten new-Operators ist daher nicht möglich. Vielmehr muss so vorgegangen werden, wie in Abbildung 49 demonstriert wird.

Abbildung 49: Programmcodeausschnitt zur Erstellung neuer Instanzen anwendungsspezifischer Dienste.

58 6 Implementierung

Zuerst muss also aus dem IQ der Name der zu erstellenden Klasse extrahiert werden. Ist dies geschehen wird ein Objekt vom Typ AppSpecificService angelegt. Dies ist die Oberklasse aller im laufenden Betrieb startbaren Dienste. Nun wird der Kontruktor des zu erstellenden Dienstes ermittelt, der als Parameter den Coordinator Service, das Dienstpasswort und den Dienstnamen entgegennimmt. Dieser Konstruktor muss daher in jedem ondemand-Dienst vorhanden sein. Die eigentliche Erstellung des Dienstobjekts geschieht letztlich mithilfe der newInstance-Methode des Konstruktors, die die konkreten Werte für die vom Konstruktor geforderten Parameter entgegennimmt.

6.2.4 Persistente Speicherung Mithilfe des Hibernate-Frameworks [JC11] können bestimmte Instanzen auf dem MobilisServer zur persistenten Speicherung in eine Datenbank geschrieben werden. Es handelt sich hierbei um ein Persistenz Framework, das automatisches Mapping von Java Objekten in Datenbankeinträge und zurück unterstützt. Zu jeder Klasse die persistent gemacht werden soll, muss eine Konfigurationsdatei (engl. Mapping File) angelegt werden, in der angegeben wird, welche Attribute abgespeichert werden sollen. Jedes Mal, wenn Instanzen einer solchen Klasse verändert werden sollen, wird eine Datenbanktransaktion gestartet, die Objekte werden verändert, gespeichert und die Transaktion wird abgeschlossen. Der Programmcodeausschnitt in Abbildung 50 demonstriert diese Vorgehensweise am Beispiel.

Abbildung 50: Verändern von mit Hibernate persistent gemachten Java Objekten.

Die Java-Klassen können sowohl uni- als auch bi-direktionale Assoziationen untereinander aufweisen. Dabei werden 1:1, 1:n und n:m Beziehungen unterstützt. Das Hibernate- Framework wertet in diesem Fall die erstellten Konfigurationsdateien der Java-Klassen aus, sucht nach den dort festgelegten Fremdschlüsseln und legt automatisch das Tabellenschema in der Datenbank an.

6.3 MobilisXMPP Laut XMPP Standard muss auf jedes IQ vom Typ Get oder Set mit einem IQ vom Typ Result oder Error geantwortet werden. Für die Get- , Set-, und Result-IQs existieren innerhalb der entsprechenden Mobilis Beans (siehe 5.5) passende Konstruktoren, denen man alle Parameter übergeben muss, die für IQ-Erstellung benötigt werden. Error IQs mussten hingegen bisher von Hand erstellt werden, obwohl es auch für diesen IQ-Typ eine standardisierte Form gibt. So muss jedes IQ vom Typ Error ein Child Element aufweisen, das wie in Abbildung 51 aufgebaut ist. Es ist gemäß Standard auch möglich, den Payload des IQs, das den Fehler auslöste, nochmal im Error IQ anzuhängen, sodass der Sender sofort weiß, welches seiner IQs fehlerhaft war.

59 6 Implementierung

Abbildung 51: IQ vom Typ Error.

Der angegebene error-type (z.B. cancel, continue, wait) gibt einen Hinweis darüber, ob und wann der Nutzer eine erneute Anfrage stellen sollte. Die defined- condition (z.B. forbidden, unexpected-request, internal-server- error) gibt Auskunft über die Art des aufgetretenen Fehlers. Innerhalb des Elements kann eine genauere Fehlerbeschreibung eingefügt werden. Die allgemeine Oberklasse XMPPBean wurde nun um Attribute und Methoden erweitert, die eine Erstellung von Error IQs nach diesem Standard ermöglichen. Im Fehlerfall kann so ein entsprechender XMPPBean-Kontruktor benutzt werden, dem lediglich die drei Parameter Fehlertyp, -art und –beschreibung als String übergeben werden müssen. Die Oberklasse ist nun ebenfalls für die Erstellung und das Parsen des -Elements zuständig.

6.4 Mobilis Client Services In diesem Abschnitt soll dargestellt werden, wie der Social Network Service als Teil der Mobilis Client Services die APIs der verschiedenen externen Systeme anspricht und deren Antworten verarbeitet. Die Schnittstellen der sozialen Netzwerke wie Foursquare, Gowalla und Qype lassen sich mittels einfacher HTTP Requests ansprechen. Meist wird als Antwortformat sowohl XML als auch JSON (Abk. für JavaScript Object Notation) unterstützt. JSON ist wie XML als Datenformat unabhängig von der benutzten Programmiersprache einsetzbar, denn es existieren zahlreiche Parser in verschiedenen Sprachen. Für den Social Network Service fiel die Wahl auf JSON, denn es hat den Vorteil, dass es mit deutlich weniger Overhead als XML auskommt und somit die kompaktere Alternative darstellt. Im Folgenden wird als Beispiel die Umgebungssuche von Qype betrachtet, um den Ablauf einer Anfrage zu demonstrieren. Andere Anfragen werden nach dem gleichen Prinzip abgewickelt. Der API node für Qype‗s Umgebungssuche lautet http://api.qype.com /v1/positions/LAT,LON/places.json wobei LON und LAT mit den Werten für Längen- und Breitengrad des Suchpunktes zu belegen sind. Bei vielen APIs müssen die HTTP Requests entsprechend dem OAuth-Verfahren signiert werden. Dafür wird im Social Network Service die externe Bibliothek OAuth Signpost [OS10] verwendet. Wie das Erstellen, Signieren und Abschicken einer Anfrage funktioniert, zeigt der Programmcodeausschnitt in Abbildung 52.

60 6 Implementierung

Abbildung 52: Erstellen, Signieren und Abschicken einer API-Anfrage.

Zu allererst wird im Beispiel ein OAuthConsumer-Objekt angelegt. Dieses wird dann benutzt, um den HttpGet-Request zu signieren. Daraufhin kann dieser Request abgeschickt werden und die entsprechende Antwort vom Typ HttpResponse kann im Weiteren ausgewertet werden. Abbildung 53 zeigt die Antwort im JSON-Format auf eine beispielhafte Anfrage.

Abbildung 53: Ausschnitt der Antwort der Qype API auf die Anfrage http://api.qype.com/v1/positions/51.0489,13.7405/places.json

Zum Parsen dieser Antwort wird die externe Bibliothek Gson [GG10] verwendet. Gson konvertiert eine JSON String sogar direkt in äquivalente Java Objekte. Daher sind im Qype- Package des Social Network Service auch Klassen mit denselben Namen und Attributen der im JSON String vorkommenden Knoten zu finden. Wie diese Klassen zusammenhängen illustriert Abbildung 54. Wird nun im QypeManager die Methode zur Umgebungssuche aufgerufen, laufen die folgenden Schritte ab. Zuerst wird mit den der Methode übergebenen Parametern die URL

61 6 Implementierung für die Anfrage erstellt. Dann wird die Anfrage an den Qype Server übertragen, welcher mit einem entsprechenden JSON String antwortet. Dieser JSON String wird daraufhin durch die Gson-Bibliothek in Java Objekte konvertiert. Letztlich werden diese Java Objekte in der Methode zur Umgebungssuche an den Aufrufenden zurückgeben, wo sie z.B. als Grundlage für Overlay Items einer Karte oder Einträge einer Ergebnisliste dienen können.

Abbildung 54: Klassendiagramm der Qype Komponenten im Social Network Service.

In der Implementierungsphase ergaben sich Änderungen gegenüber dem in Abschnitt 5.2 entwickelten Konzept, nach dem sowohl die Facebook- als auch Twitter-API in den Social Network Service integriert werden sollten. Dies wurde verworfen, da für diese populären Netzwerke bereits zahlreiche, leicht benutzbare Android-Bibliotheken zum einfachen API- Zugriff existieren. Ein nochmaliges Kapseln dieser Funktionalitäten im Social Network Service wird als nicht sinnvoll erachtet, denn es würde lediglich die Performance senken, aber nicht die Nutzung vereinfachen. Für die Facebook-API sei das Facebook Android SDK [FIL11b] genannt. Für die Twitter-API kann beispielsweise JTwitter [WAL11] verwendet werden.

62 7 Evaluierung

7 Evaluierung Nachdem in den vorangegangenen Kapiteln die konzeptionellen Aspekte und Implementationsdetails beleuchtet wurden und das Mobilis-Framework umgesetzt wurde, gilt es in diesem Kapitel, die Ergebnisse zu bewerten. Dazu soll im ersten Abschnitt ein Funktionstest durchgeführt werden. Danach folgt ein Abgleich des Mobilis-Frameworks mit den gestellten Anforderungen und ein Vergleich mit anderen Systemen. Abschließend erfolgt die Bewertung des Nutzens, den Entwickler aus dem Mobilis-Framework ziehen können.

7.1 Funktionstest Um die Funktion der für die Mobilis-Plattform entwickelten Services nachzuweisen und zu demonstrieren, wurden mehrere mobile Applikationen erstellt. Diese sind meist lediglich als Prototypen umgesetzt, können aber die Grundfunktionen der Dienste gut veranschaulichen. Daher sollen im Folgenden einige Anwendungen kurz vorgestellt und deren Grundfunktionen mithilfe von Screenshots demonstriert werden.

7.1.1 MobilisContext MobilisContext wurde im Rahmen dieser Arbeit als Beispielanwendung zur Demonstration des generischen User Context Service (siehe Abschnitt 5.4.2) entwickelt. Die Anwendung bietet die Möglichkeit, bestimmte Informationen des eigenen Nutzerkontextes an den serverseitigen User Context Service zu senden, von wo aus andere Nutzer auf diese Daten zugreifen können. Dabei setzt MobilisContext das zuvor besprochene Protokoll des Kontextdienstes um. Jegliche Kommunikation erfolgt also wie in Abschnitt 5.4.2 gezeigt wurde. Um auf die verschiedenen durch MobilisContext unterstützten Kontextarten zugreifen zu können, wurde eine Registerkartenansicht eingesetzt. So existieren die auswählbaren Tabs Mood, Tune und Location. Abbildung 55 zeigt die verschiedenen Ansichten von MobilisContext. In der Mood-Ansicht (siehe a) lassen sich Informationen über die Stimmungslage des Nutzers angeben und veröffentlichen. Dazu muss eine der in XEP-0107 vordefinierten Stimmungen (z.B. happy, hungry, angry) ausgewählt werden. Diese kann noch durch eine zusätzliche textuelle Beschreibung ergänzt werden. Die Tune-Ansicht (siehe b) erlaubt das Veröffentlichen von Informationen zur aktuell vom Nutzer gehörten Musik. MobilisContext zeigt zur Demonstration lediglich eine Liste mit drei Songs, von denen der Nutzer auswählen kann. Bei Betätigung des Play-Buttons werden detaillierte Informationen zum ausgesuchten Song an den User Context Service gesendet. Im Location Tab (siehe c) erscheint eine Kartenansicht, auf der der Nutzer eine beliebige Position auswählen kann, die dann als sein Aufenthaltsort veröffentlicht wird. Hier wurde also der Einfachheit halber auf eine Validierung der angegebenen Daten durch Ortungsverfahren verzichtet.

63 7 Evaluierung

Diese speziellen Kontextinformationen entsprechen alle jeweils einer XMPP Standarderweiterung. Natürlich ist es daneben auch möglich, beliebige Kontextdaten zum User Context Service zu übermitteln. Zu diesem Zweck muss über das Menü der Eintrag „Publish context― ausgewählt werden und es erscheint eine entsprechende Ansicht (siehe d). Hier lassen sich der Pfad im Kontextbaum sowie Schlüssel, Wert und Datentyp des neuen Eintrags festlegen. Ein Klick auf Publish sendet die Informationen zum User Context Service und schließt diese Ansicht wieder.

a) b)

a)

c) d)

Abbildung 55: MobilisContext erlaubt das Veröffentlichen von verschiedenen Arten von Kontextinformationen.

Da es sich bei MobilisContext um eine Beispielanwendung handelt, gibt es nur sehr wenige frei konfigurierbare Einstellungen. Mit Klick auf den Menüeintrag „Settings― öffnet sich die in Abbildung 56 (e) gezeigte Ansicht der Anwendungseinstellungen. Hier lässt sich momentan lediglich die XMPP-ID des MobilisServer festlegen und ein neue Suche nach dort laufenden User Context Services starten. Um Informationsupdates anderer Nutzer zu abonnieren, muss man im Menü den Eintrag „Subscribe / Unsubscribe― wählen. Es erscheint die in (f) gezeigte Ansicht. Hier kann die

64 7 Evaluierung

XMPP-ID des Nutzers sowie der zu abonnierende Knoten innerhalb des Kontextbaumes angegeben werden. Eine Bestätigung mittels des Subscribe-Buttons stößt den Abonnementprozess an. Der User Context Service wird nun dem Eigentümer des Knotens eine Autorisierungsanfrage senden. Läuft bei diesem Teilnehmer ebenfalls die Anwendung MobilisContext, so wird diese Anfrage automatisch positiv beantwortet und der neue Abonnent bekommt den aktuellen Knotenstatus vom User Context Service zugesandt. Falls Fehler auftreten, so sendet der User Context Service entsprechende Error-IQs, deren Inhalt dem Nutzer von MobilisContext in einer Toast-Nachricht angezeigt wird.

e) f)

g) h)

Abbildung 56: Anwendungseinstellungen in MobilisContext (e) und der Subscribe-Dialog (f).Wird auf Client-2 (g) eine neue Kontextinformation veröffentlicht, so erhalten alle Abonnenten eine entsprechende Benachrichtigung (h).

Veröffentlicht nun zum Beispiel ein Nutzer Client-2 wie in Abbildung 56 (g) Informationen über die Musik, die er gerade hört, so werden alle Abonnenten darüber informiert. In MobilisContext erscheint zu diesem Zweck wiederum eine kurze Bildschirmnachricht (siehe h).

65 7 Evaluierung

7.1.2 MobilisGroups MobilisGroups [RL10] ist eine Anwendung für Location Based Group Formation, die den serverseitigen Grouping Service des Mobilis Framework nutzt. Das Anlegen und Verwalten von Nutzergruppen, wie es innerhalb sozialer Netzwerke üblich ist, wird hierbei um bestimmte zeitliche und örtliche Aspekte bereichert. Man kann einer Gruppe (z. B. Interessensgemeinschaft, Verein, Sportclub) oder einem Ereignis (z. B. Konzert, Feier, BarCamp) in den meisten Fällen einen bestimmten Ort zuweisen, an dem sich bspw. die Gruppenzentrale befindet oder Treffen stattfinden. Optional können zu solchen Gruppen und Ereignissen oft auch Angaben zu gewissen Zeitspannen gemacht werden, die z.B. angeben, wann ein Ereignis stattfindet oder wann eine Vorbereitungsphase beginnt. Die Idee hinter MobilisGroups ist nun, dass diese örtlichen und zeitlichen Angaben als Restriktionen zur Gruppenverwaltung im normalen Social Networking hinzugefügt werden. Um also bestimmte Gruppen sehen zu können und um ihnen beitreten zu können, muss sich der Nutzer zu einer bestimmten Zeit an einem bestimmten Ort aufhalten.

Abbildung 57: Ausschnitt der Benutzeroberfläche von MobilisGroups. Quelle: [RL10]

66 7 Evaluierung

Die Benutzeroberfläche des im Rahmen der Belegarbeit [RL10] konzipierten und entwickelten MobilisGroups ist in Abbildung 57 dargestellt. Die zentrale Komponente ist die Kartenansicht, in der die verschiedenen Gruppen und Elemente externer sozialer Netzwerke dargestellt werden. Hier werden dem Nutzer immer nur die gerade für ihn am entsprechenden Ort zur entsprechenden Zeit sichtbaren Gruppen angezeigt. Außerdem ermöglicht ein langer Klick auf die Karte das Erstellen eigener Gruppen. Weiterhin gibt es eine Freundesliste, von der aus der Nutzer genauere Profilinformationen und Gruppenzugehörigkeiten seiner XMPP Buddies abrufen kann. Die eigenen Gruppen lassen sich in einer eigens dafür angelegten Ansicht administrieren. In entsprechenden Dialogen können Anwendungs- und Kommunikationseinstellungen festgelegt werden. Es handelt sich bei MobilisGroups eher um ein prototypisches Grundgerüst für Location Based Group Formation, welches in Richtung verschiedener Szenarien weiterentwickelt werden kann. Ein beispielhaftes Nutzungsszenario ist ein BarCamp mit etwa 100 Teilnehmern. Der Organisator der Veranstaltung erstellt mit MobilisGroups eine Gruppe, die etwa vier Wochen vor Veranstaltungsbeginn in der weiteren Umgebung (20km Radius) des Veranstaltungsortes zu sehen ist. Nutzer, die sich zu diesem Zeitpunkt in der entsprechenden Stadt aufhalten, können also das Ereignis auf der Karte sehen und sich den Termin vermerken. Teilnehmer des BarCamps, die am Tag zuvor in der Stadt ankommen, sehen ebenfalls das BarCamp-Symbol auf der Karte und können es nutzen, um dorthin zu navigieren. Das Beitreten zur Gruppe ist erst am Veranstaltungstag und in der Nähe des Veranstaltungsortes (200m Radius) möglich. Die BarCamp-Teilnehmer können mit MobilisGroups Nachrichten untereinander austauschen und andere Teilnehmerprofile erkunden. Nach dem Ende der Veranstaltung ist zwar kein Gruppenbeitritt mehr möglich, aber die Gruppe bleibt weiterhin aktiv. Dies ermöglicht den Austausch von Fotos oder anderen Dateien und erleichtert die Kontaktaufnahme mit anderen BarCamp-Teilnehmern.

7.1.3 MobilisMapDraw Zur Demonstration der Verwendung des Collaborative Editing Service hat Dirk Hering im Rahmen der Belegarbeit [DH09] die Anwendung MobilisMapDraw entwickelt. Dem Nutzer der Anwendung wird auf dem mobilen Endgerät ein Zeichenbereich (auch Shared Whiteboard genannt) angezeigt, auf dem sich optional ein Landkartenhintergrund einblenden lässt. Der Nutzer kann einer Collaborative Drawing Session beitreten oder eine neue starten. Innerhalb der Session können nun alle Teilnehmer gemeinsam und gleichzeitig auf der Karte bzw. dem Shared Whiteboard zeichnen (siehe Abbildung 58). MobilisMapDraw demonstriert nur die Grundfunktionalitäten des Collaborative Editing Service und könnte noch um zusätzliche Funktionen zum Zeichnen erweitert werden. Momentan wird lediglich ein einfaches Pinselwerkzeug für Freihandformen unterstützt. Weitere Funktionen wie das Zeichnen von Vierecken und Kreisen oder Einfügen von Textfeldern ließen sich aber hinzufügen. Außerdem wäre ein Anwählen und Ändern existierender Formen (Verschieben, Löschen, …) denkbar. Um Netzwerk-Traffic zu sparen, könnte eine nachträgliche Punktreduzierung durchgeführt werden. Weiterhin wäre ein Export der Zeichnung als Pixelgrafik wünschenswert.

67 7 Evaluierung

Abbildung 58: MobilisMapDraw ermöglicht kollaboratives Zeichnen auf Landkarten und Shared Whiteboards.

7.1.4 MobilisMedia Die Android-Anwendung MobilisMedia entstand im Rahmen der Belegarbeit „XMPP-based Media Sharing for Mobile Collaboration with Android Phones― von Benjamin Söllner [BS09]. Sie ermöglicht den Austausch von multimedialen Inhalten (z. B. Bilder) zwischen Nutzern und Nutzergruppen. Mit dem Smartphone aufgenommene und automatisch georeferenzierte Fotos können in einem dafür ausgelegten Repository hinterlegt werden. Der Inhalt dieser Repositories kann dann von anderen Nutzern nach Eigentümername, Aufnahmedatum und Aufnahmeort durchsucht werden. Die Fotos können aber natürlich auch als Icons auf einer Landkarte visualisiert werden (siehe Abbildung 59). Es ist aber auch möglich, auf die serverseitigen Dienste zu verzichten und die Fotos direkt zu bestimmten Usern via XMPP Dateitransfer zu senden. Wenn die Anwendung startet, dann wird zuallererst nach verfügbaren Repository Services (siehe Abschnitt 5.4.4) gesucht. Werden im Service-Discovery-Verfahren mehrere solcher Dienste gefunden, so erscheint ein Auswahldialog, in dem der Nutzer entscheidet welcher Dienst genutzt werden soll. Wurde ein Service ausgewählt, so werden automatisch die im Kartenausschnitt sichtbaren Einträge aus dem Repository geladen und als Icons dargestellt. Mit einem Klick auf ein Element lassen sich nähere Informationen dazu anzeigen. An dieser Stelle lässt sich die Bilddatei auch aktualisieren, sofern man Eigentümerrechte daran hat. Ein Löschen der Datei ist ebenfalls möglich (siehe Abbildung 59). Ist MobilisMedia installiert, so kann es durch Androids Intent-Mechanismus auch von externen Programmen wie der Kameraapplikation aufgerufen werden. Wird dort z.B. „Share― ausgewählt, wird auch „Share via XMPP― in der Liste der möglichen Aktionen angezeigt. MobilisMedia ist also sehr gut in die Android-Plattform integriert.

68 7 Evaluierung

Abbildung 59: Benutzeroberfläche von MobilisMedia.

7.1.5 MobilisXHunt MobilisXHunt ist ein ortsbasiertes Spiel, das mithilfe von Smartphones gespielt wird. Es entstand im Rahmen eines Komplexpraktikums im WS2009/2010 am Lehrstuhl Rechnernetze der TU Dresden. Die Grundidee hinter MobilisXHunt ist Umsetzung des Brettspiels „Scotland Yard – Auf der Jagd nach Mister X― (Ravensburger) in die Realität. Es ist ein Spiel für zwei bis sechs Personen. Ein Mitspieler ist der gesuchte Mister X und die anderen sind die Agenten, die versuchen ihn zu fangen. Die Position von Mister X ist allerdings unbekannt, aber sie wird in regelmäßigen Abständen (z.B. alle drei Runden) bekannt gegeben. Im Originalspiel hat man verschiedene Tickets (Bahn, Bus, Taxi, Fähre), um die eigene Spielfigur auf dem Brett zu bewegen. Das Spiel endet, sobald ein Agent auf der Position von Mister X steht oder wenn Mister X in einer vorher festgelegten Rundenanzahl nicht gefasst wurde. In MobilisXHunt begeben sich die Spieler mit Smartphones ausgestattet auf die Jagd in einer realen Stadt und nutzen echte Verkehrsmittel des öffentlichen Personennahverkehrs, um von einem Verkehrsknotenpunkt des Liniennetzes zum nächsten zu gelangen. Um die Spielerpositionen zu ermitteln, werden die in den Smartphones eingebauten GPS-Empfänger verwendet. Es wurde versucht, sich so genau wie möglich an die Regeln des Brettspiels zu halten, was aber durch die Übertragung des Spielprinzips in die Realität nicht immer möglich ist. Wie im Originalspiel wird in Runden gespielt, aber um den Spielfluss zu beschleunigen, können alle Agenten gleichzeitig ihren Spielzug machen, nachdem Mister X sein nächstes Ziel gewählt hat. Neben den mobilen MobilisXHunt-Anwendungen gibt es auch eine zentrale Serverkomponente, die als anwendungsspezifischer Service im MobilisServer umgesetzt

69 7 Evaluierung wurde (siehe 5.4.6). Dort ist die Spiellogik implementiert und es können alle Spieleinstellungen vorgenommen werden. Für jede Stadt, in der gespielt werden soll, müssen entsprechende Konfigurationsdateien vorliegen, die festschreiben, wo sich die Haltestellen befinden und über welche Verbindungen diese erreichbar sind. In Abbildung 60 wird die Benutzeroberfläche während eines Spiels gezeigt. Es werden die Spielfiguren der Agenten und die letzte bekannte Position von Mister X angezeigt. Außerdem sind auch alle Haltestellen zu sehen und man erkennt, wie diese miteinander im Liniennetz verbunden sind. Im nächsten Schritt erreichbare Stationen werden mit einem grünen Icon markiert, sodass die Zielauswahl schneller durchgeführt werden kann. In einer anderen Ansicht werden zusätzliche Informationen zum Spielgeschehen gezeigt. Dazu zählt zum Beispiel die Anzeige der von anderen Mitspielern verbrauchten Tickets (siehe Abbildung 60). Dies ist auch eine wichtige strategische Komponente, denn damit lassen sich eventuell Rückschlüsse auf die Position von Mister X ziehen.

Abbildung 60: Anzeige des „Spielfeldes― und der zusätzlichen Spielinformationen.

Beginnt eine neue Runde, müssen die Spieler ihre nächste Zielhaltestelle auswählen und sich dann dorthin begeben. Wurde ein Ziel gewählt, muss auch angegeben werden, welches Verkehrsmittel benutzt werden soll, damit das korrekte Ticket abgezogen werden kann. Abbildung 61 zeigt den entsprechenden Dialog (links) und den eingebauten Abfahrtsmonitor (rechts). Dieser zeigt die nächsten Abfahrten mit den Wartezeiten an einer bestimmten Haltestelle an. Damit die Runden nicht zu lang werden, können die Spieler ihre nächsten Züge zeitlich mithilfe des Abfahrtsmonitors planen. Die Spieler haben außerdem die Möglichkeit, vor, während und nach dem Spiel den Mehrbenutzerchatraum zu nutzen, der für jedes Spiel angelegt wird. Vor dem Spiel lassen

70 7 Evaluierung sich hier Spieleinstellungen diskutieren, im Spiel strategische Absprachen tätigen und nach dem Spiel kann hier die Auswertung stattfinden.

Abbildung 61: Auswahl des nächsten Ziels und Anzeige der Abfahrten.

MobilisXHunt wurde ursprünglich für die Stadt Dresden entwickelt, aber es ist durchaus auch auf andere Städte übertragbar. Es müssen lediglich die angesprochenen Konfigurationsdateien für eine neue Stadt erstellt werden. Der Abfahrtsmonitor funktioniert allerdings momentan nur in Dresden. Eine Einbindung der Abfahrten in anderen Großstädten ist geplant. Momentan arbeitet Danny Kiefner im Rahmen seines Belegs „Rundenbasierte ortsbezogene Spiele auf mobilen Endgeräten― [DK11] an der Weiterentwicklung von MobilisXHunt.

7.1.6 MobilisLocPairs MobilisLocPairs [NHBMRM+11] entstand im Rahmen eines Komplexpraktikums im WS2010/2011 am Lehrstuhl Rechnernetze der TU Dresden. Es ist eine Umsetzung des bekannten Kinderspiels Memory, das im englischsprachigen Raum Pairs genannt wird. Es handelt sich um ein Location Based Indoor Game, das also innerhalb von Gebäuden gespielt wird. Die Spielkarten mit jeweils doppelt vorhandenen Bildern sind gewissermaßen hinter Barcodes versteckt, die überall im Gebäude verteilt wurden. Das Scannen dieser Barcodes (es werden QR-Codes verwendet) entspricht dem Umdrehen einer Karte im Memory-Spiel. Bei jedem Scan-Vorgang werden die Signalstärken aller aktuell verfügbaren WLAN- Zugangspunkte aufgezeichnet, in einem sogenannten Fingerprint gespeichert und an einen Server übertragen. Dies hat den Zusatznutzen, dass damit die Ortung innerhalb des Gebäudes verbessert werden kann.

71 7 Evaluierung

Die Spielregeln folgen so weit wie möglich denen des Memory-Spiels. Bei LocPairs werden 32 Spielkarten, also 16 Paare verwendet. Das Spiel ist rundenbasiert und wird in Zweierteams gespielt. Eine Runde hat eine vorher festgelegte Maximaldauer von z.B. 60 Sekunden. Innerhalb dieser Zeit dreht ein Teammitglied die erste Karte um und daraufhin versucht das zweite Teammitglied die dazugehörige Karte aufzudecken. Gelingt dies, bekommt das Team einen Punkt, die zwei Karten werden aus dem Spiel genommen und das Team ist in der nächsten Runde erneut an der Reihe. Passen beide Karten allerdings nicht zusammen, so werden die Karten wieder zugedeckt und in der folgenden Runde spielt das nächste Team. Das Ziel des Spiels ist das Aufdecken der meisten Kartenpaare und somit das Erreichen der höchsten Punktzahl.

Abbildung 62: Benutzeroberfläche von MobilisLocPairs. Quelle: [NHBMRM+11]

Um LocPairs zu spielen, müssen die Anwendung selbst, ein Barcode-Scan-Programm (z.B. der kostenlose „Barcode Scanner―) sowie die MXA-Anwendung installiert und richtig konfiguriert sein. Durch Auswahl des Lobby-Buttons erscheint eine Ansicht aller aktuell laufenden Spiele. Man kann außerdem auch ein neues Spiel erstellen. Tritt man einem Spiel

72 7 Evaluierung bei, sieht man auch die anderen Mitspieler (siehe Abbildung 62). Die Zusammenstellung der Teams geschieht automatisch auf dem Server. Hat der Spieler keinen Namen in den Spielereinstellungen angegeben, wird automatisch ein Name generiert. Um ein Spiel starten zu können, wird eine gerade Spieleranzahl benötigt. Mindestens vier Spieler sind jedoch Voraussetzung. Bei Spielstart beginnt die erste Runde nach einer kurzen Wartezeit. Die Spieler sehen den Grundriss des Gebäudes, in dem gespielt wird. Darauf ist ihre eigene Position und die der anderen Mitspieler verzeichnet. Außerdem sind die im Gebäude verteilten Barcodes zu sehen, die es zu scannen gilt. Ist das eigene Team gerade an der Reihe, so sieht man in der unteren Leiste die restliche Rundenzeit. Außerdem erscheint der Button zum Starten des Scan-Vorgangs. Wurde ein Barcode gescannt, sehen alle Mitspieler (auch die der gegnerischen Teams) das dahinter versteckte Bild bis zum Ende der Runde (siehe Abbildung 62). Alle in diesem Abschnitt besprochenen Spielregeln und -abläufe beruhen auf der Spieldokumentation von MobilisLocPairs [NHBMRM+11].

7.1.7 Social Network Service Example Wie der Anwendungsname schon verrät, handelt es sich beim Social Network Service Example um eine Beispielanwendung. Sie hat die Aufgabe, die Verwendung des Social Network Service aus dem clientseitigen Framework-Teil (siehe Abschnitt 5.2) zu demonstrieren. Die Anwendung besteht lediglich aus einer Kartenansicht, die sich mit mehreren Overlay- Ansichten überlagern lässt. Diese Overlays kommen aus verschiedenen externen sozialen Netzwerken und werden vom Social Network Service berechnet. Momentan wird die Nutzung anhand der Netzwerke Foursquare und Qype demonstriert. Qype ist ein Empfehlungsportal, dessen Nutzer verschiedenste Unternehmen, Orte und Dienstleistungen bewerten können. Foursquare ist eine Mobile-Social-Networking-Anwendungen mit Spielcharakter, deren Nutzer mitteilen können, an welchem Ort sie sich gerade befinden, indem sie sich in entsprechende Lokalitäten „einchecken―. Dies wird mit Punkten oder bei häufigem Wiederkehren mit einem virtuellen „Bürgermeister―-Titel belohnt. Social Network Service Example erlaubt nun zum Beispiel eine Umgebungssuche aller nahe gelegenen Foursquare- und Qype-Einträge. Die Suchergebnisse werden dann als Icons auf der Karte dargestellt (siehe Abbildung 63). Bei Auswahl eines Icons lassen sich nähere Details dazu ansehen. Eine weitere Funktion ist die Anzeige der Foursquare User History. Diese umfasst die letzten zehn Orte an denen sich ein Foursquare-Nutzer eingecheckt hat. Um auf diese Daten zuzugreifen, benötigt der Social Network Service die entsprechenden Benutzerdaten. Diese können in der Anwendung unter Settings eingegeben werden (siehe Abbildung 63).

73 7 Evaluierung

Abbildung 63: Benutzeroberfläche von Social Network Service Example.

7.1.8 MobilisBuddy MobilisBuddy realisiert umgebungsbasierte Freundessuche auf mobilen Endgeräten. Die Anwendung entstand im Rahmen eines Komplexpraktikums am Lehrstuhl Rechnernetze der TU Dresden im WS2008/2009. Der Startbildschirm von MobilisBuddy ist zunächst eine normale Kartenansicht, auf der der Nutzer seine eigene Position sehen kann. Über das Menü lassen sich verschiedene XMPP- und Facebook-Accounts verwalten. Diese Konten werden benutzt, um die Freundeslisten dieser Netzwerke in MobilisBuddy zu importieren. Verwendet einer der Facebook-Freunde oder XMPP Buddies des Nutzers ebenfalls MobilisBuddy und befindet sich dieser Freund

74 7 Evaluierung innerhalb eines bestimmten Sichtbarkeitsradius (z.B. 500m) um den Nutzer herum, so erhalten beide eine entsprechende Benachrichtigung. MobilisBuddy ist also eine mobile Applikation für Proximity Detection und Proximity Alerts. Innerhalb des Radius sehen beide Nutzer live die Positionsaktualisierungen des anderen, sodass sie sich bei Bedarf leicht finden können. Wenn man auf ein Buddy Icon in der Kartenansicht drückt, dann erscheint außerdem ein Menü mit durchführbaren Aktionen wie z.B. Anrufen, Anstoßen und Chatten. Wird der Sichtbarkeitsradius wieder verlassen, so sieht man nur noch die letzte bekannte Position des Freundes durch eine entsprechende Markierung auf der Karte. Dieser Mechanismus führt zu einer besseren Privatsphäre, denn so können nur Freunde in der näheren Umgebung die eigenen Positionsupdates erhalten.

Abbildung 64: MobilisBuddy erkennt Situationen, in denen sich Freunde in der Nähe aufhalten und gibt entsprechende Benachrichtigungen aus. 7.2 Vergleich mit anderen Systemen In Abschnitt 2.2 wurden bereits einige existierende Frameworks für Mobile Social Software vorgestellt. In diesem Abschnitt soll nun kurz ein Vergleich des entwickelten Mobilis- Frameworks mit bestehenden Systemen erfolgen. Frameworks bzw. Middleware Layer geben den damit entwickelten Anwendungen bereits die grobe Architektur vor. Bei Mobilis und dem bereits zuvor vorgestellten MobiSoc [GKBB09] ist dies eine klassische Client-Server-Architektur. Dahingegen werden in SAMOA [DBRMAT07] und MobiClique [POL+09] mobile Ad-hoc-Netzwerke (engl. MANETs) aufgebaut und verwendet. Dazu wird als Funktechnologie WLAN oder Bluetooth eingesetzt.

75 7 Evaluierung

Tabelle 9 zeigt einerseits, welche der in der Anforderungsanalyse (siehe Kapitel 3) gestellten Anforderungen Mobilis tatsächlich umsetzt. Andererseits ist auch ein Vergleich mit den Features anderer Frameworks möglich.

Tabelle 9: Vergleich von Mobilis mit den gestellten Anforderungen und anderen Frameworks.

Mobi Mobi Beschreibung Mobilis SAMOA Soc Clique FA-1 Einfache Kommunikation zw. Nutzern ja nein nein nein Verwaltung von Verfügbarkeits- FA-2 ja nein nein nein informationen der Freunde FA-3 Nutzerkontext verwalten (Location) ja ja ja nein FA-4 Nutzung bestehender sozialer Netzwerke ja nein ja ja FA-5 File Sharing ja nein nein nein FA-6 Media Sharing ja nein nein nein FA-7 Gruppenbildung ja ja nein ja FA-7.1 Lokationsbasierte Gruppenbildung ja ja nein ja FA-7.2 Dynamische Gruppenbildung nein ja nein nein FA-8 Multi-User Chat ja nein nein nein FA-9 Proximity Detection ja* ja ja ja FA-10 Shared Editing ja nein nein nein FA-11 Publish-Subscribe-Mechanismus nein nein nein nein FA-12 Trading-Funktion ja* nein nein nein FA-13 Service-Paradigma umsetzen ja nein ja nein FA-14 Service Discovery ja nein ja nein Berechnung / Ermittlung sozialer Netzwerke nein ja ja ja Matching von Nutzer- und Ortsprofilen nein ja ja ja

* bisher in anwendungsspezifischem Service umgesetzt; realisierbar mit User Context Service

In Tabelle 9 wird ersichtlich, dass Mobilis eher spezielle Features bietet, die in einer Vielzahl von mobilen sozialen Anwendungen benutzt werden können, wohingegen bei den anderen Frameworks und Middleware-Layer-Systemen die automatische Berechnung der sozialen Netzwerke im Vordergrund steht. Es geht bei diesen Systemen also primär um die Gruppierung einer Nutzergemeinde in einzelne soziale Netzwerke. Dafür setzen die drei vorgestellten Systeme Nutzer- und Ortsprofile ein, die miteinander abgeglichen werden, um für die Nutzer interessante Personen und Orte ausfindig zu machen. Dahingegen geht Mobilis von einem bestehenden sozialen Netzwerk aus, das wie bei XMPP üblich im Roster der Nutzer verwaltet wird. Der Fokus wird vielmehr auf Funktionen gelegt, die innerhalb dieser Netzwerke von Nutzern oft durchgeführt werden (z.B. Instant Messaging, Gruppenbildung, Media Sharing). Diese Funktionen müssen somit nicht jedes Mal von Grund auf neu realisiert werden.

7.3 Entwicklernutzen Wie jedes Framework hat auch Mobilis das Ziel, Entwicklern so viel wie möglich Arbeit abzunehmen, sodass zu entwickelnde Anwendungen schneller umgesetzt werden können. Ein wichtiger Teil der Evaluation des Frameworks ist nun also die Beurteilung des Entwicklernutzens, welche in diesem Abschnitt durchgeführt werden soll.

76 7 Evaluierung

Da zum Zeitpunkt der Fertigstellung des Mobilis Frameworks nicht sofort Entwickler verfügbar waren, die die einzelnen Komponenten hätten testen können, wurden bereits seit Beginn dieser Arbeit mehrere Teams von Entwicklern mobiler Anwendungen im Softwareentwicklungsprozess begleitet, beraten und kontinuierlich befragt. Diese Entwickler fanden sich in verschiedenen Lehrveranstaltungen des Rechnernetze Lehrstuhls der TU Dresden. Dazu zählen das Komplexpraktikum „Entwicklung mobiler und verteilter Systeme― und ein zur Vorlesung „Application Development for Mobile and Ubiquitous Computing― gehörendes Seminar, in dem die Studierenden in Zweierteams mobile Applikationen entwickelten. Zum Abschluss des genannten Seminars wurden die Entwickler sowohl allgemein zum aktuellen Stand von Mobile Social Software als auch speziell zu ihren entwickelten Anwendungen befragt. Diese Befragung wurde mithilfe eines Fragebogens (siehe Anhang) im Rahmen des letzten Seminars durchgeführt, in dem die Studierenden auch ihre eigenen Ergebnisse vorstellen mussten. Aufgrund des generellen Interesses der Studierenden am Thema und wegen der auf Seminarzeit (180 Minuten) ausgedehnten Ausfüllzeit, kann eine sehr gute Rücklaufquote der Fragebögen von 91% festgestellt werden. Letztlich konnten 32 der 35 ausgeteilten Fragebögen zur Auswertung herangezogen werden. Es ist zu betonen, dass die durchgeführte Umfrage mit nur 32 Personen nicht in jeglicher Hinsicht repräsentativ für alle Entwickler ist. Die folgende Auswertung ist also immer unter diesem Gesichtspunkt zu betrachten. Eine Fragebogenversion mit den ausgezählten Ergebnissen der Umfrage ist ebenfalls im Anhang zu finden. In der ersten Frage sollte herausgestellt werden, welches Smartphone-Betriebssystem bei den Entwicklern am meisten verwendet wird und aus welchen Gründen dieses ausgewählt wurde. Das Ergebnis wird in Abbildung 65 gezeigt. 72% entwickelten für Android, 19% für Apples iOS, 6% für Windows Phone 7 und lediglich 3% für Nokias Symbian. Andere Smartphone- Betriebssysteme waren nicht vertreten.

Android 3% 6% iOS Windows Phone 7

19% Symbian Windows Mobile Meego Bada 72% Blackberry OS WebOS Maemo Other

Abbildung 65: Antwortverteilung auf die Frage: „Which / platform did you implement your application for?―

77 7 Evaluierung

In Abbildung 66 wird veranschaulicht, welche Gründe für die Befragten bei der Auswahl des Smartphone-Betriebssystems ausschlaggebend waren. 75% gaben an, allgemeines Interesse an der Plattform zu haben und mehr darüber lernen zu wollen. Für 38% der Entwickler zählt außerdem die Größe des Marktanteils der jeweiligen Plattform, sodass dafür entwickelte Anwendungen viele potentielle Nutzer haben. Ebenso entwickeln 38% der Studierenden auf einer Plattform, weil sie ein Gerät mit diesem Betriebssystem besitzen. Für 34% der Befragten ist die Zukunftsprognose wichtig. Sie setzen gern auf aufstrebende Systeme mit viel Potential. Es ist außerdem nicht zu vernachlässigen, dass auf den verschiedenen Betriebssystemen auch unterschiedliche Programmiersprachen eingesetzt werden. Für 28% war es wichtig, bereits gute Kenntnisse der Programmiersprache zu haben. Dahingegen wählten nur 13% ein System aus, um eine neue Programmiersprache zu lernen. Nur 6% der befragten Studierenden hatten bereits Erfahrung auf der von ihnen ausgewählten Plattform.

I wanted to learn more about that platform.

The platform has a big market share. So my application has many potential users. I do own a mobile device with that operating system myself. It is an upcoming platform with much potential. I already had good skills in the programming language used on that platform. I wanted to learn another programming language. I already had experience on that platform.

The platform has a special feature I wanted to learn about.

0% 10% 20% 30% 40% 50% 60% 70% 80%

Abbildung 66: Antwortverteilung auf die Frage: „Why did you choose this operating system?―

Es wird in der Auswertung der ersten Frage sehr deutlich, dass die Android-Plattform von den Teilnehmern des Seminars bevorzugt wird. Die Gründe für Androids Sympathie in Entwicklerkreisen entsprechen auch ungefähr den zuvor besprochenen und in Abbildung 66 veranschaulichten Gründen. Androids Martkanteile steigen kontinuierlich an und es werden immer mehr Geräte von immer mehr Herstellern herausgebracht, auf denen Android seinen Dienst verrichtet. Der Fakt, dass Android bis auf einige kleinere Teile quelloffen ist, stellt sicherlich auch einen für viele Entwickler ausschlaggebenden Grund dar. Im Mobilis-Projekt fiel die Wahl der Grundlage für die clientseitigen Framework- Komponenten ebenfalls auf Android. Wie sich nun beim ersten Teil der Umfrage herausstellte, war dies aufgrund des hohen Interesses der Entwickler auch die beste Wahl. Apples iOS ist allerdings auch nicht zu vernachlässigen. Daher ist es überlegenswert, in Zukunft die clientseitigen Framework-Teile von Mobilis auf iOS zu portieren.

78 7 Evaluierung

In Aufgabe 3 des Fragebogens galt es, den Bedarf eines Frameworks im Mobile-Software- Bereich zu klären. Daher sollten die Befragten ihre persönliche Einstellung gegenüber der Aussage einschätzen, dass Mobile Social Software oft gleiche oder ähnliche Features aufweist und daher ein Framework, das diese Features anbietet, sinnvoll wäre. 97% der Befragten stehen der Aussage neutral bis zustimmend gegenüber. Dies zeigt also, dass fast alle Umfrageteilnehmer durchaus einen Bedarf an Frameworks im Mobile-Software-Bereich sehen. Im zweiten Teil der Frage, sollte der Bekanntheitsgrad des Mobilis Framework ermittelt werden. Leider gaben nur 9% der Befragten an, Mobilis zu kennen und darüber nachgedacht zu haben, es in ihrer Anwendung zu benutzen. Letztlich hat nur ein Team (entspricht 6%) tatsächlich Komponenten aus Mobilis in einer mobilen Anwendung eingesetzt. Die Unbekanntheit von Mobilis liegt sicherlich daran, dass die Komponenten des Frameworks und die damit verbundenen Erleichterungen nicht ausreichend vorgestellt wurden. Es wurde lediglich auf die Projekt-Website und Dokumentation verwiesen, die zum Zeitpunkt der Technologieauswahl im Seminar allerdings noch nicht komplett umgesetzt waren. Weiterhin kamen im Rahmen dieser Arbeit auch Framework-Komponenten hinzu, die zu diesem Zeitpunkt noch nicht realisiert waren. Abbildung 67 veranschaulicht die Ergebnisse der allgemeinen Fragen zu Frameworks im Bereich von Mobile Social Software.

Mobile Social Software often has the same or similar features. Therefore a framework providing these features would be useful.

I know the Mobilis Framework and I have considered using it in my recently developed application.

0% 20% 40% 60% 80% 100% agree neutral disagree

Abbildung 67: Ergebnis der Fragen bezüglich Frameworks im Mobile-Software-Bereich.

Die vierte Aufgabe des Fragebogens gab den Befragten die Möglichkeit, fehlende Features des Mobilis-Projektes zu nennen. Aufgrund der eben herausgearbeiteten Unbekanntheit, gab es nur zwei Hinweise. Als erstes wurde der Wunsch geäußert, dass die Einstellungen und Daten des serverseitigen Frameworks über ein Webinterface zur Laufzeit manipulierbar gemacht werden sollen. Der zweite Hinweis zielt auf eine einfachere Verwaltung des XMPP Roster ab. Mithilfe eines BuddyManager soll das Blockieren von Nutzern sowie das Hinzufügen bzw. Löschen von Freunden zur bzw. von der Kontaktliste realisiert werden.

79 7 Evaluierung

Die Fragen zwei und fünf stellen einen weiteren wichtigen Teil der Umfrage dar. Hier geht es um die Wichtigkeit bestimmter Features im Bereich von Mobile Software aber auch bzgl. der konkret im Seminar umgesetzten Anwendungen. Zuerst bestand die Aufgabe, die Wichtigkeit der folgenden Feature-Kategorien im allgemeinen Kontext mobiler Software zu bewerten: soziale und ortbasierte Features, Kommunikations- und Kooperationsfeatures sowie spielerische Features. Die Befragten konnten die jeweiligen Kategorien auf einer vierstufigen Likert-Skala von „nutzlos― bis hin zu „sehr wichtig― einschätzen. Die Ergebnisse dieser Aufgabe sind in Abbildung 68 veranschaulicht.

Social features

Location features

Communication features

Cooperation features

Gaming features

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

useless very important

Abbildung 68: Ergebnis der Frage: „How do you rate the importance of the following feature categories in the general scope of mobile social software?―

Als allgemeines Resultat dieser Frage wird deutlich, dass alle vorgeschlagenen Feature- Kategorien von fast allen Befragten als in irgendeiner Art nützlich bewertet worden sind. Lediglich die Cooperation Features und Gaming Features wurden von 6% der Befragten als nutzlos eingestuft. Es ist allerdings trotzdem eine Gewichtung der Bedeutung der Feature-Kategorien für Mobile Software erkennbar. So sehen 97% der Befragten den Ortsbezug in mobilen Anwendungen als wichtiges oder sogar sehr wichtiges Merkmal. Mit 91% ist bei den Kommunikations-Features ein ähnlich hoher Wert zu verzeichnen. Soziale Merkmale wie Freunde und Gruppen wurden immerhin von 75% als wichtig oder sehr wichtig eingestuft. Die Cooperation Features und Gaming Features schneiden im Vergleich zu den anderen Kategorien deutlich schlechter ab. Für die befragten Entwickler scheinen kollaborative und spielerische Elemente also durchaus spezieller zu sein als Merkmale der anderen Kategorien. Aber immerhin halten sich die Prozentwerte für eine eher wichtige mit denen für eine eher unwichtige Einschätzung dieser Kategorien die Waage (siehe Abbildung 68).

80 7 Evaluierung

Die Schlussfolgerung aus dieser Teilaufgabe für das Mobilis-Projekt lautet nun, dass der Fokus eindeutig auf ortsbasierten und sozialen Features sowie Kommunikations-Features liegt. Welche genauen Merkmale die Befragten damit meinen, wurde in der Teilaufgabe 2b des Fragebogens ermittelt, die im Folgenden ausgewertet wird. Die Studierenden sollten hierbei für jede Feature-Kategorie aus einer Auswahl von vorgegebenen Merkmalen das wichtigste auswählen oder einen eigenen Vorschlag machen.

Social features

23% Friends

37% Groups

Events

Integration of external 20% social networks

20%

Abbildung 69: Die wichtigsten sozialen Features bezüglich Mobile Software.

Wie man in Abbildung 69 erkennen kann, ist die Verteilung der vier vorgeschlagenen sozialen Features relativ gleichmäßig, wobei als die wichtigste Eigenschaft mobiler Anwendungen die Integration externer Netzwerke wie Facebook oder Foursquare ausgewählt wurde. Im Mobilis-Projekt sorgt der Social Network Service (siehe Abschnitt 5.2) innerhalb des clientseitigen Frameworks für ebendiese Funktionalität. Die Verwaltung von Gruppen und Ereignissen wurde von jeweils 20% der Befragten als wichtigstes Feature erachtet. Dafür kann im Mobilis-Projekt der extra dafür konzipierte Grouping Service (siehe Abschnitt 5.4.3) des MobilisServer eingesetzt werden. Für die Verwaltung der eigenen Freundesliste bietet Mobilis selbst keine Funktionen an. Da Mobilis jedoch auf XMPP beruht, kann für Freundeslisten der XMPP Roster benutzt werden. Wie schon zuvor angesprochen, ist eine einfache Möglichkeit zur Verwaltung der Buddylist (Hinzufügen, Blockieren und Löschen von Freunden, Autorisierungen erteilen) in Mobilis- Anwendungen wünschenswert. Abbildung 70 zeigt, dass die Stimmverteilung bei den ortsbezogenen Features viel klarer ist. 70% der Befragten halten die Navigation zu Freunden oder anderen Orten als die wichtigste Funktionalität. Im Mobilis-Projekt gibt es dafür jedoch keine zu verwendende Komponente. Allerdings ermöglicht die Android-Plattform das Starten von beliebigen anderen installierten Programmen mithilfe des Intent-Mechanismus. Wenn ein Navigationsprogramm installiert

81 7 Evaluierung ist, ließe sich diese Funktion also auch innerhalb von Mobilis-Anwendungen nutzen. Um die Position von Freunden oder besonderen Orten zu verwalten (17%) und Proximity Detection (3%) oder Umgebungssuchen (3%) durchzuführen, könnte der generische User Context Service des MobilisServer verwendet werden. Ein Nutzer müsste dort nur kontinuierlich seinen aktuellen Aufenthaltsort veröffentlichen. Der User Context Service würde andere Nutzer über Änderungen informieren oder andere (anwendungsspezifische) Dienste könnten die dort hinterlegten Daten verwenden, um z.B. die Nähe zu anderen Objekten zu ermitteln und gegebenenfalls Proximity Alerts zu versenden. Das Anreichern von Mediendateien mit Geoinformationen wurde nur von 7% der Befragten als wichtigstes ortsbezogenes Feature ausgewählt. Im Mobilis-Projekt gibt es die bereits in Abschnitt 7.1.4 beschriebene Anwendung MobilisMedia, die genau diese Funktion umsetzt. Sie benutzt dafür die serverseitigen Dienste Repository Service und Content Service (siehe Abschnitt 5.4.4).

Location features Show position of friends or 17% special places Proximity alert (friends, 3% places, …) 3% Vicinity search (for friends, 7% places, …) Geotagging of pictures and 70% videos Navigation (to friends, places, …)

Abbildung 70: Die wichtigsten Location Features bezüglich Mobile Software.

Bei der Wahl des wichtigsten Kommunikationsmittels innerhalb mobiler Anwendungen (siehe Abbildung 71) haben mit knappem Vorsprung die Systeme mit synchroner Zustellung wie z.B. Instant Messaging den größten Anteil. Das Versenden von Textnachrichten und Verfügbarkeitsinformationen ist dank der clientseitigen XMPP Services leicht in Mobilis- Anwendungen möglich. In einem Mehrbenutzerchat ist auch synchrone Kommunikation möglich. Für einen Multi-User Chat sprachen sich allerdings nur 3% der Studierenden aus. Die in Abschnitt 5.3 besprochenen XMPP Services erlauben eine leichte Integration von Mehrbenutzerchaträumen in mobilen Anwendungen. Asynchrone Kommunikation (z.B. Email, Nachrichtenzustellung) wurde von 37% der Befragten als wichtigstes Feature dieser Kategorie ausgewählt. Wie bereits zuvor herausgestellt wurde, konzentriert sich das Mobilis-Projekt eher auf synchrone Kommunikation und bietet daher keine asynchronen Mechanismen an.

82 7 Evaluierung

Communication features

17% Asynchronous (Email, Messages) Synchronous (Chat, Instant 3% 37% Messaging, Presence) 3% Multi-User Chat

File sharing

Media sharing (photos, 40% videos, music)

Abbildung 71: Die wichtigsten Communication Features bezüglich Mobile Software.

Das Veröffentlichen und Verteilen von Mediendaten wie Bildern, Video und Musik wurde von 17% der Umfrageteilnehmer als sehr wichtig erachtet. Im entwickelten Framework setzt die Anwendung MobilisMedia (siehe Abschnitt 7.1.4) diese Funktion um. Die allgemeinere Form des File Sharing fand mit 3% nur wenig Anklang bei den Entwicklern. Mithilfe des File Transfer Service (siehe Abschnitt 5.3) ist das Austauschen beliebiger Dateien im Mobilis-Projekt möglich.

Collaboration features

27% Shared Editing (of text or other documents) Shared Drawing (Shared Whiteboards)

73%

Abbildung 72: Die wichtigsten kollaborativen Features bezüglich Mobile Software.

Mit 73% der Stimmen ist das gemeinsame Bearbeiten von Text oder anderen Dokumenten das wichtigste Feature im Bereich Kollaboration. Die restlichen 27% wählten die speziellere

83 7 Evaluierung

Form des gemeinsamen Zeichnens (z.B. auf einem Whiteboard). Beide Funktionen sind in Mobilis-Anwendungen mit dem Collaborative Editing Service (siehe 5.4.5) umsetzbar. Als Beispielanwendung zählt MobilisMapDraw (siehe 7.1.3). Gaming Features deckt das Mobilis-Framework bisher nicht ab. In den Anwendungen MobilisXHunt und MobilisLocPairs mussten alle spielerischen Elemente wie z.B. die Bestenliste neu entwickelt werden. Diese high score list wurde von der Hälfte der befragten Entwickler zum wichtigsten Element gewählt. 44% gaben an, dass das Sammeln von Punkten oder anderen Gegenständen die wichtigste Funktion in Mobile Games ist. Als andere Funktionen wurden ein Mehrspielermodus und das Erreichen bestimmter Errungenschaften genannt (siehe Abbildung 73).

Gaming features

3% 3%

Collect / earn points or items High score list 44%

Multiplayer

50% Achievements

Abbildung 73: Die wichtigsten spielerischen Merkmale bezüglich Mobile Software.

Zuvor wurde festgestellt, dass Gaming Features in Relation zu den anderen Kategorien als unwichtig deklariert wurden. Daher gilt es zu prüfen, ob Elemente dieser Kategorie zukünftig vom Mobilis-Framework angeboten werden sollten oder nicht. In Aufgabe 5 wurden die Studierenden erneut mit den Feature-Kategorien und Features aus Aufgabe 2 konfrontiert. Dieses Mal bestand die Aufgabe darin, speziell die Nützlichkeit der Merkmale für ihre kürzlich entwickelte mobile Anwendung einzuschätzen. Weiterhin sollten die Merkmale angekreuzt werden, die bereits implementiert wurden. Nun ist es durchaus interessant zu untersuchen, welche vom Mobilis-Framework unterstützten Features als nützlich markiert, aber nicht in den Anwendungen der Studierenden implementiert wurden. Denn diesen Entwicklern könnte unter Umständen geraten werden, das Mobilis-Framework zu verwenden, um die gewünschten Features leicht umzusetzen. Das Ergebnis dieser Untersuchung ist in Abbildung 74 zu sehen. Die Verwaltung von Gruppen und ein Mehrbenutzerchat werden in 41% bzw. 38% der Anwendungen als nützlich eingestuft, wurden jedoch nicht implementiert. Mit Mobilis wäre eine solche Feature-Integration in vielen Fällen sicherlich einfach möglich. Bei der

84 7 Evaluierung

Integration externer sozialer Netzwerke könnte Mobilis bei einem Viertel der Anwendungen behilflich sein. Auch die kollaborativen Funktionen würden in einem Teil der Anwendungen (28% Shared Editing, 16% Shared Drawing) zusätzlichen Nutzen bringen, aber sie wurden sicherlich aufgrund der hohen Komplexität nicht umgesetzt. Einige Funktionen wie Media Sharing (28%) und Geotagging (22%) wurden auch bereits in Mobilis-Anwendungen wie MobilisMedia umgesetzt. Beispielanwendungen, bei denen die Nutzung der Framework- Komponenten demonstriert wird, sind also auch vorhanden.

Useful rated Mobilis features that were not implemented

Shared Editing 28% Shared Drawing (Whiteboard) 16% Multi-User Chat 38% File sharing 19% Media sharing (photos, videos, music) 28% Geotagging of pictures and videos 22% Friends 34% Groups 41% Events 28% Integration of social networks 25% 0% 10% 20% 30% 40% 50% percentage of developers

Abbildung 74: Von Mobilis explizit angebotene Features, die als nützlich bewertet und nicht implementiert markiert wurden.

Zum Abschluss zeigt Abbildung 75 den Anteil der Entwickler, die mindestens ein Mobilis- Feature als nützlich für ihre Anwendung erachten und die es aber nicht umgesetzt haben. In über der Hälfte der Projekte (56,25%) würden die Entwickler also unter Umständen vom Mobilis-Framework profitieren. Diese Zahl ist jedoch durchaus kritisch zu betrachten, denn einige Framework-Komponenten lassen sich lediglich innerhalb von Android-Projekten und nicht auf anderen Smartphone-Betriebssystemen nutzen. Weiterhin ist es auch möglich, dass einzelne Mobilis-Features auch mit anderen Frameworks oder Bibliotheken schneller und effizienter umzusetzen sind.

Developers who would benefit from Mobilis

Benefit 56,25% 43,75% yes no 0% 20% 40% 60% 80% 100%

Abbildung 75: Anteil der Entwickler, die vom Mobilis-Projekt profitieren könnten.

85 7 Evaluierung

7.4 Fazit Der erste Teil dieses Kapitels zeigte, dass die Server- und Client-seitigen Komponenten des entwickelten Mobilis-Frameworks bereits in zahlreichen prototypischen Beispiel- anwendungen eingesetzt werden. Diese Anwendungen wurden zum größten Teil nicht im Rahmen dieser Arbeit konzipiert und implementiert, sondern nur in Teilaspekten an die erneuerten Framework-Komponenten angepasst. Sie wurden kurz vorgestellt und deren Funktion wurde anhand von Screenshots veranschaulicht. Die im zweiten Teil durchgeführte Umfrage hat gezeigt, dass der generelle Bedarf an Frameworks für leichtere und schnellere Umsetzung mobiler Anwendungen bei den Entwicklern vorhanden ist. Leider ist es so, dass vielen Entwicklern das Mobilis-Projekt unbekannt war und sie sich deshalb nicht damit beschäftigt haben. Weiterhin wurde deutlich, dass die Wahl von Android als Grundlage des clientseitigen Frameworks eine sehr gute war, denn die Sympathie für dieses Smartphone-Betriebssystem war bei den befragten Entwicklern sehr hoch. Die von den Befragten als sehr wichtig für Mobile Software eingestuften Features kommen aus den Bereichen Social, Location und Communication. In der Kategorie der sozialen Features konnte gezeigt werden, dass Mobilis fast alle wichtigen Merkmale unterstützt. Auch ortsbasierte Funktionen lassen sich mit den vorhandenen Diensten umsetzen. Da Mobilis bei der Kommunikation auf XMPP setzt und dabei Erweiterungen wie Mehrbenutzerchats umsetzt, werden auch fast alle Kommunikations-Features angeboten. Zuletzt wurde gezeigt, dass über die Hälfte der befragten Entwickler vom Mobilis-Projekt profitieren könnten. Natürlich ist es nicht in allen diesen Fällen sinnvoll, das Mobilis- Framework einzusetzen, aber den Entwicklern kann zu einer tiefgründigen Beschäftigung mit den entsprechenden Framework-Komponenten geraten werden.

86 8 Zusammenfassung und Ausblick

8 Zusammenfassung und Ausblick Zu Beginn dieser Arbeit wurde ein Überblick über den Bereich Mobile Social Software gegeben. Dazu wurden sowohl kommerzielle Produkte als auch Forschungsarbeiten beleuchtet. Als Ergebnis dieser Analyse konnte festgestellt werden, dass viele Anwendungen sich stark ähnelnde Teilfunktionen anbieten. Diese mussten bisher für jede Applikation von Grund auf neu konzipiert und implementiert werden. Auch in der zum Abschluss dieser Arbeit durchgeführten Umfrage sprach sich ein Großteil der befragten Entwickler für den Einsatz von Frameworks zur schnelleren und effizienteren Entwicklung mobiler Anwendungen aus. Solche Framework-Ansätze existieren auch bereits und einige Systeme aus dem Forschungsbereich wurden in dieser Arbeit detailliert betrachtet. In den darauffolgenden Kapiteln wurden die Anforderungen an das zu entwickelnde Framework festgelegt und die zur Umsetzung der Dienstumgebung einsetzbaren Technologien beleuchtet. Als Grundlage dieser Arbeit diente die am Lehrstuhl Rechnernetze der TU Dresden entwickelte Mobilis-Plattform. Auf dieser Plattform wurden bereits mehrere Anwendungen und Server-Dienste für verschiedene Teilbereiche von Mobile Social Software umgesetzt. Ein anwendungsübergreifendes Dienstkonzept fehlte jedoch bisher. Im Konzepte-Kapitel dieser Arbeit wurde dann unter anderem die Architektur der Framework-Komponenten erarbeitet. Bereits bestehende Teile des Mobilis-Projekts wurden eingegliedert sowie teilweise überarbeitet und neue Komponenten kamen hinzu. Das darauffolgende Kapitel umfasst implementationsspezifische Details und Aspekte sowie die Lösungen zu Problemen, die bei der Umsetzung des Konzeptes auftraten. Abschließend erfolgte eine Bewertung der Ergebnisse dieser Arbeit. Dazu wurde zu allererst die Funktion der umgesetzten Framework-Komponenten nachgewiesen, indem Beispiel- anwendungen und Prototypen demonstriert wurden. Weiterhin konnte festgestellt werden, dass fast alle in der Anforderungsanalyse besprochenen Features umgesetzt wurden. Das Framework wurde abschließend noch mit bestehenden Frameworks für Mobile Social Software verglichen. Daraufhin wurde untersucht, in welchem Umfang die Entwickler mobiler Applikationen überhaupt vom Mobilis-Framework profitieren können. In der dafür durchgeführten Umfrage kam heraus, dass Mobilis die meisten Features unterstützt, die die befragten Entwickler als wichtig erachten. Außerdem konnte ermittelt werden, dass sich einige Teile von Mobilis in über der Hälfte der zuletzt von den befragten Entwicklern erstellten Anwendungen als hilfreich herausstellen könnte. Zum Abschluss der Arbeit kann nun festgestellt werden, dass mit Mobilis ein durchaus wiederverwendbares Framework geschaffen wurde, das in vielen Anwendungsszenarien eine schnelle und effiziente Entwicklung mobiler Applikationen ermöglicht. Eine Weiterentwicklung und Verbesserung des aktuellen Standes ist jedoch an mehreren Stellen möglich. So wäre zum Beispiel die Umsetzung der noch offen gebliebenen Anforderungen denkbar. Hierbei ist die Anforderung der dynamischen Gruppenbildung (FA-7.2) zu nennen, nach der ein Nutzer automatisch anhand seiner Position in bestimmten ortsbasierten Gruppen ein-

87 8 Zusammenfassung und Ausblick oder ausgeschrieben wird. Außerdem ist auch eine Weiterentwicklung des User Context Service (siehe Abschnitt 5.4.2), der bereits nach dem Publish/Subscribe-Verfahren arbeitet, hin zu einem generischen Publish Subscribe Service (FA-11) denkbar. Damit könnten dann nicht nur Daten des Nutzerkontextes, sondern beliebige Informationen wie Verkehrs- oder Aktien-Updates in der Nutzergemeinde verteilt werden. Weiterhin wurde in der durchgeführten Umfrage der Wunsch nach einem BuddyManager geäußert, mit dem sich der XMPP Roster schnell und einfach verwalten lässt. Werden die serverseitigen Mobilis-Dienste von sehr vielen Nutzern zur gleichen Zeit verwendet, spielt auch die Performance eine wichtige Rolle. Eine entsprechende Analyse der Skalierbarkeit wurde bisher noch nicht durchgeführt, wäre aber sehr hilfreich um die praktische Einsatzmöglichkeit besser einschätzen zu können. Die in dieser Arbeit durchgeführte Befragung von Entwicklern wurde sehr allgemein gehalten, da ein Großteil der Befragten das Mobilis-Framework nicht kannte. Somit konnte zwar ermittelt werden, dass Mobilis die meisten wichtigen Features unterstützt und in vielen Anwendungsfällen hilfreich sein könnte, aber eine genauere und umfassendere Evaluierung der einzelnen Framework-Komponenten war daher nicht möglich. Deshalb sollten in Zukunft die einzelnen Komponenten und Einsatzmöglichkeiten des Frameworks einer anderen Entwicklergruppe vorgestellt werden, die dann nach der Anwendungsentwicklung mit und ohne Framework die Zeitersparnis, den Einarbeitungsaufwand, die Güte der Dokumentation und andere Aspekte genau einschätzt. Aufgrund dieser Umfragedaten ließen sich dann die konkreten Framework-Teile verbessern und andere gewünschte Komponenten hinzufügen. Im Mobilis-Projekte wurde sich bewusst für eine klassische Client-Server-Architektur entschieden, damit rechenintensive Aufgaben statt auf dem mobilen Endgerät auf einem leistungsstarken Server durchgeführt werden können. Weiterhin vereinfacht dieser Ansatz auch die Kommunikation, da jeder Teilnehmer nur die eine Verbindung zum Server verwalten muss. Da jedoch die Rechenleistung moderner Smartphones und anderer Geräte wie Tablet-PCs ständig anwächst und da Mobilfunkverbindungen immer höhere Geschwindigkeiten anbieten und in Flatrate-Modellen abgerechnet werden, ist es durchaus überlegenswert, auf den zentralen Server, der einen Single Point of Failure darstellt, zu verzichten. Sowohl der XMPP Server als auch die generischen Mobilis Services könnten auf die Clients ausgelagert werden. Dies würde die Nutzung einer Peer-to-Peer-Umgebung ermöglichen, in der vorher abgestimmt werden müsste, welcher Peer die Server-Rolle übernimmt. In diese Abstimmung sollten auch Informationen zum Akkufüllstand und zur Netzwerkanbindung der einzelnen Clients eingehen. Fällt nun der Peer mit Server-Rolle aus, so muss die Abstimmung erneut gestartet werden. Durch diesen Ansatz ergibt sich also eine höhere Flexibilität. Auf der anderen Seite stehen diesem Vorteil die wahrscheinlich deutlich schlechtere Performance und der höhere Aufwand auf dem Client mit Server-Rolle gegenüber. Die Nutzung der serverseitigen Framework-Komponenten ist dank des plattformunabhängigen Ansatzes mit XMPP nicht nur aus Mobilis-Anwendungen heraus möglich. Momentan wird im Mobilis-Projekt an einem Web-Gateway für die Dienste des MobilisServer gearbeitet. Damit könnte der Zugriff auf diese Dienste von beliebigen

88 8 Zusammenfassung und Ausblick

Endgeräten aus erfolgen. Eventuell müssen damit die plattformabhängigen clientseitigen Mobilis-Komponenten zum Ansprechen der serverseitigen Dienste nicht auf andere Smartphone-Betriebssysteme wie Apples iOS portiert werden, um sie auch dort nutzbar machen.

89

Anhang

Anhang Leerer Fragebogen zur in Abschnitt 7.3 beschriebenen Umfrage zum Entwicklernutzen.

I Anhang

II Anhang

III Anhang

Ergebnisse der in Abschnitt 7.3 beschriebenen Umfrage zum Entwicklernutzen.

IV Anhang

V Anhang

VI Abbildungsverzeichnis

Abbildungsverzeichnis Abbildung 1: Statistik zu Marktanteilen verschiedener Smartphone-Betriebssysteme in den USA. Quelle: [NC10a] ...... 2 Abbildung 2: Architektur von CenceMe Smartphone Software (links) und Backend Server (rechts). Quelle: [MLF+08] ...... 8 Abbildung 3: Architektur der SAMOA Middleware. Quelle: [DBRMAT07] ...... 11 Abbildung 4: MobiSoc-Architektur. Quelle: [GKBB09]...... 12 Abbildung 5: Architektur des MobiClique-Systems. Quelle: [POL+09] ...... 13 Abbildung 6: XML-Darstellung eines Beispiel-IQ...... 22 Abbildung 7: Senden einer Gruppennachricht...... 23 Abbildung 8: Der MUC-Dienst leitet Gruppennachrichten an alle Teilnehmer des Raumes weiter...... 23 Abbildung 9: Service Discovery IQ zur Abfrage von Informationen zu einem XMPP-Nutzer...... 24 Abbildung 10: Antwort auf ein Service Discovery IQ...... 24 Abbildung 11: Subscribe IQ zum Abonnieren von Informations-Updates. Vgl. [MSAM10] 25 Abbildung 12: Publish IQ zum Veröffentlichen eines Informations-Updates. Vgl. [MSAM10] ...... 25 Abbildung 13: Benachrichtigung über ein Informationsupdate. Vgl. [MSAM10] ...... 25 Abbildung 14: Architektur von Webservices ...... 27 Abbildung 15: Allgemeine Architektur ...... 29 Abbildung 16: Architekturkonzept der Mobilis Client Services ...... 31 Abbildung 17: Hauptfunktionen der XMPP Services ...... 32 Abbildung 18: Dienste auf dem MobilisServer ...... 33 Abbildung 19: Ein leeres MobilisServiceDiscoveryIQ zur Abfrage aller aktiven Dienste. ... 34 Abbildung 20: Die Antwort enthält eine Auflistung aller aktiven Mobilis Services...... 34 Abbildung 21: MobilisServiceDiscoveryIQ zur Suche nach einem bestimmten Dienst...... 35 Abbildung 22: Die Antwort enthält nur Dienste mit dem gesuchten Namespace bzw. der gesuchten Versionsnummer...... 35 Abbildung 23: CreateNewServiceInstanceIQ zum Erstellen einer neuen Dienstinstanz...... 36 Abbildung 24: Die Antwort enthält die JID des neuen Dienstes...... 37 Abbildung 25: Ablauf beim Erstellen einer neuen Dienstinstanz...... 37 Abbildung 26: Kontextbaum mit Beispieleinträgen ...... 39 Abbildung 27: Ablauf des Subscribe-Verfahrens ...... 40

VII Abbildungsverzeichnis

Abbildung 28: SubscribeIQ vom Typ Set...... 40 Abbildung 29: AuthorizationIQ vom Typ Get...... 40 Abbildung 30: AuthorizationIQ vom Typ Result...... 41 Abbildung 31: SubscribeIQ vom Typ Result und die an den neuen Abonnenten gesendete Nachricht mit dem aktuellen Informationsstand...... 41 Abbildung 32: UnsubscribeIQ vom Typ Set...... 42 Abbildung 33: Ablauf des Unsubscribe-Verfahrens...... 42 Abbildung 34: Ablauf des Publish-Verfahrens...... 43 Abbildung 35: PublishIQ vom Typ Set...... 43 Abbildung 36: Die XMPP Message, mit der alle Abonnenten über das Update informiert werden...... 43 Abbildung 37: Die Informationen aus bestimmten Nachrichtenarten werden vom User Context Service automatisch in die passenden Knoten des Context Tree gespeichert... 44 Abbildung 38: GroupQueryIQ vom Typ Get...... 46 Abbildung 39: GroupQueryIQ vom Typ Result...... 46 Abbildung 40: Aufrufabläufe von Repository Service und Content Service in verschiedenen Anwendungsfällen. Quelle: [BS09] ...... 47 Abbildung 41: Ausgetauschte IQs bei Repository Service und Content Service. Quelle: [BS09] ...... 48 Abbildung 42: Überblick über eine Collaboration Session. Quelle: [DH09] ...... 49 Abbildung 43: Übersicht der wichtigsten Attribute und Methoden von Mobilis Beans...... 51 Abbildung 44: Übersicht über Komponenten innerhalb von Mobilis Beans...... 52 Abbildung 45: Adapterschichten in Android und Java zur Nutzung der gleichen Mobilis Beans...... 53 Abbildung 46: Paketübersicht des kompletten Mobilis-Projektes...... 54 Abbildung 47: Konfiguration der Mobilis Agents...... 56 Abbildung 48: Konfiguration der Mobilis Services...... 57 Abbildung 49: Programmcodeausschnitt zur Erstellung neuer Instanzen anwendungsspezifischer Dienste...... 58 Abbildung 50: Verändern von mit Hibernate persistent gemachten Java Objekten...... 59 Abbildung 51: IQ vom Typ Error...... 60 Abbildung 52: Erstellen, Signieren und Abschicken einer API-Anfrage...... 61 Abbildung 53: Ausschnitt der Antwort der Qype API auf die Anfrage http://api.qype.com/v1/positions/51.0489,13.7405/places.json ...... 61

VIII Abbildungsverzeichnis

Abbildung 54: Klassendiagramm der Qype Komponenten im Social Network Service...... 62 Abbildung 55: MobilisContext erlaubt das Veröffentlichen von verschiedenen Arten von Kontextinformationen...... 64 Abbildung 56: Anwendungseinstellungen in MobilisContext (e) und der Subscribe-Dialog (f).Wird auf Client-2 (g) eine neue Kontextinformation veröffentlicht, so erhalten alle Abonnenten eine entsprechende Benachrichtigung (h)...... 65 Abbildung 57: Ausschnitt der Benutzeroberfläche von MobilisGroups. Quelle: [RL10] ..... 66 Abbildung 58: MobilisMapDraw ermöglicht kollaboratives Zeichnen auf Landkarten und Shared Whiteboards...... 68 Abbildung 59: Benutzeroberfläche von MobilisMedia...... 69 Abbildung 60: Anzeige des „Spielfeldes― und der zusätzlichen Spielinformationen...... 70 Abbildung 61: Auswahl des nächsten Ziels und Anzeige der Abfahrten...... 71 Abbildung 62: Benutzeroberfläche von MobilisLocPairs. Quelle: [NHBMRM+11] ...... 72 Abbildung 63: Benutzeroberfläche von Social Network Service Example...... 74 Abbildung 64: MobilisBuddy erkennt Situationen, in denen sich Freunde in der Nähe aufhalten und gibt entsprechende Benachrichtigungen aus...... 75 Abbildung 65: Antwortverteilung auf die Frage: „Which mobile operating system / platform did you implement your application for?― ...... 77 Abbildung 66: Antwortverteilung auf die Frage: „Why did you choose this operating system?― ...... 78 Abbildung 67: Ergebnis der Fragen bezüglich Frameworks im Mobile-Software-Bereich. . 79 Abbildung 68: Ergebnis der Frage: „How do you rate the importance of the following feature categories in the general scope of mobile social software?― ...... 80 Abbildung 69: Die wichtigsten sozialen Features bezüglich Mobile Software...... 81 Abbildung 70: Die wichtigsten Location Features bezüglich Mobile Software...... 82 Abbildung 71: Die wichtigsten Communication Features bezüglich Mobile Software...... 83 Abbildung 72: Die wichtigsten kollaborativen Features bezüglich Mobile Software...... 83 Abbildung 73: Die wichtigsten spielerischen Merkmale bezüglich Mobile Software...... 84 Abbildung 74: Von Mobilis explizit angebotene Features, die als nützlich bewertet und nicht implementiert markiert wurden...... 85 Abbildung 75: Anteil der Entwickler, die vom Mobilis-Projekt profitieren könnten...... 85

IX Tabellenverzeichnis

Tabellenverzeichnis

Tabelle 1: Zusammenfassung funktionaler Anforderungen ...... 18 Tabelle 2: Zusammenfassung Geräteanforderungen ...... 19 Tabelle 3: Zusammenfassung nichtfunktionaler Anforderungen ...... 20 Tabelle 4: Mögliche Fehlerfälle bei MobilisServiceDiscoveryIQs...... 36 Tabelle 5: Mögliche Fehlerfälle bei CreateServiceInstanceIQs...... 38 Tabelle 6: Mögliche Fehlerfälle bei SubscribeIQs...... 41 Tabelle 7: Mögliche Fehlerfälle bei UnsubscribeIQs...... 42 Tabelle 8: Mögliche Fehlerfälle bei PublishIQs...... 44 Tabelle 9: Vergleich von Mobilis mit den gestellten Anforderungen und anderen Frameworks...... 76

X Abkürzungsverzeichnis

Abkürzungsverzeichnis Abk. Abkürzung AIDL Android Interface Definition Language bspw. beispielsweise bzw. beziehungsweise d. h. das heißt engl. englisch etc. et cetera GPS Global Positioning System GSM Global System for Mobile Communications GUI Graphical User Interface HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force IQ Info / Query JID Jabber Identifier, oft auch XMPP Identifier genannt LBG Location Based Game MAC Media Access Control MoSoSo Mobile Social Software MSN oder Mobile Social Networking MXA Mobilis XMPP on Android PubSub Publish / Subscribe RPC Remote Procedure Call SASL Simple Authentication and Security Layer SN Social Network, soziales Netzwerk TCP Transmission Control Protocol TLS Transport Layer Security u. a. unter anderem UDDI Universal Description, Discovery and Integration UMTS Universal Mobile Telecommunications System vgl. vergleiche W3C World Wide Web Consortium WSDL Web Services Description Language XEP XMPP Extension Protocol XML Extensible Markup Language XMPP Extensible Messaging and Presence Protocol z. B. zum Beispiel

XI Literaturverzeichnis

Literaturverzeichnis [AANG11] Aka-Aki Networks GmbH, ―aka-aki,‖ http://www.aka-aki.com/, 2011. [ABKW08] M. Arb, M. Bader, M. Kuhn, and R. Wattenhofer, ―VENETA: Serverless Friend-of-Friend Detection in Mobile Social Networking,‖ in 4th IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), Avignon, France, 2008. [AG07] Ansgar Gerlicher, ―Developing Collaborative XML Editing Systems,‖ PhD thesis, University of the Arts London, 2007. [AS05] Aleksander Slominski, ―Xml pull parser,‖ May 2005. [Online]. Available: http://- www.xmlpull.org/ [ASL+09] A. Ankolekar, G. Szabo, Y. Luon, B. A. Huberman, D. Wilkinson, and F. Wu, ―Friendlee: A Mobile Application for Your Social Life,‖ in MobileHCI ’09: Proceedings of the 11th International Conference on Human-Computer Interaction with Mobile Devices and Services, Bonn, Germany, 2009. [BGA+08] A. Beach, M. Gartrell, S. Akkala, J. Elston, J. Kelley, K. Nishimoto, B. Ray, S. Razgulin, K. Sundaresan, B. Surendar, M. Terada, and R. Han, ―WhozThat? Evolving an ecosystem for context-aware mobile social networks,‖ IEEE Network, vol. 22, no. 4, pp. 50–55, July 2008. [BS09] Benjamin Söllner, ―XMPP-based Media Sharing for Mobile Collaboration with Android Phones,‖ Master‘s thesis, Technische Universität Dresden, Fakultät Informatik, October 2009. [Can11] Canalys, ―Google‘s Android becomes the world‘s leading smart phone platform,‖ January 2011. [Online]. Available: http://www.canalys.com/pr/2011/- r2011013.pdf [CH08] Clint Heyer, ―Mobile Social Software,‖ PhD thesis, The University of Queensland, April 2008. [CMRW07] R. Chinnici, J.-J. Moreau, A. Ryman, and S. Weerawarana, ―Web Services Description Language (WSDL) Version 2.0,‖ World Wide Web Consortium, Tech. Rep., June 2007. [Online]. Available: http://www.w3.org/TR/wsdl20/ [Cri10] D. Cridland, ―XEP-0286: XMPP on Mobile Devices,‖ XMPP Standards Foundation, Tech. Rep., September 2010. [Online]. Available: http://xmpp.org/extensions/xep- 0286.html [DBRMAT07] Dario Bottazzi, Rebecca Montanari, and Alessandra Toninelli, ―Context- Aware Middleware for Anytime, Anywhere Social Networks,‖ IEEE Intelligent Systems, vol. 22, pp. 23–32, 2007. [Dey01] A. K. Dey, ―Understanding and Using Context,‖ Personal Ubiquitous Comput., vol. 5, pp. 4–7, January 2001. [Online]. Available: http://dx.doi.org/- 10.1007/s007790170019

XII Literaturverzeichnis

[DH09] Dirk Hering, ―Entwicklung eines Dienstes für Real-time Collaborative Editing für die Mobilis-Plattform,‖ Master‘s thesis, Technische Universität Dresden, Fakultät Informatik, September 2009. [DK11] Danny Kiefner, ―Rundenbasierte ortsbezogene Spiele auf mobilen Endgeräten,‖ Master‘s thesis, Technische Universität Dresden, Fakultät Informatik, April 2011. [EI11] Ebay Inc., ―Ebay,‖ 2011. [Online]. Available: http://www.ebay.com [ESSS11] M. Endler, A. Skyrme, D. Schuster, and T. Springer, ―Defining Situated Social Context for Pervasive Social Computing,‖ in Second IEEE Workshop on Pervasive Collaboration and Social Networking (PerCol), Seattle, USA, March 2011. [FIL11a] Facebook Ireland Limited, ―Facebook,‖ 2011. [Online]. Available: http://- www.facebook.com [FIL11b] ——, ―Facebook Android SDK,‖ February 2011. [Online]. Available: https://github.com/facebook/facebook-android-sdk/ [Fou11]Foursquare, Inc., ―Foursquare,‖ 2011. [Online]. Available: http://foursquare.com/ [Gar08] C. M. Gartrell, ―SocialAware: Context-Aware Multimedia Presentation via Mobile Social Networks,‖ Master Thesis, University of Colorado, Department of Computer Science, 2008. [GG10] Google Gson, ―google-gson: A Java library to convert JSON to Java objects and vice-versa,‖ December 2010. [Online]. Available: http://code.google.com/p/google- gson/ [GHM+07] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. F. Nielsen, A. Karmarkar, and Y. Lafon, ―http://www.w3.org/tr/soap12-part1/,‖ World Wide Web Consortium, Tech. Rep., April 2007. [Online]. Available: http://www.w3.org/TR/- soap12-part1/ [GKBB09] A. Gupta, A. Kalra, D. Boston, and C. Borcea, ―MobiSoC: a middleware for mobile social computing applications,‖ Mobile Networks and Applications, vol. 14, pp. 35–52, 2009. [Goo11a] Google, ―Google Buzz,‖ 2011. [Online]. Available: http://- www.google.com/buzz [Goo11b] ——, ―Google Latitude,‖ 2011. [Online]. Available: http://- www.google.com/intl/en_us/latitude/intro.html [Gow11] Gowalla, Inc., ―Gowalla,‖ 2011. [Online]. Available: http://gowalla.com/ [HMESA08] J. Hildebrand, P. Millard, R. Eatmon, and P. Saint Andre, ―XEP-0030: Service Discovery,‖ http://xmpp.org/extensions/xep-0030.html, XMPP Standards Foundation, Tech. Rep., June 2008. [Online]. Available: http://xmpp.org/extensions/- xep-0030.html [IR11] Ignite Realtime, ―Smack API 3.1.0,‖ February 2011. [Online]. Available: http://- www.igniterealtime.org/projects/smack/

XIII Literaturverzeichnis

[JC11] JBoss Community, ―Hibernate. Relational Persistence for Java & .NET,‖ February 2011. [Online]. Available: http://www.hibernate.org/ [JG05] Q. Jones and S. A. Grandhi, ―P3 Systems: Putting the Place Back into Social Networks,‖ IEEE Internet Computing, vol. 9, pp. 38–46, 2005. [KSJ08] R. Kokku, K. Sundaresan, and G. Jiang, ―Enabling location specific real- time mobile applications,‖ in MobiArch ’08: Proceedings of the 3rd international workshop on Mobility in the evolving internet architecture, Seattle, WA, USA, 2008, pp. 19–24. [LSHG08] K. A. Li, T. Y. Sohn, S. Huang, and W. G. Griswold, ―Peopletones: a system for the detection and notification of buddy proximity on mobile phones,‖ in MobiSys ’08: Proceeding of the 6th international conference on Mobile systems, applications, and services, Breckenridge, CO, USA, 2008. [ML11] MeetMoi LLC, ―MeetMoi,‖ 2011. [Online]. Available: http://www.meetmoi.com [MLF+08] E. Miluzzo, N. D. Lane, K. Fodor, R. Peterson, H. Lu, M. Musolesi, S. B. Eisenman, X. Zheng, and A. T. Campbell, ―Sensing Meets Mobile Social Networks: The Design, Implementation and Evaluation of the CenceMe Application,‖ in The 6th ACM Conference on Embedded Networked Sensor Systems (Sensys), Raleigh, NC, USA, 2008. [MMC09] S. B. Mokhtar, L. McNamara, and L. Capra, ―A middleware service for pervasive social networking,‖ in M-PAC ’09: Proceedings of the International Workshop on Middleware for Pervasive Mobile and Embedded Computing, Urbana Champaign, Illinois, 2009. [MP11] Mobilis Project, ―Mobilis SVN Repository,‖ March 2011. [Online]. Available: https://mobilisplatform.svn.sourceforge.net/svnroot/mobilisplatform [MSAM10] P. Millard, P. Saint-Andre, and R. Meijer, ―XEP-0060: Publish-Subscribe,‖ XMPP Standards Foundation, Tech. Rep., July 2010. [Online]. Available: http://- xmpp.org/extensions/xep-0060.html [MSN05] M. Motani, V. Srinivasan, and P. S. Nuggehalli, ―PeopleNet: engineering a wireless virtual social network,‖ in MobiCom ’05: Proceedings of the 11th annual international conference on Mobile computing and networking, Cologne, Germany, 2005. [NC10a] Nielsen Company, ―Games Dominate America‘s Growing Appetite for Mobile Apps,‖ September 2010. [Online]. Available: http://blog.nielsen.com/- nielsenwire/online_mobile/games-dominate-americas-growing-appetite-for-mobile- apps/ [NC10b] ——, ―U.S. Smartphone Battle Heats Up: Which is the "Most Desired" Operating System?‖ December 2010. [Online]. Available: http://blog.nielsen.com/- nielsenwire/online_mobile/us-smartphone-battle-heats-up/

XIV Literaturverzeichnis

[NHBMRM+11] Norbert Harder, Beatrice Moltkau, Reik Müller, Tobias Reinsch, Benjamin Vetter, and Stefan Wagner, ―MobilisLocPairs,‖ February 2011. [Online]. Available: http://mobilisplatform.sourceforge.net/mobilislocpairs.htm [OS10] OAuth Signpost, ―Simple OAuth message signing for Java,‖ March 2010. [Online]. Available: http://code.google.com/p/oauth-signpost/ [POL+09] A.-K. Pietiläinen, E. Oliver, J. LeBrun, G. Varghese, and C. Diot, ―MobiClique: middleware for mobile social networking,‖ in WOSN ’09: Proceedings of the 2nd ACM workshop on Online social networks, Barcelona, Spain, 2009. [RL10] Robert Lübke, ―Mobile Social Networking - Location Based Group Formation,‖ Master‘s thesis, Technische Universität Dresden, Fakultät Informatik, October 2010. [SA04] P. Saint Andre, ―XEP-0128: Service Discovery,‖ XMPP Standards Foundation, Tech. Rep., October 2004. [Online]. Available: http://xmpp.org/extensions/xep- 0128.html [SA08a] ——, ―XEP-0045: Multi-User Chat,‖ XMPP Standards Foundation, Tech. Rep., July 2008. [Online]. Available: http://xmpp.org/extensions/xep-0045.html [SA08b] ——, ―XEP-0118: User Tune,‖ XMPP Standards Foundation, Tech. Rep., January 2008. [Online]. Available: http://xmpp.org/extensions/xep-0118.html [SAH09] P. Saint Andre and J. Hildebrand, ―XEP-0080: User Location,‖ XMPP Standards Foundation, Tech. Rep., September 2009. [Online]. Available: http://- xmpp.org/extensions/xep-0080.html [SAH10] ——, ―XEP-0277: Microblogging over XMPP,‖ XMPP Standards Foundation, Tech. Rep., January 2010. [Online]. Available: http://xmpp.org/- extensions/xep-0277.html [SAM08] P. Saint Andre and R. Meijer, ―XEP-0107: User Mood,‖ XMPP Standards Foundation, Tech. Rep., October 2008. [Online]. Available: http://xmpp.org/- extensions/xep-0107.html [SHSI08] S. Smaldone, L. Han, P. Shankar, and L. Iftode, ―Roadspeak: enabling voice chat on roadways using vehicular social networks,‖ in Proceedings of the 1st Workshop on Social Network Systems, ser. SocialNets ‘08. New York, NY, USA: ACM, 2008, pp. 43–48. [Online]. Available: http://doi.acm.org/10.1145/- 1435497.1435505 [SW10] Stiftung Warentest, ―Test: Soziale Netzwerke,‖ Zeitschrift test, vol. 04/2010, April 2010. [TMMMRE04] Thomas Muldowney, Matthew Miller, and Ryan Eatmon, ―XEP-0096: SI File Transfer,‖ XMPP Standards Foundation, Tech. Rep., 2004. [Online]. Available: http://xmpp.org/extensions/xep-0096.html [TS11] Thomas Springer, ―Application Development for Mobile and Ubiquitous Computing,‖ Lecture, February 2011. [Online]. Available: http://www.rn.inf.tu- dresden.de/lectures/ADfMaUC/6.%20Context%20Awareness.pdf

XV Literaturverzeichnis

[TTS09] H. Timenes, S. Tennant, and R. Savage, ―XEP-0255: Location Query,‖ XMPP Standards Foundation, Tech. Rep., April 2009. [Online]. Available: http://- xmpp.org/extensions/xep-0255.html [Twi11] I. Twitter, ―Twitter,‖ 2011. [Online]. Available: http://www.twitter.com [WAL11] Winterwell Associates Ltd., ―JTwitter - the Java library for the Twitter API,‖ February 2011. [Online]. Available: http://www.winterwell.com/software/jtwitter.php [xmp11] ―XMPP Standards Foundation,‖ March 2011. [Online]. Available: http://- www.xmpp.org [Yah11] Yahoo, ―Flickr,‖ 2011. [Online]. Available: http://www.flickr.com

XVI Eidesstattliche Erklärung

Eidesstattliche Erklärung Hiermit versichere ich, die vorliegende Arbeit selbständig, ohne fremde Hilfe und ohne Benutzung anderer als der von mir angegebenen Quellen angefertigt zu haben. Alle aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche gekennzeichnet.

Dresden, 15.03.2011

Robert Lübke.

XVII