ERSTELLUNG EINES FRAMEWORKS ZUR EFFIZIENTEN ENTWICKLUNG KOLLABORATIVER ECHTZEITANWENDUNGEN AUF MOBILEN GERÄTEN

Transkript

1 Fakultät Informatik, Institut für Systemarchitektur, Professur Rechnernetze Belegarbeit ERSTELLUNG EINES FRAMEWORKS ZUR EFFIZIENTEN ENTWICKLUNG KOLLABORATIVER ECHTZEITANWENDUNGEN AUF MOBILEN GERÄTEN Felix Wackernagel Mat.-Nr.: Betreuer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill und: Dr. Thomas Springer Eingereicht am 28. Februar 2014

2

3 II

4 SELBSTSTÄNDIGKEITSERKLÄRUNG Hiermit erkläre ich, Felix Wackernagel, die vorliegende Belegarbeit zum Thema "Erstellung eines Frameworks zur ezienten Entwicklung kollaborativer Echtzeitanwendungen auf mobilen Geräten" selbstständig und ausschlieÿlich unter Verwendung der im Quellenverzeichnis aufgeführten Literatur- und sonstigen Informationsquellen verfasst und entwickelt zu haben. Dresden, 28. Februar 2014 III

5 IV

6 DANKSAGUNGEN Mein Dank richtet sich an alle Personen dich mit während der Erstellung dieser Belegarbeit unterstützt haben. Ein besonderer Dank geht dabei an meinen Betreuer Herr Dr. Thomas Springer, der mich während der Bearbeitungszeit durch Feedback sowie fachlichen Rat und die Einführung in das wissenschaftliche Schreiben begleitet hat. Des Weiteren möchte ich mich bei meiner Verlobten Maria für die Geduld, Unterstützung und Entbehrungen durch die vielen Stunden zur Fertigstellung dieser Arbeit bedanken. Die Schilderung von Problemen aus der Welt der Informatik bewirkten einige neue Gedankengänge und waren zugleich unterhaltsam. Auÿerdem möchte ich mich bei Michael Dürre und Sindy Tiedke bedanken, die mir Feedback zum Verständnis meiner Arbeit lieferten. Zum Schluss danke ich noch meinen Eltern, die mir im Laufe meines Lebens den Wert von Bildung vermittelten und mich über die Zeit meines Studiums hinweg begleiteten. V

7 VI

8 INHALTSVERZEICHNIS 1 Einleitung Motivation Gliederung der Arbeit Grundlagen Apache Wave Architektur Client-Server Kommunikation WebSocket Protokoll Nebenläugkeitskontrolle Operational Transformation Google Wave Operational Transformation Android Anforderungsanalyse Funktionale Anforderungen Nicht-funktionale Anforderungen Technische Anforderungen Qualitätsanforderungen Zusammenfassung VII

9 4 Verwandte Arbeiten Google Drive Realtime API Generic Collaboration Infrastructure Beurteilung Zusammenfassung Konzept Kernkomponenten DOM Adapter Framework Adapter Workspace Awareness Adapter Kommunikationsadapter Mobile Strategy Adapter Integration einer anwendungsunabhängigen API Zusammenfassung Implementierung Kommunikationsadapter Mobile Strategy Adapter OT-Engine und OT-Model Framework Adapter Workspace Awareness Adapter Umsetzung aus Sicht des Entwicklers Zusammenfassung Evaluation Integration der Generic Collaboration Infrastructure in Android Testumgebung Durchführung und Auswertung Fazit und Ausblick 57 VIII Inhaltsverzeichnis

10 1 EINLEITUNG Immer mehr Anwendungen unterstützen das Teilen und Versenden von Bildern, Dokumenten und Multimediadateien. Die Gründe dafür sind verschiedener Natur. Es kann der Unterhaltungscharakter oder die Arbeit sein. In vielen Firmen gibt es bereits Anwendungen, wie zum Beispiel Conuence 1 oder MediaWiki 2, um einen zentralen Punkt für solche Dokumente und Dateien zu haben. Doch solche Werkzeuge sind für Einzelnutzer konzipiert und berücksichtigen das Arbeiten im Team nicht. Einige Hersteller haben diesen fehlenden Aspekt aufgegrien und dafür kollaborative Echtzeitanwendungen entwickelt. Die Firma Google tat dies mit der Produktreihe Google Drive 3, welches das erstellen und bearbeiten von Dokumenten, Tabellen und Arbeitsbereichen unterstützt. Dabei können mehrere Nutzer simultan und in Echtzeit ein Dokument bearbeiten und Änderungen der anderen Teilnehmer verfolgen. Auf diese Weise müssen Dokumente nicht mehr zwischen Mitgliedern eines Teams versendet und das private Versionsmanagement organisiert werden. Solche Anwendungen gibt es mittlerweile nicht nur für die gemeinsame Bearbeitung von Dokumenten, sondern ebenfalls für Bilder, multimediale Inhalte und Spiele. Ein Groÿteil dieser kollaborativen Echtzeitanwendungen ist für den Einsatz auf dem Desktop-PC konzipiert. Doch die Entwicklung von mobilen Endgeräten wie zum Beispiel Smartphones und Tablets zeigt eine stetige Steigerung der Mittel an Ressourcen in diesen Geräten. Gerade das Tablet ist ein wichtiger Meilenstein in dieser Entwicklung. Ein Gerät, das Rechenleistung sowie kompakte Gröÿe miteinander kombiniert und Anwendungen mobil gemacht hat. Somit sind die Mittel für rechenaufwendige Mehrbenutzeranwendungen nicht mehr nur dem stationären Computer vorbehalten, sondern erönen sich nun auch dem mobilen Markt. Gerade in einer immer schneller werdenden Zeit ist das Arbeiten von unterwegs keine Seltenheit mehr. Dank solcher kollaborativen Echtzeitanwendungen ist es nun möglich von überall, zu jedem Zeitpunkt, mit mehreren Personen Gleichzeit an einem Dokument zu arbeiten. 1.1 MOTIVATION Der Bereich der Multi-User Anwendungen wächst immer weiter. In mehr als zehn Jahren Forschung des kollaborativen Bereiches haben sich unterschiedliche Algorithmen zur Behandlung von Konikten entwickelt. Diese werden benötigt, um einen konsistenten Zustand nach einer Operation auf einem gemeinsam bearbeiteten Dokument zu gewährleisten. Somit wird die Aufgabe zur Erstellung einer neuen kollaborativen Echtzeitanwendung zunächst einmal zur Recherche und Prüfung der verschiedenen Frameworks und deren verwendeten Algorithmen. Ebenso die Zielplattform spielt dabei eine wichtige Rolle, denn bei mobilen Endgeräten bleibt die Erweiterung eines Frameworks selten unvermeidbar. An diesem Punkt wird der enorme Zeitaufwand für den Entwickler erkennbar. Umso mehr, wenn das Framework in einem späteren 1 ozielle Website: 2 ozielle Website: 3 Produktseite: Google Drive 1

11 Entwicklungszustand durch ein anderes ersetzt werden soll. Dies ist sicherlich ein Grund für die geringe Anzahl an Multi-User Anwendungen im mobilen Sektor. Dies motiviert zu einem Framework, um den Aufwand für zukünftige Entwickler zu reduzieren und damit das Feld der mobilen Techniken zu erweitern. Kollaborative Anwendungen haben auf mobilen Endgeräten zusätzliche Herausforderungen im Vergleich zu den Web-basierten Lösungen für den Desktop. Gerade die Anzahl an unterschiedlichen Geräten und Herstellern muss eine Lösung für verschiedene Displaygröÿen unterstützen. Anders als beim Web folgen Anwendungen auf mobilen Geräten mehr dem Design Guide ihres Betriebssystems, um Funktionen mit gleichem Aussehen zu verbinden. Das Thema Cross-Plattform Entwicklung spielt ebenfalls eine wichtige Rolle, denn die Zielgruppe einer Anwendung verwendet unterschiedliche Plattformen in verschiedenen Lebenssituationen. Neben Geräten, Designs und Plattformen, ist die Mobilität ein wichtiger Faktor dieser Arbeit. Der Nutzer eines Desktop PC ist an einen Standort gebunden, während Smartphone-Nutzer durch Mobilität eine schwankende Verbindungsqualität und Unterbrechungen herbeiführen. All diese Herausforderungen müssen bedacht werden. Deshalb soll ein Werkzeug entstehen, womit die Anpassung zu einer kollaborativen Echtzeitanwendung eektiv ermöglicht werden kann. In folgenden Arbeiten soll das entstandene Framework dieser Arbeit in die Mobilis-Plattform der Technischen Universität Dresden integriert werden. Dadurch sollen kollaborative Algorithmen für Nutzung in einem verteilten System als Dienst angeboten werden können. Das Framework soll die hierarchische Struktur eines Dokumentes verwalten und bei angewandten Operationen die Konsistenz überprüfen. Aufgetretene Konikte zwischen Operationen sollen erkannt und behoben werden. Die eektive und simple Wiederverwendung, ebenso die Erweiterung, soll ein zentraler Aspekt sein, um eine Vielzahl an bestehenden Single-User Anwendungen mit kollaborativer Funktionalität zu erweitern. Das Ziel dieser Arbeit soll es nun sein, einen Algorithmus für Koniktlösungen aus dem Apache Wave Projekt als generischen Dienst zur Koniktbehandlung und Erkennung zu extrahieren, diesen mittels eines Adapterkonzeptes für mobile und native Anwendungen bereitzustellen und am Beispiel der Android Plattform ein Prototyp zu implementieren. Die Evaluation der dabei entstandenen Arbeit soll einen Abschluss bilden und Vergleiche mit anderen Verfahren ermöglichen. 1.2 GLIEDERUNG DER ARBEIT Der Aufbau dieser Arbeit setzt sich aus folgenden Teilen zusammen. In Kapitel 2 werden die fachlichen Grundlagen aus Wissenschaft und Industrie zum Thema kollaborativer Anwendungen und bereits vorhandener Techniken vermittelt. Mit Kapitel 3 werden alle funktionalen und nicht-funktionalen Anforderungen an mobile und kollaborative Anwendungen identiziert. Bereits vorhandene Ansätze und Frameworks für die Integration von kollaborativen Funktionen werden in Kapitel 4 vorgestellt. Der konzeptionelle Entwurf eines kollaborativen Frameworks für mobile Endgeräte wird mit Kapitel 5 präsentiert. Kapitel 6 demonstriert die praktische Umsetzung des adaptierten Generic Collaboration Infrastructure Konzeptes an mobile Systeme. Eine Evaluation des entwickelten Konzeptes sowie der implementierten Anwendung wird in Kapitel 7 getätigt. Abschlieÿend wird in Kapitel 8 ein Fazit über die behandelte Problematik sowie ein Ausblick auf noch kommende Themen gemacht. 2 Kapitel 1 Einleitung

12 2 GRUNDLAGEN 2.1 APACHE WAVE Das Apache Wave Projekt wurde im Jahr 2012 von der Firma Google übernommen und ist seitdem als Open Source verfügbar. Das ehemalige Google Wave, wurde bei der Google I/O Konferenz 2009 erstmals vorgestellt und ist eine Plattform für kollaborative Echtzeitanwendungen. Es stellt eine Multimessaging Plattform dar, in der mehrere Nutzer gleichzeitig strukturierte Nachrichten schreiben, bearbeiten, löschen und kommentieren können. Nutzer sind in der Lage, beliebig vielen Konversationen zu folgen und beispielsweise Dateien, Links oder Videos hinzufügen. All diese Aktionen geschehen parallel und somit können Änderungen an einem Dokument von allen Teilnehmern in Echtzeit verfolgt werden Architektur Apache Wave ist eine kollaborative Plattform, um Dokumente, die als Wave bezeichnet werden, mit Nebenläugkeitskontrolle und geringen Antwortzeiten zu übertragen. Durch das Federation Protokoll können mehrere Wave Provider miteinander kommunizieren und sogenannte Shared Waves zwischen Wave Servern versenden. Ein Wave Provider ist über seine Internetdomain eindeutig identizierbar. Die Wave Nutzer sind ebenfalls eindeutig adressierbar, da sich ihre Adresse aus Nutzername und der Domain ihres Wave Provider zusammensetzt, vergleichbar mit der . Adresse Nutzername Wave-Provider wave.google.com Wave-Nutzer Bob Tabelle 2.1: Zusammensätzung der Wave-Nutzeradressen Neben Wave Providern und Nutzern existieren weiterhin Gruppen, Robots, Gateways, Proxies und andere Services. Eine Gruppe repräsentiert dabei eine Liste von Nutzern. Ein Robot ist ein automatisierter Wave Nutzer und stellt spezielle Funktionen wie beispielsweise Übersetzer, Spiele oder externe Daten zur Verfügung. Ein Gateway konvertiert verschiedene Kommunikationsprotokolle um somit den Datenaustausch zwischen Wave und oder IM zu ermöglichen. All diese Bestandteile verfügen über eine Adresse und somit im Internet erreichbar. Ein Wave Provider verwaltet und autorisiert alle ihm zugehörigen Nutzer sowie dessen Waves. Ist beispielsweise ein Nutzer teil einer Wave und stammt von einem anderen Wave Provider, so wird eine Kopie der Wave beim anderen Provider gespeichert. Der Wave Provider ist für das Versenden von Änderungen verantwortlich und nutzt dabei das Google Wave Federation Protocol, um mit anderen Wave Providern zu kommunizieren. Tabelle 2.1 zeigt beispielhaft die Adresse eines Wave Provider und Nutzer. 3

13 Eine Wave besteht aus einer Sammlung von mehreren Wavelets. Ein Nutzer, der Zugri auf ein Wavelet hat, wird Teilnehmer genannt. Der Inhalt eines Wavelet wird Dokument genannt. Somit besteht ein Wavelet aus zwei Komponenten: einer Liste von Teilnehmern und einer Liste von Dokumenten. Im oberen Abschnitt wurde bereits auf Waves eingegangen, deren Teilnehmer ebenfalls Bestandteil eines anderen Wave Providers sein können. Teilnehmer eines anderen Providers speichern dabei eine Kopie des Wavelets dem diese partizipieren. Da ein Nutzer an mehreren Wavelets teilnehmen kann und um die Gröÿe der Wavelets gering zu halten, werden Nutzerinformationen in einem separaten Wavelet gespeichert. Dieses nutzerspezische Wavelet hat einen Nutzer als Teilnehmer und beinhaltet alle ihn betreende Daten. Solch eine begrenzte Teilnehmerliste wird ebenfalls bei privaten Nachrichten verwendet. Dabei sind der Sender und der Empfänger in der Teilnehmerliste des Wavelets gespeichert und der Zugri für andere Nutzer beschränkt. Es wurde bereits ein Einblick in die Adressierbarkeit von Nutzern und Wave Providern gegeben. Dies gilt ebenfalls für Waves und deren Wavelets. Beide verfügen über eine ID, welche eindeutig und global erreichbar ist. Eine WaveID setzt sich dabei aus der Domain des Wave Provider und einer eindeutigen Zeichenkette zusammen. Die WaveletID ist dabei eindeutig im Kontext seiner zugehörigen Wave. Auch diese ID setzt sich aus Domain und Zeichenkette zusammen. Die Domain in der WaveletID gibt dabei Auskunft über den Host und somit dem Urheber dieser Nachricht. In Tabelle 2.2 werden zwei Adressen als Beispiel dargestellt. Wave (ID) Wavelet (ID) Adresse waveinabox.net/w+mbrxywf_w-a waveinabox.net, conv Tabelle 2.2: Adresse von Wave Komponenten Ein Wave Provider ist für jegliche Änderungen die auf Wavelets angewendet werden und deren Autoren dem Provider zugehörig sind, verantwortlich. Diese Änderungen werden im Kontext von Wave als Operationen bezeichnet und nden ihre Anwendung auf das Wavelet-Modell. Im Zusammenhang dazu steht der Operational Transformation Algorithmus. Dieser wird zur Konikterkennung und Koniktbehebung zwischen Operationen verwendet. Nach einer erfolgreichen Operation auf ein lokales Modell und Ausschluss von Konikten zwischen anderen Operationen wird die Operation zu entfernten Teilnehmern übertragen. Wie bereits beschrieben, können Wavelets bei verschiedenen Wave Providern erzeugt werden. Das Wavelet eines Nutzer, welches seine persönlichen Daten beinhaltet, ist demselben Provider wie dem des Nutzers zugeordnet. Im Vergleich zu anderen Wavelets wird dieses nie an andere externe Wave Provider exportiert. Dies gilt ebenfalls für private Wavelets deren Nutzer demselben Provider angehören. Im Übrigen gibt die Sichtbarkeit von einzelnen Dokumenten keine Auskunft über die gesamte Übertragbarkeit des zugehörigen Wavelet. Ist ein Dokument als privat deklariert, so wird es nicht an weitere Provider verteilt. In der Arbeit [1], aus einer Reihe von Veröentlichungen über ehemals Google Wave, werden weitere Details über das Rechtesystem vorgestellt. Neben Waves, Nutzern und Wavelets gibt es noch weitere Komponenten welche den Aufbau eines Wave Provider vervollständigen. Der Wave-Store dient als zentraler Speicher für Operationen die auf ein Wavelet angewendet wurden. Der Wave-Service verwendet den Wave-Store, um Operationen zu speichern und ebenso zu laden. Der Wave-Service löst zudem Konikte zwischen Wavelet Operationen mittels des Operational Transformation Algorithmus und validiert diese, bevor die Übertragung zu weiteren Teilnehmern durchgeführt wird. Dabei können die Teilnehmer über weitere Wave Provider oder dem integrierten Frontend Service am Wavelet kollaborieren. Das Frontend ist ebenfalls ein Bestandteil des Wave Provider und dient als Zugangspunkt für Clients. Es erstellt eine grasche Oberäche und koordiniert die Kommunikation zu weiteren Teilen des Wave Provider. Für die Kommunikation mit anderen Providern gibt es zwei besondere Komponenten: Das Federation Gateway und der Federation Proxy. Bevor auf diese Komponenten noch weiter eingegangen werden kann, sollen die Begrie local Wavelet und remote Wavelet, welche zuvor einheitlich als Shared Wave bezeichnet wurden, noch einmal verdeutlicht werden. Ein local Wavelet bezeichnet ein Wavelet welches von einem Nutzer bei seinem zugehörigen Wave Provider angelegt wurde. Ein remote Wavelet bezeichnet die Kopie eines Wavelets von einem anderen Provider. Beide Arten werden im Wave-Store gespeichert. Die remote Wavelets werden zusätzlich vom Provider in einem Cache zwischengespeichert. Sämtliche lesende Zugrie auf das remote Wavelet werden vom Cache getätigt. Änderungen werden erst auf das remote Wavelet angewendet, wenn der zugehörige Provider die Operation auf dessen lokales Modell angewendet hat. 4 Kapitel 2 Grundlagen

14 Abbildung 2.1: Architektur der Wave Provider Das Federation Gateway dient zur Übertragung von local Wavelets zu anderen Wave Providern. Dabei werden die Wavelet Operationen, die auf ein local Wavelet angewendet wurden, zu einem Wave Provider eines remote Teilnehmer gesendet. Zusätzlich sendet das Gateway Wavelet Operationen, welche noch nicht empfangen wurden, da der Nutzer beispielsweise zum Zeitpunkt der Operation oine war. Um dieses Verfahren zu realisieren, verwendet das Federation Gateway eine Queue für alle remote Domains. In dieser Queue werden alle zu versendenden Wavelet Operationen zwischengespeichert. Eine Operation wird aus der Queue gelöscht, wenn ein Acknowledge dafür vom Wave Provider empfangen wurde. Die Queue ist ein Teil des Wave-Stores und somit persistent gespeichert bei Server Ausfall. Der Federation Proxy verarbeitet hingegen die remote Wavelet Operationen von einem anderen Wave Provider. Dabei werden dem Proxy neue Wavelet Operationen von einem remote Federation Gateway zugesandt. Zusätzlich empfängt der Proxy auch Wavelet Operationen, die während der oine Zeit des Nutzers nicht übertragen werden konnten. Daraus ergibt sich eine Kollaboration zwischen Federation Proxy und Federation Gateway um mehrere Wave Provider miteinander zu verbinden. Für die Kommunikation zwischen Federation Gateway und Federation Proxy wird das Google Wave Federation Protocol verwendet. Dieses Protokoll ist eine Erweiterung des XMPP (Extensible Messaging and Presence Protocol) Standard und ermöglicht das Finden von IP Adressen sowie Ports mittels SRV Records 1, TLS Authentizierung 2 und Verschlüsselung von Verbindungen. Abbildung 2.1 zeigt noch einmal alle Komponenten des Wave Provider in der Übersicht und wie diese miteinander in Verbindung stehen Client-Server Kommunikation Im Abschnitt wurde bereits ausführlich die Kommunikation zwischen verschiedenen Wave Providern und somit der Server zu Server Kommunikation beschrieben. In diesem Abschnitt wird auf die Kommunikation zwischen Client und Server eingegangen sowie das dabei verwendete Protokoll näher erläutert [2]. Der Wave Nutzer, welcher als Client agiert, steht in Verbindung mit dem Wave Server um Wavelets zu erstellen, deren Inhalt zu lesen und zu bearbeiten. Für die Realisierung dieser 1 SRV Record steht für Service Record und wurde in RFC 2782 speziziert. 2 Transport Layer Security ist Bestandteil der Transportschicht und wird zur sicheren Datenübertragung im Internet eingesetzt. 2.1 Apache Wave 5

15 Abbildung 2.2: Nachrichtenaustausch zwischen Client und Server Funktionen wird ein spezielles Client-Server Protokoll verwendet, womit Nachrichten im JSON 3 Format übertragen werden. Als Basis für dieses Protokoll dient das erweiterbare WebSocket Protokoll. Für die Client-Server Kommunikation wird ein kompaktes und ezientes Protokoll verwendet, während für die Server-Server Kommunikation das Google Wave Federation Protocol zum Einsatz kommt. Durch die Verwendung von WebSockets wird eine bidirektionale und asynchrone Verbindung zwischen Client und Server aufgebaut. Dadurch können beide Seiten der Verbindung unabhängig Nachrichten versenden, ohne auf eine sofortige Rücknachricht zu warten. Die Weiterentwicklung des Client-Server-Protokolls wurde mit der Entscheidung der Kommunikationsprotokolle mit einbezogen. Jede Nachricht, die mit diesem Protokoll versendet wird, enthält die Version des verwendeten Protokolls. Jeder Wave Server, der eine empfangene Protokollversion nicht unterstützt, schlieÿt daraufhin die Verbindung und unterbindet somit weitere Kommunikation. Dadurch wird sichergestellt, dass die versendeten Nachrichten verarbeitet werden können. Das Client-Server-Protokoll wird nach einer erfolgreichen Verbindung mit dem Server verwendet. Für den Aufbau der Verbindung wird das WebSocket Protokoll verwendet. Wurde eine Verbindung zwischen Client und Server etabliert, so werden Nachrichten zwischen beiden Parteien ausgetauscht. Diese Nachrichten werden in WebSocket Frames gekapselt. Dabei wird eine Nachricht pro Frame verschickt. Im Abschnitt 2.2 werden weitere Details dieser Technologie erläutert. Es gibt zwei Arten von Requests, die eine Wave Nachricht repräsentieren können. Mit dem ProtocolOpenRequest beginnt ein Client die Kommunikation mit dem Server. Dabei enthält der ProtocolOpenRequest die WaveID einer Wave, die verfolgt und bearbeitet werden soll. Wurde die Verbindung erfolgreich hergestellt, sendet der Client ProtocolSubmitRequests. Mit diesem Request werden Änderungen, die vom Client an einem Wavelet getätigt wurden, an den Server gesendet. Der Server wiederum schickt bei jeder Änderung von anderen Teilnehmern ein ProtocolWaveletUpdate. Für dieses Update wird kein Request vorausgesetzt. Es ist eine unabhängige Nachricht, welche durch die Vorteile des WebSocket Protokoll, ohne vorherige Anfrage übertragen werden kann. Neben der Notizierung von Modelländerungen wird das ProtocolWaveletUpdate aber auch für fehlgeschlagene Verbindungsversuche verwendet. Somit kann der Server als Antwort auf einen ProtocolOpenRequest ein ProtocolWaveletUpdate mit einer Fehlernachricht oder unabhängig vom Request ein Update mit noch nicht erhaltenen Waveletänderungen verschicken. Der Client muss für jedes Wavelet, an dem er teilnehmen möchte, einen weiteren ProtocolOpenRequest verschicken. Bevor ein ProtocolSubmitRequest verschickt werden kann, muss der Client auf die Antwort des Servers für den ProtocolOpenRequest warten. Dieser enthält bei erfolgreicher Verbindung einen Dokumenten Hash. Dieser Hash muss mit jedem ProtocolSubmitRequest verschickt werden. In Abbildung 2.2 wird noch einmal der Nachrichtenuss zwischen Client und Server exemplarisch dargestellt. Es wurde bereits bei der Erläuterung zum Nachrichtenuss der Inhalt einer Nachricht bzw. dessen Aufbau angeschnitten. In diesem Absatz soll darauf noch weiter eingegangen werden. Der 3 JavaScript Object Notation wurde von Douglas Crockford deniert 6 Kapitel 2 Grundlagen

16 Abbildung 2.3: Protokollnachrichten und Inhalt des Client-Server-Protokoll von Wave ProtocolOpenRequest enthält neben der WaveID auch einen WaveletID Präx. Auf Basis dieser beiden Informationen erkennt der Server für welche Wavelets der Client Dokumente abruft. Der WaveletID Präx kann auch verkürzt werden, um eine gröÿere Menge von Wavelets zu erhalten. Wird ein leerer Präx verwendet, so wird der Client über Änderungen von allen Wavelets informiert, die Teil der angegebenen Wave sind. Mit Beginn des ersten ProtocolOpenRequest erhält der Client einen Snapshot, welcher das initiale Modell abbildet. Die Protokollversion ist ebenfalls ein Bestandteil dieser Nachricht und wird für weitere Kommunikation benötigt. Das ProtocolWaveletUpdate kann einen Snapshot vom aktuellen Wavelet Modell enthalten, wenn der Client zum ersten Mal das Modell anfordert. Des Weiteren sind eine oder mehrere ProtocolWaveletDelta Nachrichten und die Protokollversion enthalten. Solch ein WaveletDelta repräsentiert die Änderungen, die auf einem Wavelet angewendet wurden und nun lokale reproduziert werden sollen. Der ProtocolSubmitRequest enthält ein ProtocolWaveletDelta, welches die Änderungen vom Client an einem Wavelet enthält und die vom Server auf die Wave angewendet werden sollen. Der Client kann nur einen ProtocolSubmitRequest pro Wavelet ausführen und schickt erst weitere, wenn der vorherige mit einem ProtocolSubmitResponse quittiert wurde. Alle Änderungen, die während des Wartens auf einen ProtocolSubmitResponse getätigt werden, werden beim Client gesammelt und mit dem nächsten ProtocolSubmitRequest gebündelt verschickt. Der Client muss dabei die gesammelten Deltas mit derzeit eingehenden Deltas von einem ProtocolWaveletUpdate selbstständig transformieren um die aktuelle Version an den Server schicken zu können. Ein ProtocolWaveletDelta wird nur auf eine Wave angewendet, wenn die ganze OT Transformation erfolgreich ist. Die Anwendung eines Deltas erfolgt dann auf atomarer Ebene. Das WaveletDelta wird bei nicht erfolgreicher Anwendung verworfen. Des Weiteren wird dem Request der Dokumenten Hash hinzugefügt sowie die Protokollversion. Der ProtocolSubmitResponse ist die vierte und letzte Nachricht. Dieser repräsentiert eine Antwort auf einen ProtocolSubmitRequest und enthält bei erfolgreicher Anwendung der ProtocolWaveletDeltas den neuen Wavelet Dokumenten Hash um weitere ProtocolSubmitRequests zu versenden. Die Protokollversion ist auch in dieser Nachricht enthalten. In Abbildung 2.3 ndet sich eine Zusammenstellung des Aufbaus der einzelnen Wave Nachrichten. Zum Abschluss dieses Kapitels wird der Aufbau des Nachrichteninhaltes beschrieben. Wie bereits erwähnt, ist das Client-Server-Protokoll eine Erweiterung des WebSocket Protokolls, um Nachrichten im JSON Format zu übertragen. Diese JSON Nachrichten werden mittels der Bibliothek Protocol-Buers 4 erzeugt. Protocol-Buers ist eine sprachneutrale, plattformunabhängige und erweiterbare Serialisierungstechnik für strukturierte Daten. Entwickelt wurde dies von der Firma Google im Jahr 2001 und wird weiterhin unterstützt. Das Ziel von 4 Ozielle Website: developers.google.com/protocol-buers 2.1 Apache Wave 7

17 Protocol-Buers ist simple und eziente Datenübertragung. Während XML in einem textuellen Format übertragen wird, verwendet Protocol-Buers das Binärformat. Diese Technik eignet sich zum Speichern und Übertragen von strukturierten Informationen und wird gerade von Google bei RPC Systemen verwendet [3]. Im Falle von Wave ndet eine Serialisierung und Deserialisierung zwischen JSON und Protocol-Buers Nachrichten statt. Da Protocol-Buers verschachtelte Nachrichtenstrukturen wie bei JSON unterstützt, werden Konvertierungen rekursiv angewendet. Die atomare Einheit bei Protocol-Buers entspricht dem Key-Value Pair, vergleichbar mit dem bei JSON. Bei der Konvertierung zwischen JSON und Protocol-Buers entspricht der Key des JSON Objektes einem Variablennamen im Protocol-Buer, nachdem eine Funktion den Key normalisiert hat. Im Anschluss daran wird der Value in Abhängigkeit von dessen Typ konvertiert. JSON-Arrays werden in Listen umgewandelt und anschlieÿend rekursiv deren Elemente. Der Typ Boolean wird beispielsweise in 1 für True und 0 für False abgebildet. Vice versa erfolgt die Konvertierung von JSON in Protocol-Buers. Weitere Hinweise sowie Details zur Implementierung nden sich auf der oziellen Website. 2.2 WEBSOCKET PROTOKOLL Das WebSocket Protokoll wurde von der Internet Engineering Task Force (IETF) im Jahr 2011 entwickelt und speziziert. Es ermöglicht bidirektionale und asynchrone Kommunikation zwischen zwei Seiten. Ohne das WebSocket Protokoll muss ein Client in Intervallen einem Server Requests zuschicken, um Änderungen von Inhalten zu erhalten. Dies führt zu verschiedenen Problemen. Der Server muss mehrere TCP-Verbindungen oen halten, um dem Client zu antworten. Das verwendete HTTP-Protokoll hat einen groÿen Overhead, welcher mit jedem Request verschickt werden muss. Des Weiteren muss der Client jede ausgehende Verbindung mit eingehenden Verbindungen abgleichen. Eine simple Lösung wäre die Verwendung einer einzigen TCP-Verbindung um über diese sämtliche Nachrichten zwischen Client und Server zu übertragen. Eben diesen Ansatz verfolgt das WebSocket Protokoll. Die Standard Ports für die unverschlüsselte und verschlüsselte Kommunikation bei HTTP sind 80 und 443. Dieselben Ports verwendet auch das WebSocket Protokoll. Da beide eine TCP-Schicht zur Kommunikation verwenden, kann die bestehende Infrastruktur für beide verwendet werden, HTTP sowie WebSockets. Das neue Protokoll besteht aus zwei Bestandteilen: einem Handshake Mechanismus und dem Datentransfer. Der Handshake dient zum Aufbau der WebSocketverbindung. Dabei wird ein HTTP Request mit einer Anfrage bezüglich eines Protokollupgrades an den Server geschickt. Ist der Server in der Lage das Upgrade Protokoll zu verarbeiten, so wird der Handshake mit einer entsprechenden Nachricht beantwortet. Wurde der Handshake erfolgreich durchgeführt, bleibt die Verbindung bestehen und fortan wird das ausgehandelte Protokoll verwendet. Bei einem Fehlschlag wird die Verbindung wieder getrennt. In Tabelle 2.3 wird auf der linken Seite ein Handshake Request für das WebSocket Protokoll und auf der rechten Seite ein passender Response mit dem erfolgreichen Protokollupgrade dargestellt. Weitere Erklärungen nden sich unter [4]. GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dghlihnhbxbjzq== Origin: Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 HTTP/ Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pplmbitzhzrbk+xoo= Sec-WebSocket-Protocol: chat Tabelle 2.3: Verbindungsaufbau zwischen Client und Server mit dem WebSocket Protokoll Die Einheit der Datenübertragung nennt sich Message. Eine Message wird aus mehreren Frames zusammengesetzt und über eine oene Verbindung übertragen. Jedes Frame, das zu einer Message gehört, hat einen speziellen Typ. Der Typ kann Text enthalten, oder auch aus Binäroder Kontrolldaten bestehen. Die ersten beiden Typen bilden den primären Inhalt der Message, während Letzteres als Statusinformation für das Protokoll dient. Das WebSocket Protokoll ist erweiterbar und könnte in der Zukunft noch weitere Typen und Mechanismen unterstützen. Durch die oene Verbindung ist keine Anfrage vom Client nötig, um Daten vom Server zu erhalten. Stattdessen kann dieser sofort neue Inhalte an den Client senden. Dadurch entsteht eine asynchrone Kommunikation zwischen Client und Server. Die komplette Spezikation kann unter [4] gefunden werden. 8 Kapitel 2 Grundlagen

18 2.3 NEBENLÄUFIGKEITSKONTROLLE Das Ziel von kollaborativen Anwendungen ist die Zusammenarbeit von mehreren Personen an einem gemeinsamen Dokument. Dabei sollen die Personen ortsunabhängig und am Beispiel dieser Arbeit auch geräteunabhängig sein. Im Laufe der gemeinsamen Bearbeitung eines Dokumentes wird es sich nicht vermeiden lassen, dass wenigstens zwei Personen zur selben Zeit eine gleichzeitige Änderung vornehmen. Um danach ein einheitliches Dokument für alle Personen zu erhalten, muss eine sogenannte Nebenläugkeitskontrolle die gleichzeitigen Änderungen überwachen. Die Nebenläugkeitskontrolle verwendet einen speziellen Algorithmus zur Erkennung und Behebung von Konikten und stellt somit einen wichtigen Bestandteil von kollaborativen Applikationen dar. Es gibt zwei Ansätze für die Nebenläugkeitskontrolle: der pessimistische Ansatz und der optimistische Ansatz. Beim pessimistischen Ansatz wird zum Beispiel das gleichzeitige Bearbeiten eines Objektes mittels einer Schreibsperre gelöst. Möchte eine Person ein Objekt bzw. ein Dokument bearbeiten, so fordert diese vom zentralen Server, wo das Dokument liegt, einen Schreibzugri an. Arbeitet bereits eine andere Person an diesem Dokument, so weist der Server diesen Schreibzugri zurück und erlaubt keine weiteren Änderungen. Erst wenn die Bearbeitung beendet wurde, wird die Schreibblockade entfernt und erlaubt das erneute Bearbeiten. Dieser Ansatz folgt dem Transaktionskonzept, welches in Datenbanken verwendet wird. Änderungen, die in einer Transaktion getätigt wurden, nden erst mit dem Transaktionsende Anwendung auf das bearbeitete Dokument. Der entscheidende Nachteil dieses Ansatzes ist die zeitliche Diskrepanz zwischen Anfrage und möglichem Schreibzugri. Eine Person muss auf die Bestätigung eines Schreibzugris warten und kann im ungünstigsten Fall nicht auf ein Objekt zugreifen. Dadurch ist keine Echtzeit Bearbeitung möglich. Im Gegenteil, mittels Sperrung ist keine Nebenläugkeit vorhanden und nur eine Person in der Lage Änderungen vorzunehmen. Die Sperrung eines Dokumentes ist aber nicht das einzige Verfahren, welches in die pessimistische Nebenläugkeitskontrolle eingeordnet wird. Um die Probleme der parallelen Arbeit zu umgehen, können Änderungen mittels sequenzieller Verarbeitung ebenfalls zu einem konsistenten Dokumentenzustand führen. In diesem Fall werden sämtliche Operationen mit einem Zeitstempel versehen und in der chronologischen Reihenfolge auf das Dokument angewendet. Dabei können zeitliche Verzögerungen auftreten. Wird beispielsweise Operation A und darauf Operation B begonnen, so kann es zu Wartezeiten kommen, wenn B noch vor A beendet wurde. Somit ist B bereits auf das Dokument anwendbar aber um mögliche Nebenläugkeit zu verhindern, wird erst auf A gewartet und B danach angewendet. Solch ein Zeitstempel bezieht sich meist auf eine logische Uhr wie sie in [5] beschrieben wird. Eine weitere Möglichkeit ist die Aufteilung eines Dokumentes. So wird beispielsweise ein Dokument in mehrere Abschnitte zerlegt und zur exklusiven Nutzung einer Person gegeben. Der Schreibzugri auf diesen Abschnitt ist nur dem aktuellen Besitzer erlaubt. Dieses Verfahren ist eine Schreibsperre auf einer feineren Ebene. Im Gegensatz zum pessimistischen Ansatz erlaubt der optimistische Ansatz die gleichzeitige lokale Änderung an einem gemeinsam genutzten Objekt von mehreren Personen. Dabei gibt es keine Einschränkungen und kurze Reaktionszeiten für die Nutzer [6]. Änderungen an einem Objekt werden lokal zwischengespeichert. Treten im weiteren Verlauf Konikte mit den Operationen von anderen Personen auf, so wird versucht, diese aufzulösen. Entweder durch den Nutzer selber oder automatisiert. Beim optimistischen Ansatz wird von einem seltenen Koniktauftreten ausgegangen. Konikte in der Nebenläugkeit werden dabei erst nach der Anwendung von Operationen festgestellt und somit sind inkonsistente Zustände schneller für den Nutzer ersichtlich. Gerade mit zunehmender Nutzeranzahl und vielen Operationen wird der Aufwand für solche Verfahren sehr groÿ. Ein solches Verfahren ist beispielsweise die optimistische Sperre. Anders als beim pessimistischen Ansatz besitzt jeder Nutzer bereits die Berechtigung ein Objekt zu bearbeiten. Während der Bearbeitung wird das Schreibrecht geprüft und bei Entzug von diesem die Bearbeitung rückgängig gemacht. Bei einigen Verfahren werden mehrere Dokumentenversionen vorbehalten und bei Konikten wieder hergestellt [7]. Somit sollen die Intentionen des Nutzers erhalten bleiben. Für beide Ansätze gibt es mittlerweile verschiedene Algorithmen mit unterschiedlichen Herangehensweisen um das Problem der gleichzeitigen Dokumentenänderung zu lösen [8]. 2.3 Nebenläugkeitskontrolle 9

19 2.4 OPERATIONAL TRANSFORMATION Operational Transformation (OT) ist ein weiterer Algorithmus, der zum optimistischen Ansatz gehört. Dieser ndet Einsatz bei einer replizierten Modellarchitektur, wobei Operationen sofort lokal ausgeführt werden können und konkurrierende fremde Operationen, gegen die eigenen transformiert werden um einen konsistenten Zustand zu erhalten [9]. Um eine Vorstellung vom OT Algorithmus zu erhalten und damit auch auf Engpässe besser hinweisen zu können, wird im folgenden Abschnitt ein Beispiel angeführt. Angenommen ein Server mit einem zentralen Dokumentenmodell sowie ein Client mit einer lokalen Dokumentenkopie nehmen zum selben Zeitpunkt eine Änderung am Dokument vor. Die Änderung des Servers kann dabei von einem weiteren Teilnehmer der Kollaboration ausgelöst worden sein. Das Dokument besteht dabei aus der Zeichenfolge ABCDE und umfasst somit eine Länge von 5. Der Client wendet eine Löschoperation auf den Buchstaben D an, was im Folgenden als Operation c mit del 4 bezeichnet wird. Der Server wendet ebenfalls eine Löschoperation, aber auf den Buchstaben B an. Diese wird im Folgenden als Operation s mit del 2 bezeichnet. Da der OT Algorithmus zur Nebenläugkeitskontrolle mit anschlieÿender Koniktbehebung eingesetzt wird, nden in diesem Beispiel die Operationen c und s zum selben Zeitpunkt statt. In diesem Fall wendet der Client zu erst die eigene Operation c am lokalen Dokument an und empfängt im Anschluss die Operation s vom Server. Das lokale Dokument vom Client setzt sich somit aus ACE zusammen. Auf der Serverseite wird zu erst Operation s und anschlieÿend die vom Client versendete Operation c angewendet, womit das zentrale Dokument ACD ergibt. Dies ist ein typischer Fall, der bei kollaborativen Anwendungen entstehen kann. In dem eben genannten Beispiel wurde noch keine Nebenläugkeitskontrolle berücksichtigt, denn es sollte das primäre Problem bei kollaborativen Anwendungen auühren. In Abbildung?? (a) ist das Beispiel noch einmal grasch dargestellt. Der OT Algorithmus ndet seine Anwendung in dem Moment, wo eine fremde Operation auf ein lokales Modell angewendet werden soll. Anhand des eben genannten Beispiels wäre dies Operation s auf Clientseite und Operation c auf Serverseite. Der OT Algorithmus verwendet vor Anwendung der Operation eine Transformationsfunktion um die ursprüngliche Intention der Operation zu erhalten und damit einen konsistenten Zustand für alle Dokumente zu erreichen. Die Transformationsfunktion nimmt zwei Operationen entgegen und bildet diese auf zwei transformierte Operationen ab (2.1a). Zusätzlich gilt (2.1b), womit ein konsistentes Ergebnis erzielt wird, da Operation s gefolgt von c' identisch zu Operation c gefolgt von s' ist. Für die soeben verwendete Löschoperation ndet sich in Code 5 eine mögliche Implementierung. Generell gibt es nicht nur eine Lösung für solch eine OT Funktion solange alle Eigenschaften enthalten sind. xform(c,s) = (c 0,s ) 0 (2.1a) (c 0 s) = (s 0 c) (2.1b) Abbildung 2.4: Eigenschaften der Operational Transformation in Bezug auf deren Funktionen und Operationen. xform ( del x, del y ) = { del x 1, del y} i f x > y { del x, del y 1} i f x < y { no op, no op } i f x = y Listing 2.1: Transformationsbeispiel einer Löschoperation Nach Anwendung der Funktion xform von Code 5 auf die Operationen c und s, entsteht auf Serverseite die Operation c' mit del 3, während auf Clientseite die Operation s' weiterhin bei del 2 bleibt. Auf diese Weise erhalten Client und Server einen konsistenten Dokumentenzustand. Der OT Algorithmus wird im Laufe der Kollaboration nicht immer synchron zwischen Client und Server ausgeführt werden. Um dennoch sicherzustellen, dass alle Teilnehmer im selben Zustand sind und somit demselben Dokumentenpfad folgen, werden Zustandsvektoren verwendet. Der daraus resultierende Zustandsgraph zeigt den Verlauf jeder Operation und Transformation, die auf ein Dokument angewendet wurde, an. Der OT Algorithmus macht dabei die Zusicherung eines konsistenten Dokumentes, wenn alle Teilnehmer einer Sitzung im identischen Zustand sind. 10 Kapitel 2 Grundlagen

20 (a) Problematik bei kollaborativen Anwendungen (b) Lösung mittels Operational Transformation Abbildung 2.5: Operational Transformation Problem sowie Lösung Abbildung 2.6: Zustandsgraph während einer Operational Transformation 2.4 Operational Transformation 11

21 In Abbildung 2.5 ist ein Zustandsgraph für Client und Server abgebildet. Mit jeder Operation auf Clientseite bewegt sich der Graph nach links und mit jeder Serveroperation nach rechts. Der Zustandsvektor wird dabei auf der jeweiligen Seite erhöht. Ein Konikt im Dokument zeichnet sich dadurch aus, dass Client und Server in einem unterschiedlichen Zustand sind. OT verwendet einen Verlauf für alle Operationen, um dadurch alle Kollaborationsteilnehmer in denselben Zustand zu überführen. Die bereits angeführte Operationstransformation wird dabei verwendet. Das Beispiel von Abbildung 2.5 soll die Synchronisation zwischen Client und Server noch einmal illustrieren. Der Client wendet die Operation c mit del 4 auf sein lokales Dokument an. Der Server führt die Operationen s 1 mit del 1 und s 2 mit del 3 aus. Die Operation s 2 wird dabei vom Server direkt nach s 1 angewendet, ohne vorher c zu c' zu transformieren. Bei Verwendung des Dokumentes aus Abbildung??, haben Client und Server nach Teil (a) jeweils ein Dokument besteht aus BCE. Trotz eines identischen Dokumentes sind Client und Server in einem unterschiedlichen Zustand. Tatsächlich zeigt sich in diesem Beispiel eine weitere Besonderheit von OT, denn mit der Anwendung von s 2 auf Serverseite ist der Client eine Operation im Rückstand und hat keine Operation die mit s 2 zur Transformation verwendet werden kann. OT kann nur verwendet werden, wenn beide Operationen vom selben Zustand begonnen wurden. Die Lösung dafür liegt in der Speicherung der transformierten Operationen. So speichert der Client nach Erhalt von s 1 das zweite Transformationsergebnis c'. Mit dem Erhalt von s 2, wird die zuvor gespeicherte Operation c' zur Transformation verwendet. Mit der Annahme das c' nach s 1 angewandt wurde, sind Client und Server im selben Zustand und die Bedingung für OT ist wieder gegeben. Das Ergebnis für Client und Server ist weiterhin das Dokument BCE. Durch die Transformation entstehen no-op 5 Operationen, womit lediglich der Zustand von beiden Seiten synchronisiert wird. Tatsächlich werden Operationen nur dann von Kollaborationsteilnehmern verwendet, wenn beide auf einen gemeinsamen Zustand zurückzuführen sind, auch wenn dies aus mehreren vorangegangenen Operationen nachvollzogen werden muss. Um einen ständig wachsenden Operationsspeicher zu vermeiden, werden angewandte Operationen mit einer Quittierungsnachricht 6 bestätigt und aus dem Operationsverlauf gelöscht. In der Arbeit [10] wird im Kapitel Synchronisation Protocol näher auf dieses Verfahren eingegangen sowie in dem Artikel [11], weswegen an dieser Stelle das Thema nicht weiter vertieft wird. Es wurde gezeigt, dass Operational Transformation das Problem von Konikten bei parallelen Operationen beheben und mittels Synchronisation alle Teilnehmer einer Sitzung in denselben Zustand überführen kann. 2.5 GOOGLE WAVE OPERATIONAL TRANSFORMATION Im vorherigen Kapitel 2.4 wurde der Operational Transformation Algorithmus, speziell der Jupiter OT [9], vorgestellt und erläutert. Im folgenden Kapitel soll es um die speziellen OT Anpassungen für die Herausforderungen von Apache Wave gehen. Die Herausforderungen sieht die Firma Google in der gleichzeitigen und dabei möglichst in Echtzeit stattndenden Kommunikation zwischen mehreren Personen. Die Begrie gleichzeitig und Echtzeit denieren sich dabei durch die sofortige, sichtbare Veränderung an einem Dokument welche von anderen Personen verursacht wurde. Der Google Wave Operational Transformation Algorithmus muss somit schnell und zuverlässig sein. Der Jupiter OT verwendet bereits lokale Dokumentenkopien, um lokale Operationen sofort auf das Dokument anwenden zu können. Somit sind keine Wartezeiten gegenüber einer Synchronisierung über das Internet vorhanden. Neben den lokalen Kopien werden bei OT bereits Operationen gebündelt und geschlossen an einen zentralen Dokumentenserver geschickt. Somit ist die Übertragungslast verteilt und nicht kontinuierlich. Dies schont im Hinblick auf mobile Endgeräte den Akku. Remote Operationen werden vor der Anwendung auf das lokale Dokumentenmodell mittels OT transformiert, um Konikte mit parallelen Operationen zu vermeiden. Im Fall von Wave, wird OT auf Wavelets angewendet, da deren Dokumente und Nutzer sich jederzeit ändern können. All die genannten Herausforderungen werden bereits durch den Jupiter OT umgesetzt. Der Zweck von Apache Wave ist die gleichzeitige Kommunikation von mehreren Personen. Dies bedeutet, dass mehrere Clients über einen zentralen Server in Verbindung stehen. Durch die Verwendung eines Zustandsgraphen werden Client und Server in einen synchronen Zustand 5 No-Op steht für No Operation und stellt eine Operation ohne Änderung dar. Dies tritt bei Operationen auf, die sich Gegenseitig aufgehoben haben. 6 Bei der Datenübertragung wird ein Acknowledgement-Signal als Quittierung für erhaltene oder verarbeitete Daten versendet und kurz als ACK bezeichnet. 12 Kapitel 2 Grundlagen

22 Abbildung 2.7: Dokumentenstruktur eines Wavelet Operation retain insert characters insert element start insert element end delete characters delete element start delete element end replace attributes update attributes annotation boundary Beschreibung Bewege Cursor Zeichen hinzufügen Starttag hinzufügen Endtag hinzufügen Zeichen löschen Starttag löschen Endtag löschen Attibute ersetzen Attribute aktualisieren Annotationsreichweite Tabelle 2.4: Übersicht aller möglichen Wave Operationen überführt. Dabei wird jeweils ein Zustandsgraph pro Client verwaltet, was einen hohen Speicherbedarf erfordert und zusätzlich die Rechenlast für den Server erhöht, da dieser einen gemeinsamen Zustand für alle Clients erarbeiten muss. Da ein exibler und ezienter Server von groÿer Bedeutung ist, führte Google eine Wartezeit für Clients ein bevor diese weitere Operationen an den Server senden können. Um genau zu sein, kann ein Client immer nur eine Operation an den Server senden und muss dann auf ein ACK-Signal für die erfolgreiche Anwendung auf das zentrale Dokument warten. In dieser Wartezeit, werden weiterhin alle lokalen Operationen auf das lokale Dokument angewendet und dann in einem Operation Composer gebündelt. Jede remote Operation wird dabei vom Client selber transformiert und an seine Operationen angepasst. Mit eintreen des Acknowledgement hat der Server die Client Operation auf sein Dokument angewendet und die dabei transformierte Operation an alle weiteren Clients weitergeleitet. Der Client kann dann alle gebündelten und bereits transformierten Operationen an den Server übertragen. Durch dieses Verfahren folgt der Client dem Zustandspfad des Servers und ist dennoch exibel in seiner Ausführung. Zusätzlich braucht der Server nicht mehr einen Zustandsgraphen für jeden Client, sondern einen Zustandsgraphen der als Operationsverlauf dient. Jede Clientoperation wird somit gegen den Verlauf transformiert, auf das Dokument angewendet, an die anderen Clients verschickt und im Operationsverlauf gespeichert. Ein Nachteil entsteht jedoch mit der beschriebenen Anpassung des OT Algorithmus. Der Client sieht überüssige Änderungen von anderen Clients für die Dauer des Operationsaustausch zwischen zwei Clients über einen Server. Jedoch wurde dies als Kompromiss für die Erweiterung der Serverseite akzeptiert. Die Kapselung von Änderungen in Form von Operationen wurde bereits mehrfach genannt. Ebenso das OT für jede Operation die passende Transformationsfunktion benötigt. Am Beispiel von Apache Wave gibt es Wavelet Operationen. Solche Operationen unterteilen sich in Dokumentenoperationen und Aufgabenoperationen. Aufgabenoperationen sind Beispielsweise das hinzufügen oder entfernen von Teilnehmer einer Wavelet. Dokumentenoperationen sind jegliche Änderungen am Dokumenten, sei es das Hinzufügen von Wörtern, Tags oder bewegen des 2.5 Google Wave Operational Transformation 13

23 Cursors. Im Zusammenhang mit OT haben Dokumentenoperationen einen speziellen Schwerpunkt im Vergleich zu Aufgabenoperationen. In Apache Wave wird jeder Buchstabe, jedes Start- oder Endtag im Dokument als Item bezeichnet. Lücken zwischen Items werden Positionen genannt. Ein Cursor bewegt sich auf Positionen und über Items hinweg. Da Apache Wave ein Rich-Text-Editor ist, unterstützt es Annotationen um Abschnitte zu formatieren. Eine Annotation besitzt dabei eine Reichweite von Zeichen und die Zeichenformatierung. Abbildung 2.6 verdeutlicht den Aufbau noch einmal grasch. Aus dem Dokumentenaufbau und den Funktionalitäten eines Nachrichteneditors lässt sich eine begrenzte Anzahl an Operationen für Apache Wave zusammen stellen. Zum einen werden Operationen für das hinzufügen und löschen von Buchstaben sowie Tags benötigt, zum anderen Operationen um Attribute zu ersetzen oder zu aktualisieren. Eine Operation um den Cursor im Dokument zu bewegen und eine für Annotationen. Somit setzt sich Apache Wave aus 10 möglichen Operationen, die noch einmal in Tabelle 2.4 aufgeführt sind, zusammen. Apache Wave verwendet einen Operation Transformer um die ganze OT Logik darin zu kapseln. Der Transformer nimmt zwei Operationen entgegen, dekomponiert diese, wendet OT darauf an und komponiert das Ergebnis. Das Resultat sind zwei transformierte Operationen die an weitere Clients verteilt werden können. Die Komposition erfolgt vom Operation Composer, welcher ebenfalls auf Clientseite vorhanden ist, um lokale Operationen zu bündeln. Die genaue Funktion des Composer und wie dessen Algorithmus beschrieben ist ndet sich in der Arbeit [10] wieder. Der Operation Decomposer spaltet die zuvor gebündelten Operationen in einzelne auf, um darauf den OT Algorithmus anwenden zu können. 2.6 ANDROID Die wesentliche Grundlage für die heutigen Smartphones sind deren mobile Betriebssysteme. Die führenden Hersteller sind Google mit Android, Windows mit Windows Phone 7 und Apple mit dem iphone 8. Jedes dieser Betriebssysteme ist für die mobile Entwicklung auf kleinen Geräten ausgelegt und unterstützt verschiedene multimediale Inhalte sowie Positionsbestimmung und drahtlose Kommunikation. Im Rahmen dieser Arbeit wurde das Android Betriebssystem von Google zur weiteren Vertiefung der Implementierung ausgewählt. Dennoch soll das später vorgestellte Konzept auch Einzug in andere Systeme nden, um die Cross-Plattformentwicklung zu ermöglichen. Das Android Betriebssystem wurde 2007 von der Open Handset Alliance 9 vorgestellt und wird seitdem von den Android Developers 10 der Firma Google weiter vorangetrieben. Der Gedanke von Open Source Projekten ist seit dem Start von Android ein wesentlicher Bestandteil. Noch heute werden im Laufe der Zeit die unterschiedlichen Versionen zur freien Verfügung gestellt. Projekte wie Cyanogenmod 11 greifen auf diese Veröentlichungen zurück und fügen weitere, zum Teil von der Android-Gemeinschaft gewünschte, Funktionalitäten hinzu. Mittlerweile ist Android nicht nur ein Betriebssystem für Smartphones, sondern auch für Navigationssysteme, Fernsehgeräte und Kameras. Der Erfolg dieser Plattform wird durch viele verschiedene Gerätehersteller vorangetrieben. Das Besondere am Android OS ist seine Architektur. Diese gliedert sich in vier Schichten: Linux-Kernel, Laufzeitumgebung und Bibliotheken, Anwendungsrahmen und der eigentlichen Anwendungsschicht. Ein wesentlicher Teil von Android stammt vom freien Betriebssystem Linux. Der verwendete Linux-Kernel liefert die nötigen Gerätetreiber und wurde mit Blick auf Energieverbrauch und Speichermanagement optimiert. Die Dalvik Virtual Machine (DVM) ist eine eigens angepasste Laufzeitumgebung von Dan Bornstein und basiert auf der quelloenen Java Virtual Machine (JVM) Apache Harmony. Auch in der DVM wurden spezielle Anpassungen für mobile Endgeräte getätigt. Wird eine Android Anwendung gestartet, so wird ein neuer Betriebssystemprozess mit einer eigenen DVM erzeugt, in dieser die Anwendung ausgeführt wird. Dieser Vorgang ist zwar sehr aufwendig, dennoch liefert es in puncto Sicherheit einige Vorteile. Da das Erzeugen der nötigen Anwendungsressourcen sehr teuer ist, werden Anwendungen erst dann vom System beendet, wenn die nötigen Ressourcen für andere Anwendungen knapp werden. Dadurch entsteht eine Performance-Steigerung beim Start von Anwendungen. Die DVM basiert zwar auf einer JVM, dennoch führt diese Dalvik-Bytecode aus. Jede Android Anwendung wird in der Programmiersprache Java geschrieben und von einem developer.android.com Kapitel 2 Grundlagen

24 Abbildung 2.8: Architektur der Android Plattform Java Compiler in Java-Bytecode übersetzt. Für die Nutzung dieser Anwendung in der DVM, übersetzt ein Dalvik Compiler den Java-Bytecode in Dalvik-Bytecode mit der Dateiendung.dex. Durch die Erzeugung eines eigenen Betriebssystemprozesses haben Anwendungsabstürze keinen Einuss auf das restliche System, womit die Systemstabilität unterstützt wird. Weitere Informationen sowie Hinweise zur DVM nden sich in [12]. Der Anwendungsrahmen sowie die Anwendungen selber greifen auf die Android Bibliotheken zurück, welche bereits wesentliche Funktionalitäten wie Datenbanken oder 2-D-, 3-D-Grakbibliotheken mitbringen. Der Anwendungsrahmen bildet die Schnittstelle zwischen Anwendung und Hardwarekomponenten. Dieser stellt Managementklassen zur Verfügung, welche wiederum in Anwendungen verwendet werden, um beispielsweise eine Internetverbindung zu etablieren. In der Anwendungsschicht laufen Applikationen von Google oder frei entwickelte. In dieser Schicht erfolgt die Interaktion mit dem Nutzer und die Kommunikation mit anderen Anwendungen. Dabei können Anwendungen auf die darunter liegenden Schichten zugreifen und deren Funktionalitäten nutzen. Abbildung 2.7 zeigt die eben beschriebene Architektur noch einmal in der Zusammenfassung. Eine Android Anwendung kann aus vier verschiedenen Hauptkomponenten bestehen. Eine Activity stellt eine grasche Oberäche zur Verfügung. Diese verwaltet alle anzuzeigenden Elemente sowie die Interaktionen mit dem Nutzer. Ein Service dient für längere Verarbeitungen und benötigt keine Oberäche. Ein Service kann beispielsweise eine Musikanwendung sein, bei der ein Nutzer Musik hören kann und gleichzeitig mit einem Webbrowser Inhalte vom Internet ansehen kann. Ein Content-Provider dient als Schnittstelle für Informationen. Diese können aus einer Datenbank oder einem Web Service kommen. Die letzte Komponente ist ein Broadcast Receiver welcher die Android Nachrichten in Form von Intents empfangen kann. Somit können asynchrone und systeminterne Nachrichten verarbeitet werden. Services und Content-Provider können ebenfalls für andere Anwendungen zur Verfügung gestellt werden. Beispiele sind dabei der Google-Kalender oder das Google-Kontaktbuch, welche bereits vorinstalliert sind. Activities können globale Funktionalitäten anbieten. Zum Beispiel eine Internetseite önen, wenn eine URL an das Androidsystem via Intent verschickt wird. Zum Abschluss soll das Thema Sicherheit angeschnitten werden. Wie bereits genannt, werden Android Anwendungen in einem eigenen Betriebssystemprozess, in einer eigenen DVM, ausgeführt. Dies entspricht dem Sandbox-Prinzip in dem bestimmte Funktionalitäten, wie Änderungen am Betriebssystem, verboten sind. Jede Anwendung hat ihren eigenen Speicher und kann somit keine Änderungen am Speicher von anderen Anwendungen vornehmen. Um den Nutzer über die Funktionalitäten einer Anwendung in Kenntnis zu setzen, werden Permissions (Rechte) vergeben. Eine Permission kann die Abfrage des Netzwerkstatus oder der Zugri auf das Kontaktbuch sein. Durch solche Permissions kann die Sandbox einer Anwendung kontrolliert geönet werden. Jede Permission muss im Android-Manifest deklariert sein. Eine Anwendung 2.6 Android 15

25 muss, vor der Installation auf einem Gerät, signiert werden. Signieren bedeutet, die Anwendung mit einer digitalen Unterschrift zu versehen. Dafür wird ein Zertikat verwendet, welches vom Anwendungsentwickler eigenständig erstellt wurde und bei diesem verwahrt wird. Android führt Anwendungen, die mit demselben Zertikat signiert wurden, in derselben Sandbox aus. Somit teilen sich diese einen Prozess sowie Speicher und können dadurch aufeinander zugreifen, solange dies im Manifest der Anwendung deklariert ist. Beim Signieren der Anwendung wird diese in ein Android-Package (APK) gepackt und kann folglich im Google PlayStore 12 oder per Internet auf jedem Android Gerät installiert werden. Weitere Hinweise sowie Beispiele zur Implementierung nden sich in [13] und [14]. Als Ergänzung kann das Kapitel Android von [8] gelesen werden. 12 play.google.com 16 Kapitel 2 Grundlagen

26 3 ANFORDERUNGSANALYSE Das in dieser Arbeit zu entwickelnde Framework soll die spätere Erweiterung von mobilen Anwendungen von einer Single-User zu einer Multi-User Anwendung erleichtern. Die dabei entstehende Lösung wird in diesem Kapitel mittels einer Anforderungsanalyse näher speziziert. In den folgenden Abschnitten werden die funktionalen Anforderungen sowie die nicht-funktionalen Anforderungen an eine mobile kollaborative Anwendung anhand von typischen Anwendungsfällen herausgearbeitet und tabellarisch erfasst. Dabei werden Muss-Kriterien mit einer hohen Anforderungspriorität versehen während Kann- und Soll-Kriterien eine niedrigere Priorität erhalten da diese nicht so relevant in ihrer Umsetzung sind. 3.1 FUNKTIONALE ANFORDERUNGEN Die zentrale Anforderung an eine kollaborative Anwendung ist die Bearbeitung von Objekten durch Nutzer, die Teil derselben Sitzung sind. Dabei werden die Änderungen eines Nutzers in Echtzeit an die anderen Sitzungsteilnehmer übertragen. Um Teilnehmer einer Sitzung werden zu können, muss ein Nutzer sich gegenüber dem System authentizieren. Somit wird eine Anmelde- (REQ-FUNC-1) und Abmeldefunktion (REQ-FUNC-1.1) benötigt. Für neue Nutzer muss es die Möglichkeit einer Registrierung (REQ-FUNC-1.2) geben. Nachdem ein Nutzer sich gegenüber dem System authentiziert hat, kann dieser nach Sitzungen suchen (REQ-FUNC-1.3) sowie selber neue erstellen (REQ-FUNC-1.4). Ein Nutzer kann sein Prol und das von anderen einsehen (REQ-FUNC-1.5), wobei das persönliche zusätzlich bearbeitet werden kann (REQ-FUNC-1.6). Ist ein Nutzer einer Sitzung beigetreten, so erhält er ein Objekt, welches von allen Teilnehmern derselben Sitzung gemeinsam bearbeitet werden kann. Dieses Objekt kann bereits durch vorherige Sitzungen verändert worden sein und Änderungen beinhalten. Das Objekt kann nun mittels verschiedener Operationen manipuliert bzw. verändert werden. Am Beispiel von Apache Wave ist solch ein Objekt eine Nachricht und kann gelöscht, bearbeitet, verlinkt und kommentiert (REQ-FUNC-1.7) werden. Jeder Teilnehmer kann ebenfalls neue Objekte der Sitzung hinzufügen (REQ-FUNC-1.8). Ein Nutzer der Teilnehmer einer Sitzung ist kann sich jederzeit von dieser abmelden und anderen Sitzungen beitreten (REQ-FUNC-1.9) bzw. weitere Teilnehmer zu einem späteren Zeitpunkt hinzufügen (late join) oder einladen (REQ-FUNC-1.10). Ein besonderes Interesse liegt auf der Echtzeitkommunikation. Dadurch werden die Änderungen von anderen Teilnehmern in nahe zu Echtzeit angezeigt (REQ-FUNC-2). Die Hauptfunktionalität einer Kollaboration liegt in der gemeinsamen Bearbeitung eines Objektes ohne das Auftreten von Konikten zwischen den Änderungen dieses Objektes (REQ-FUNC-2.1). Dabei soll eine Nebenläugkeitskontrolle zur Koniktbehebung (REQ-FUNC-2.2) verwendet werden. Diese beiden Punkte tragen entscheidend zum Multi-User Gedanken bei. Neben dem Kollaborationsaspekt ist das mobile Endgerät an sich nicht zu vergessen. Wie bereits am Anfang dieser Arbeit erwähnt, haben mobile Anwendungen bestimmte Herausforderungen zu meistern. Dazu zählt eine schwankende Verbindungsrate bzw. die abrupte Unterbrechung einer Verbindung (REQ-FUNC-2.3). Das Ziel des Framework soll es sein, bei Unterbrechung der 17

27 Abbildung 3.1: Anwendungsfälle am Beispiel von Apache Wave Internetverbindung von einem Multi-User Mode in einen Single-User Mode zu wechseln (REQ-FUNC-2.4) und dabei Operationen, die im Single-User Mode getätigt wurden, für eine spätere Wiederverbindung mit dem Internet zu speichern (REQ-FUNC-2.5) und dann zu senden. Dadurch sollen Datenbestände, die lokal vorgehalten werden, wieder mit einem zentralen System synchronisiert werden (REQ-FUNC-2.6). Ebenfalls wichtig bei mobilen Geräten ist deren Gröÿe. Mit dem Erfolg von Tablets ist mehr Platz auf einem Display vorhanden und ermöglicht somit die zusätzliche Anzeige von Informationen. Das Framework soll somit weitere Möglichkeiten für die dynamische Erweiterung von Inhalten ermöglichen (REQ-FUNC-2.7) um beispielsweise eine Statusanzeige über den Anwendungsmodus oder die Internetverbindung anzuzeigen. Selbstverständlich soll mit dem Editieren von Objekten die eigentliche Kommunikation zwischen einem oder mehrerer Personen ebenfalls Bestandteil der Lösung sein. In Tabelle 3.1 sind alle eben genannten funktionalen Anforderungen aufgelistet. Abbildung 3.1 zeigt stattdessen die Funktionen am Beispiel von Apache Wave. 3.2 NICHT-FUNKTIONALE ANFORDERUNGEN Um die speziellen Anforderungen an das Framework umsetzen zu können, werden im folgenden Abschnitt die technischen Anforderungen näher erläutert. Da als Beispielimplementierung das Apache Wave Framework als Grundlage verwendet wird, müssen auch dessen besondere technische Gegebenheiten berücksichtigt werden. Darauf folgen werden die Qualitätsanforderungen, da diese durch die technischen Aspekte beeinusst werden Technische Anforderungen Da diese Arbeit den Schwerpunkt mobile Entwicklung hat, stellt die Integration von kollaborativen Funktionen in mobile Geräte eine technische Anforderung dar (REQ-TECH-1). Da die grundlegenden kollaborativen Funktionen von Apache Wave verwendet werden, wird die Extraktion dieser Komponenten (REQ-TECH-1.1) nötig sein sowie eine Kommunikationsschnittstelle zu einem bestehenden Wave Server (REQ-TECH-1.2). Die Verwendung von WebSockets sowie Wave spezische Protokolle muss dabei ebenso für mobile Geräte ermöglicht werden (REQ-TECH-1.3). Da bisher nur eine Browser basierte Clientimplementierung für Apache Wave existiert, muss zunächst eine Lösung für Android implementiert werden (REQ-TECH-1.4). Zur Nutzung des Apache Wave Server wird eine Verbindung über das Internet mittels Android etabliert (REQ-TECH-1.5). Den begrenzten Ressourcen eines mobilen Gerätes muss besondere Aufmerksamkeit gewidmet werden (REQ-TECH-2). So ist die Rechenleistung nicht so hoch wie bei einem Desktop-PC, wie es ein Server beispielsweise ist. Da Apache Wave mit einer lokalen Dokumentenkopie arbeitet, muss die nötige Rechenkapazität bedacht werden (REQ-TECH-2.1). Um die Netzwerklast zu minimieren, 18 Kapitel 3 Anforderungsanalyse

28 Bezeichnung Funktion Priorität REQ-FUNC-1 Nutzer am System anmelden Muss REQ-FUNC-1.1 Nutzer am System abmelden Muss REQ-FUNC-1.2 Nutzer am System registrieren Muss REQ-FUNC-1.3 Sitzung suchen Soll REQ-FUNC-1.4 Sitzung erstellen Muss REQ-FUNC-1.5 Teilnehmerprole ansehen Kann REQ-FUNC-1.6 Eigenes Prole bearbeiten Kann REQ-FUNC-1.7 Direkte Änderung von Objekten Soll REQ-FUNC-1.8 Objekte erstellen Muss REQ-FUNC-1.9 Teilnehmer aus Sitzung entfernen Kann REQ-FUNC-1.10 Teilnehmer aus Sitzung hinzufügen Kann REQ-FUNC-2 Automatische Aktualisierung der Oberäche Muss REQ-FUNC-2.1 Multi-User Bearbeitung von Objekten Muss REQ-FUNC-2.2 Nebeläugkeitskontrolle Muss REQ-FUNC-2.3 Dynamische Datenrate Soll REQ-FUNC-2.4 Unterstützung von Single-User und Multi-User Modes Soll REQ-FUNC-2.5 Oine Speicherung von Operationen Soll REQ-FUNC-2.6 Datensynchronisierung Muss REQ-FUNC-2.7 Gröÿenanpassbare Oberäche Kann Tabelle 3.1: Funktionale Anforderungen ist ein persistentes Speichern des kollaborativen Dokumentes auch auf Clientseite zu berücksichtigen (REQ-TECH-2.2). Dabei ist die mögliche Speicherkapazität eines Gerätes mit einzubeziehen. Die unterschiedlichen Displaymaÿe ermöglichen das Anzeigen von unterschiedlichen Inhalten (REQ-TECH-2.3). Die besonderen Eingabemöglichkeiten sollten ebenfalls berücksichtig werden. So sind neben virtueller Tastatur, ein Touchscreen, Funktionstasten oder Gestik sowie Haptik möglich (REQ-TECH-2.4). Trotz Verlust einer Internetverbindung kann eine mobile Anwendung weiterhin betrieben werden. Der Wechsel von Multi-User zu Single-User Anwendung ist dabei entscheidend. Um die Änderungen für den Server im Single-User Mode nicht zu verlieren, müssen diese auf dem mobilen Gerät ebenfalls persistent gespeichert und bei bestehender Internetverbindung übertragen werden können (REQ-TECH-2.5). In Tabelle 3.2 wurde ebenfalls eine Zusammenstellung aller eben genannten Kriterien erstellt. Bezeichnung Funktion Priorität REQ-TECH-1 Integration in Android Muss REQ-TECH-1.1 Adapter zur Kollaboration mittels Apache Wave Muss REQ-TECH-1.2 Adapter zur generischen Kommunikation Muss REQ-TECH-1.3 Kommunikation mit WebSockets und Wave Protokollen Muss REQ-TECH-1.4 Anbindung an Android mittels Adapter Muss REQ-TECH-1.5 Verwendung einer schwankenden Internetverbindung Muss REQ-TECH-2 Möglichkeiten von mobilen Ressourcen beachten Soll REQ-TECH-2.1 Nötige Rechenleistung auf dem Client gering halten Soll REQ-TECH-2.2 Persistente Dokumentenkopien auf dem Client Soll REQ-TECH-2.3 Rücksicht der unterschiedlichen Displaygröÿe Kann REQ-TECH-2.4 Verschiedene Eingabemöglichkeiten beachten Kann REQ-TECH-2.5 Speicherung von Änderungen ohne Internetverbindung Soll Tabelle 3.2: Technische Anforderungen 3.2 Nicht-funktionale Anforderungen 19

29 Abbildung 3.2: Merkmale der Softwarequalität aus der ISO Norm ISO/IEC Qualitätsanforderungen Als Referenz zur Bestimmung von Qualität wird die ISO-Norm ISO/IEC verwendet. Diese Norm wurde von der Internationalen Organisation für Normung 1 herausgegeben und ersetzt seit 2005 die ISO/IEC 9126, welche bis dahin die wesentlichen Qualitätsmerkmale für Software umfasste. Dabei ist zu beachten, dass diese Normen die Software als Produkt betrachten und somit die Produktqualität im Vordergrund steht. Dabei werden nur indirekt der Entwicklungsprozess der Software und deren Qualität berücksichtigt. In [15] wird über die sechs Hauptkriterien, welche sich aus Funktionalität, Zuverlässigkeit, Benutzbarkeit, Ezienz, Portabilität und Wartbarkeit zusammensetzen, gesprochen und wie diese sich in feinere Qualitäten unterteilen lassen. Ein kurzer Überblick ndet sich ebenfalls unter [16] oder in Abbildung 3.2. Für die Qualitätsanforderungen des Framework sind in puncto Funktionalität (REQ-QUAL-1) die Kriterien Korrektheit (REQ-QUAL-1.1) und Sicherheit (REQ-QUAL-1.2) ein wichtiger Punkt. Korrektheit, gerade im Zusammenhang mit kollaborativen Dokumenten, hat eine zentrale Rolle. Der Anwendungsnutzer sowie der spätere Software-Entwickler muss sich der Korrektheit der einzelnen Operationen und somit der Konsistenz des Dokumentes gewiss sein. In puncto Sicherheit stellt bereits Apache Wave einiges an Funktionalität zur Verfügung. Zugrisrechte und Kryptograe sind nur einige Bestandteile davon. Weitere Details dazu nden sich in [1] und [17]. Bei der Zuverlässigkeit (REQ-QUAL-2) ist Fehlertoleranz (REQ-QUAL-2.1) und Wiederherstellbarkeit (REQ-QUAL-2.2) zu nennen. Fehlertoleranz im Zusammenhang mit der Darstellung eines inkonsistenten Dokumentes, wobei die Zeit so gering wie möglich gehalten werden soll. Die Wiederherstellung von Daten ist bei schwankenden Verbindungsraten bzw. Verbindungsverlust relevant. Bei der Benutzbarkeit (REQ-QUAL-3) ist im Wesentlichen der geringe Platz von Bedienelementen auf einem mobilen Gerät entscheidend. Deshalb sollte die angebotene Funktionalität im Zusammenhang mit der Displaygröÿe stehen (REQ-QUAL-3.1). Bei Ezienz (REQ-QUAL-4) ist die Reaktionszeit einer Kollaboration (REQ-QUAL-4.1) zu nennen [18]. So sollten die sichtbaren Änderungen entfernter Teilnehmer nicht länger als zwei Sekunden Verzögerung aufweisen (REQ-QUAL-4.2). Lokale Änderungen sollten mit etwa 200 ms Verzögerung angezeigt werden (REQ-QUAL-4.3). Beim Kriterium für Änderbarkeit (REQ-QUAL-5) seien Stabilität (REQ-QUAL-5.1) und Modizierbarkeit (REQ-QUAL-5.2) genannt. Für eine stabile Kollaboration sollte eine Anpassung an verfügbare Verbindungsqualität möglich sein. So wird bei einer verfügbaren WLAN Verbindung auf diese gewechselt, statt mit einer langsameren mobilen Verbindung weniger Datenpakete zu übertragen. Die Anzahl der Teilnehmer sollte ebenfalls dynamisch sein wobei für Apache Wave keine Teilnehmergrenze bekannt ist. Solche dynamischen Eigenschaften sollten vom Framework später unterstützt werden. Zum Schluss sei noch die Übertragbarkeit (REQ-QUAL-6) genannt. Eine generelle Kapitel 3 Anforderungsanalyse

30 Bezeichnung Funktion Priorität REQ-QUAL-1 Funktionalität Muss REQ-QUAL-1.1 Die Anwendung soll richtig und konsistent arbeiten Muss REQ-QUAL-1.2 Sicherheit der Daten soll gewährleistet werden Soll REQ-QUAL-2 Zuverlässigkeit Muss REQ-QUAL-2.1 Fehlertoleranz gegenüber der Synchronisierung Soll REQ-QUAL-2.2 Wiederherstellung der Daten bei verlust Soll REQ-QUAL-3 Benutzbarkeit Muss REQ-QUAL-3.1 Funktionen im Rahmen des möglichen Platzes Soll REQ-QUAL-4 Ezienz Soll REQ-QUAL-4.1 Echtzeitkommunikation bei Kollaboration Muss REQ-QUAL-4.2 Max. zwei Sekunden für entfernte Änderungen Soll REQ-QUAL-4.3 Max. 200 ms für lokales Feedback Soll REQ-QUAL-5 Änderbarkeit Soll REQ-QUAL-5.1 Variable Datenübertragung und Verbindung Kann REQ-QUAL-5.2 Festlegung der Teilnehmergröÿe Kann REQ-QUAL-6 Übertragbarkeit Soll REQ-QUAL-6.1 Wiederverwendbarkeit des Frameworkkonzeptes Muss Tabelle 3.3: Qualitätsanforderungen Übertragung auf ein anderes mobiles Betriebssystem, wie Windows Phone oder iphone, ist nicht ohne gröÿeren Entwicklungsaufwand realisierbar, da jedes unterschiedliche Programmiersprachen verwendet. Was allerdings übertragbar ist bzw. sein soll, ist das Konzept (REQ-QUAL-6.1), welches sich hinter dem entstehenden Framework verbirgt. Auf das Konzept wird in einem späteren Kapitel nähe eingegangen, sei aber an dieser Stelle bereits genannt. Die Übertragung auf ein mobiles Gerät sollte dabei aber keine Herausforderung darstellen. Tabelle 3.3 repräsentiert eine Zusammenfassung der eben festgestellten Qualitätsanforderungen. 3.3 ZUSAMMENFASSUNG In diesem Kapitel wurde auf die funktionalen Anforderungen eines mobilen und kollaborations unterstützenden Frameworks eingegangen. Dabei wurde speziell auf die technischen Anforderungen im Zusammenhang des Apache Wave Server eingegangen. Abschlieÿend wurden Qualitätsanforderungen an mobile Applikationen und real-time groupware Anwendungen nach dem ISO-Standard erfasst. Im Rahmen der praktischen Umsetzung dieser Arbeit wird der Schwerpunkt auf der Clientseite liegen und somit auf der Integration von kollaborativen Funktionen in ein mobiles System. Dabei wird ein bestehendes kollaboratives System, am Beispiel von Apache Wave, genutzt und eine Verbindung über das Internet verwendet. Als mobiles System wird das Betriebssystem Android verwendet. Die Kommunikation mittels Client und Server wird mit verschiedenen Protokolle realisiert. Eine Extraktion der Serverfunktionalitäten um einen schlanken kollaborativen Server zu erstellen, sowie die spätere Integration in die Mobilis-Plattform der Technischen Universität Dresden, soll in dieser Arbeit nicht weiter vertieft werden. Aus diesem Grund sind alle dokumentierten Anforderungen mehr auf die Kommunikation sowie die Implementierung des Clients speziziert. All die genannten Anforderungen werden mittels eines Adapterkonzeptes umgesetzt, auf das in den folgenden Kapiteln näher eingegangen wird. Somit wird die zentrale Rolle ein generischer und somit wiederverwendbarer Adapter für kollaborative Zwecke einnehmen. 3.3 Zusammenfassung 21

31 22 Kapitel 3 Anforderungsanalyse

32 4 VERWANDTE ARBEITEN Nachdem im Kapitel 2 die Funktionsweise von kollaborativen Algorithmen (2.3, 2.4), der Aufbau des Apache Wave Framework (2.1) und die Technik von WebSockets (2.2) und Android (2.6) beschrieben wurde, handelt dieses Kapitel von dem Vergleich bereits erforschter Ansätze und Konzepte zur ezienten Integration von kollaborativen Funktionen in bereits bestehende Anwendungen. Sowohl theoretische Aspekte als auch konventionelle Umsetzungen sollen eine Basis für weitere Teile dieser Belegarbeit bilden. Abschlieÿend werden die vorgestellten Arbeiten für die weitere Nutzung und Anpassung an mobile Umgebungen im Abschnitt 4.3 verglichen. 4.1 GOOGLE DRIVE REALTIME API Im Jahr 2013 kündigte die Firma Google ihre Google Drive Realtime API an. Nach der Übergabe von Google Wave an Apache, ist die Realtime API das nächste Projekt zur kollaborativen Nutzung von Dokumenten und Dateien. Nachdem Erfolg von Google Docs, Sheets und Slides können Entwickler auf vergleichbare Funktionen mittels der Realtime API zugreifen, um eine Kollaboration ihren Anwendungsnutzern zu ermöglichen. Die API verwendet dabei Dokumente aus dem online Speicher Google Drive. Ein Dokument wird dabei im Zusammenhang mit der Realtime API als Modell bezeichnet und vom Entwickler entworfen. Das Modell kann dabei aus Listen, Maps und individuellen Objekten bestehen. Die Modellstruktur kann Bäume oder beliebige Graphen abbilden. Das Datenmodell hat dabei den Anspruch einer gemeinsamen Nutzung und Bearbeitung. Dieser Aspekt muss vom Entwickler beim Entwurf berücksichtigt Abbildung 4.1: Zusammenarbeit von Anwendung, API und Drive. 23

33 (a) Überblick des Cross-Platform-Development Ansatzes (b) Ablauf des Modell Import über einen JSON REST- Service. Abbildung 4.2: Die Google Drive Realtime API stellt bereits unterstützende Funktionen für die Entwicklung zur Verfügung. [19] werden. Im Anschluss daran wird das Modell per Upload in Google Drive gespeichert und fortan für alle Kollaborateure zur Verfügung gestellt. Jeder Nutzer besitzt eine lokale Kopie im Hauptspeicher seines Gerätes. Im Vergleich zu anderen Modellen kann dieses spezielle kollaborative Modell durch die Bearbeitung von allen Teilnehmern einer Sitzung verändert werden. Zur Manipulation des Datenmodells wird die Realtime API verwendet. Diese API ermöglicht den Zugri auf den Collaboration Service von Google Drive, um somit eine Modellsynchronisation zwischen mehreren Teilnehmern zu ermöglichen. Zum aktuellen Zeitpunkt dieser Arbeit liegt die API in der JavaScript Programmiersprache vor. Die API verarbeitet weiterhin die Netzwerkkommunikation, den Speicher, die Anwesenheit von Teilnehmern und Koniktbehebung. Jede Änderung am Modell wird dabei Mutation genannt und in einem Verlauf online gespeichert. Mittels EventHandler kann der Entwickler Mutations am Modell verfolgen, um die Anwendungsoberäche zu aktualisieren. Lokale Änderungen werden dabei sofort auf das Modell im Hauptspeicher angewendet und danach zum Server gesendet. Auf diese Weise werden Manipulationen am Modell sofort ersichtlich, auch wenn die Latenzzeiten im Netzwerk lang sind. Der Operational Transformation Algorithmus wird zur Koniktbehebung zwischen Mutations angewandt. Nach erfolgreicher Transformation werden die Mutations auf das Drive Modell angewendet und somit zu allen Teilnehmern übertragen. Die Anwesenheit von Teilnehmer wird dabei ebenfalls von der Realtime API überwacht. Dadurch kann die Bearbeitung des Modells durch einen Teilnehmer verfolgt und für andere angezeigt werden. Weitere Workspace Awareness Funktionen werden nicht unterstützt bzw. wurden dokumentiert. Einige Anwendungen wie die Entwicklungsumgebung Neutron Drive 1, das Planungstool Gantter 2 und die Zeichenanwendung Draw.io 3 verwenden bereits die Google Drive Realtime API. Die Abbildung 4.1 stellt noch einmal alle genannten Bestandteile des Aufbaus grasch dar. Die Realtime API wurde als generische API modelliert und verfolgt dabei das Ziel der Cross-Plattform Entwicklung. So wurde beispielsweise bei der Google I/O 2013 eine Version für die Java-Umgebung angekündigt, womit sich der Einsatzbereich zur mobilen Entwicklung erweitert. Einige Funktionen sollen abschlieÿend zur Realtime API genannt werden. Die Unterstützung von Undo- und Redo-Operationen erhöhen die Verwendbarkeit der Anwendung und steigert die Ezienz bei der späteren Integration durch den Entwickler. Die Reduktion von Netzwerkkommunikation wird durch die Bündelung von Mutations erreicht. So werden schnell geschriebene Buchstabenfolgen in einer Mutation zusammengefasst. Die Export/Import Funktionalität des Datenmodells ermöglicht die Nutzung der API als REST-Service. Mittels der Methoden GET und POST kann das Datenmodell im JSON Format zum Download und Upload kommuniziert werden. Dabei wird ebenfalls die Synchronisation des Modells unterstützt. Ein Vergleichsalgorithmus vergleicht das hochgeladene Modell mit dem Drive Modell und generiert aus den Änderungen Mutations. Diese werden auf das Drive Modell angewendet und dadurch an alle Teilnehmer verteilt. Einen Überblick der eben genannten Funktionen ndet sich in den Abbildungen 4.2 (a) und (b). Eine wissenschaftliche Veröentlichung zu dieser API sowie deren verwendeten Algorithmen wurde bisher nicht getätigt. Eine Video Präsentation auf der Google I/O 2013 mit dem Titel The Secrets of the Drive Realtime API liefert einen Überblick über die Funktionalität und den Aufbau der API. Des Weiteren ndet sich auf der oziellen Website [20] eine Dokumentation sowie unter dem Entwickler-Blog [21] eine Zusammenfassung drive.draw.io 24 Kapitel 4 Verwandte Arbeiten

34 4.2 GENERIC COLLABORATION INFRASTRUCTURE Die Generic Collaboration Infrastructure [22], [23] und [24] beschreibt die eziente Integration von Nebenläugkeitskontrolle und Workspace Awareness in bereits vorhandene Web Applikationen. Mittels der GCI Architektur werden bestehende Teile der Anwendung adaptiert und dadurch mit kollaborativen Funktionen erweitert. Dieser Eingri ist nicht-invasiv und nimmt somit geringen Einuss auf bestehenden Code. Die Wiederverwendung und Kapselung von Funktionalität wird durch eine Architektur aus Komponenten unterstützt. Die Kernkomponenten der GCI sind der DOM-Adapter, Framework-Adapter und Workspace Awareness Adapter. Eine Concurrency Control Komponente dient der Nebenläugkeitskontrolle und wird vom DOM-Adapter sowie Framework-Adapter verwendet. Für die Koniktbehebung wird der De-facto-Standard Operational Transformation angewendet. Auf Basis einer anwendungsunabhängigen API werden Komponenten zur Konikterkennung und Koniktbehebung mit den genannten Adaptern verbunden. Die GCI dient als Lösung der folgenden drei Herausforderungen: Die Heterogenität von Anwendungen erfordert eine spezische Umsetzung von Applikationsoperationen. Beispielsweise sind Schreib- und Zeichenanwendungen disjunkt und lassen sich nicht auf operativer Ebene miteinander vereinheitlichen. Somit sind die Concurrency Control Komponenten auf der Seite des Clients anwendungsabhängig. Die OT Koniktbehebung ist Domain-spezisch und zieht eine Vielzahl an Transformationsfunktionen nach sich. Die Anzahl an benötigten Funktionen steigt dabei quadratisch an. Ein Beispiel dazu zeigt Tabelle 4.1 aus [24]. Eine generische Umsetzung von Funktionen ist deshalb nicht ezient realisierbar. Die invasive Bindung bei der Integration der Nebenläugkeitskontrolle hat einen groÿen Zeitaufwand zur Folge. Sämtliche Modelloperationen müssen im Code erfasst und angepasst werden, wodurch ein invasiver Eingri in die bestehende Anwendung erfolgt. ins(c 2,i 2 ) del(i 2 ) ins(c 1,i 1 ) f 1 (ins(c 1,i 1 ),ins(c 2,i 2 )) f 3 (ins(c 1,i 1 ),del(i 2 )) del(i 1 ) f 2 (del(i 1 ),ins(c 2,i 2 )) f 4 (del(i 1 ),del(i 2 )) Tabelle 4.1: Matrix der OT-Funktionen bei einem Operation-Set von O TE = fins(c,i),del(i)g. [24] Zum Absolvieren der genannten Herausforderungen wurden bereits die benötigten Bestandteile der GCI genannt. Die anwendungsspezischen Operationen werden vom DOM-Adapter und Framework-Adapter angepasst. Der DOM-Adapter verwendet dabei das standardisierte Interface des DOM, während der Framework-Adapter ein Set an Methoden und Strukturen zur Erstellung und Manipulation des Datenmodells bereitstellt. Dabei werden bereits bestehende Bibliotheken zur Nebenläugkeitskontrolle vom Framework-Adapter verwendet und somit die Wiederverwendung und Ezienz erhöht. Die Concurrency Control Komponente wird als OT Engine ein Bestandteil der GCI und erzeugt Transparenz sowie Variabilität für den Algorithmus, da die gesamte Koniktbehebung in einer Komponente gekapselt und somit austauschbar ist. Durch die Umsetzung einer anwendungsunabhängigen API wird die Integration der GCI nicht-invasiv und steigert damit die Ezienz und senkt die Einarbeitungszeit für den Entwickler. Der Workspace Awareness Adapter wurde in der Betrachtung von Herausforderungen sowie deren Überwindung nicht berücksichtigt. Dies liegt an der nicht vorhandenen Notwendigkeit bei Single-User Anwendungen. Die Workspace Awareness betrit die kontextsensitiven Informationen bei der Zusammenarbeit von mehreren Personen zum selben Zeitpunkt. Der Adapter verwendet die transformierten Operationen, um relevante Informationen zum Verhalten der entfernten Nutzer zu extrahieren und anzuzeigen. So können beispielsweise Textcursor von anderen Nutzern oder eine Teilnehmerliste angezeigt werden. Die Anzeigekomponenten von Awareness Information werden Widgets genannt und sind dem Collaboration Editor untergeordnet. Die Widgets dienen der Ergänzung und variieren in der Anzahl. Vergleichbar mit den Transformationsfunktionen von OT, ist eine Verallgemeinerung der Workspace Awareness ebenfalls nicht möglich. Die heterogenen Anwendungen und Operationen erschweren einen generischen Ansatz und setzen das Wissen des Entwicklers darüber voraus. Die groÿe Anzahl an Adaptern und Komponenten sowie deren Verbindungen miteinander können den Entwickler zu Beginn verwirren. Um die Schwierigkeiten am Anfang zu reduzieren, wurde eine methodische Herangehensweise in [24] in der Grak 4.3 präsentiert. Anhand von Fragen und Antworten werden Informationen zur bestehenden Anwendung gesammelt und daraufhin die Notwendigkeit einer Application-Agnostic API sowie nötige Implementierungen von OT-Engine und Workspace Awareness evaluiert. 4.2 Generic Collaboration Infrastructure 25

35 Abbildung 4.3: Methodische Auswahl der Adapter zur Integration in eine bestehende Anwendung. [24] 4.3 BEURTEILUNG Nachdem einige Konzepte und Frameworks zur Umsetzung von kollaborativen Funktionen in den vorangegangenen Abschnitten erklärt wurde, soll in diesem Abschnitt eine Beurteilung über die Portabilität auf eine mobile Plattform erfolgen. Da mobile Anwendungen unterschiedliche Ziele und Herausforderungen im Vergleich zu Web Anwendungen haben, müssen die Konzepte, sowie bereits vorhandene Bibliotheken erweiterbar sein. Dies betrit nicht nur die Implementierung, sondern auch das Konzept dahinter. Das sich wechselnde Umfeld eines mobilen Gerätes beeinusst ebenso die laufenden Anwendungen. Verbindungsverluste, Veränderung der Displaygröÿe und geringer Batteriestand sind nur einige Faktoren auf die eine Anwendung reagieren muss. Das Kriterium der Variabilität ist dadurch eine wichtige Charakteristik im mobilen Bereich. Die Verwendung von Frameworks und Bibliotheken soll die Ezienz der Integration erhöhen und den Entwicklungsaufwand reduzieren. Jedoch muss für den Entwickler eine Transparenz in Zusammenhängen, Algorithmen und daraus resultierenden Folgen existieren. Die plattformunabhängige Entwicklung von mobilen Anwendungen ist ein relevanter Aspekt bei der Konzeption eines Frameworks. Deshalb wird ein relevantes Kriterium für die Auswahl eines Konzeptes bzw. Frameworks zu Weiterentwicklung das Cross-Platform-Development sein. Das Ziel ein ezientes Framework zu entwickeln wird durch eine nicht-invasive Integration begünstigt. Dadurch reduzieren sich die Entwicklungs- und Refaktorierungszeit für den Entwickler. Das Kriterium der Integrierbarkeit ist somit ebenfalls entscheidend. Für die Softwareentwicklung ist die Wiederverwendung von Bestandteilen einer vorherigen Arbeit ein Kriterium für Ezienz. Sowohl Komponenten aus dem Framework dieser Arbeit, als auch daraus resultierende Anwendungen, sollten diesem Kriterium entsprechen. Die Google Drive Realtime API bietet eine Vielzahl an Komponenten und Funktionen für die weitere Entwicklung an. Koniktbehebung, Authentizierung und weitere Funktionen werden mittels einer API angeboten und begünstigen die schnelle Integration in bestehende Anwendungen. Eine Wiederverwendung der Realtime API ist generell möglich, jedoch die konkrete Implementierung zur Adaption an Anwendungen nicht. Der Ansatz einer API und eines Datenmodells demonstrierte eine plattformübergreifende Entwicklung und macht eine Portierung auf andere Systeme anwendbar. Die applikationsspezischen Operationen werden in Form eines Realtime Data Model abgebildet und dadurch eng mit der Anwendung verbunden. Der Austausch sowie die Erweiterung von API Teilen ist nicht möglich. Der Entwickler muss auf die Funktionen der API vertrauen und hat keine Einuss darauf. Die zentralisierte Architektur von Modell und Realtime Servern lässt keine Transparenz zu. Eine konkrete Dokumentation zum Datenaustausch wurde beispielsweise nicht gefunden. Aus den angeführten Punkt lässt sich schlieÿen, dass eine Weiterentwicklung der Realtime API nicht möglich ist. 26 Kapitel 4 Verwandte Arbeiten

36 Google Drive Generic Collaboration Realtime API Infrastructure Erweiterbarkeit + Variabilität + Transparenz + Cross-Platform-Development + + Integrierbarkeit + Wiederverwendbarkeit Legende: + gut angemessen schlecht Tabelle 4.2: Beurteilung der vorgestellten Konzepte für die Portabilität auf mobile Plattformen. Die Generic Collaboration Infrastructure demonstriert die Vielschichtigkeit von Real-Time Groupware Anwendungen. Mit der Umsetzung eines komponentenbasierten Systems, bestehend aus API und Adaptern, können einzelne Bestandteile variiert und erweitert werden. Am Beispiel des Framework-Adapter werden explizit zusätzliche Bibliotheken und Frameworks in die Anwendung etabliert. Die Transparenz wird durch die mehrfach erforderte selbstständige Implementierung erzielt. Da das Konzept plattformunabhängig ist, lässt es sich ohne Probleme auf andere Systeme übertragen. Über eine anwendungsunabhängige API werden weitere Komponenten in die bestehende Anwendung etabliert, was eine minimal-invasive Anpassung des bestehenden Codes zur Folge hat. Somit ist trotz weiterem Implementierungsaufwand eine eziente Integration möglich. Neben dem abstrakten Konzept lassen sich auch einzelne Bestandteile der Infrastruktur in andere Anwendungen integrieren und dadurch wiederverwenden. Für eine konkrete Implementierung ist dies abhängig vom Grad der Anwendungsabhängigkeit, während das gesamte Konzept weiter verwendet und entwickelt werden kann. Es zeigt sich, dass abstrakte und frei verfügbare Frameworks für eine eziente Integration in bestehende Anwendung von Vorteil sind. Ebenso die Portabilität auf andere Systeme lässt sich damit eektiver umsetzen. Somit bietet die Generic Collaboration Infrastructure das gröÿere Potenzial zur Weiterentwicklung an. Es sei jedoch noch genannt, dass die Google Drive Realtime API weiterhin in der Entwicklung ist und die in dieser Arbeit beurteilten Dezite reduziert werden können. 4.4 ZUSAMMENFASSUNG In diesem Kapitel ging es um die Gegenüberstellung zwischen bereits existierenden Konzepten und Bibliotheken zur ezienten Weiterentwicklung von bestehenden Anwendungen zu Multi-User Applikationen. Dabei wurde der Wechsel von Web zu Mobile als Schwerpunkt gesetzt. Die vorgestellten Inhalte stammen sowohl aus Forschung als auch der Industrie. Für die folgenden Kapitel 5 und 6 wurde eine Beurteilung nach verschiedenen Kriterien der Ezienz, Wiederverwendbarkeit und Portabilität erstellt, um somit ein eektives Verfahren für die Integration von kollaborativer Funktionalität weiter zu entwickeln. Dabei zeigte sich, dass die Nebenläugkeitskontrolle und Workspace Awareness nicht generalisierbar sind und somit die Rolle des Entwicklers nicht auÿer Acht gelassen werden kann. 4.4 Zusammenfassung 27

37 28 Kapitel 4 Verwandte Arbeiten

38 5 KONZEPT Für die Entwicklung eines Konzeptes zur Umsetzung eines generischen Frameworks für kollaborative Anwendungen wurde das Generic Collaboration Infrastructure (GCI) Konzept von [24] aufgegrien und für die speziellen Herausforderungen an mobile Anwendungen angepasst. In seiner Arbeit [24] stellt Matthias Heinrich eine Infrastruktur aus Adaptern vor, womit ein dynamisches Framework für kollaborative Zwecke umgesetzt werden kann. Dabei werden verschiedene Adapter für entscheidende Komponenten einer Kollaboration zur Verfügung gestellt und somit einem Entwickler die Möglichkeit gegeben, eine Single-User Anwendung in eine Multi-User Anwendung zu erweitern. Der Entwickler soll dabei so wenige Änderungen wie nötig an seiner bestehenden Codebasis machen müssen. Da es aber keine vollkommene generische Umsetzung eines solchen Frameworks geben kann, wie es auch in [24] erläutert wird, hat der Entwickler selber die Möglichkeit eigene Adapter und Koniktauösungen zu implementieren. Dieses Konzept folgt somit einer dynamischen Erweiterung von bereits bestehenden Komponenten oder der Infrastruktur an sich. Es ist dabei zu beachten, dass der Schwerpunkt beim GCI auf Web Anwendungen liegt. In den folgenden Abschnitten wird auf die wesentlichen Bestandteile vom GCI eingegangen und wie diese im Hinblick auf die Umsetzung in mobilen Anwendungen angepasst werden müssen. 5.1 KERNKOMPONENTEN Die wesentlichen Komponenten der GCI sind der DOM 1 Adapter, der Framework Adapter und der Workspace Awareness Adapter. Der DOM Adapter sorgt für die Anpassung der Modellstruktur durch Änderungen in einer laufenden Kollaboration. Der Framework Adapter verwaltet eine Modellstruktur, die nicht auf dem DOM basiert und liefert, wie auch der DOM Adapter, die nötigen Funktionen für eine Konikterkennung sowie Koniktbehandlung. Der Workspace Awareness Adapter verbindet die Adapter mit speziellen Anzeigekomponenten die selber direkte Änderungen am Modell bewirken können und dabei die Funktionalitäten der Koniktkontrolle mit einbeziehen. In Abbildung 5.1 ist der architektonische Aufbau der GCI noch einmal grasch dargestellt. Die weiÿ markierten Boxen stehen dabei für die Single-User Komponenten und die grau markierten Boxen für die Multi-User Komponenten. Bereits durch diese Trennung wird der Kerngedanke eines generischen kollaborativen Frameworks schnell erkennbar bei dem ein minimal höherer Entwicklungsaufwand von multi- user Anwendungen im Vergleich zu Single User Anwendungen erreicht werden soll. Die Single-User Komponenten stellen zudem eine vollständige Anwendung über mehrere getrennte Schichten dar, bestehend aus Oberäche (Editor UI), speziellen Operationen welche von der Oberäche angeboten werden (Editor API), einer anwendungsunabhängigen Schnittstelle (Applicationagnostic API) und Datenstruktur (Data Model). Die Multi-User Komponenten nehmen dabei keinen Einuss auf die bestehende 1 Document Object Model 29

39 Abbildung 5.1: Architekturüberblick von der Generic Collaboration Infrastructure (GCI) Funkionalität der Anwendung. Insofern zeigt sich die saubere Trennung zwischen einer bestehenden Anwendung und einer gezielten Erweiterung für mehrere Anwender. Die bewusste Aufteilung in die genannten Schichten hat sich beim Vergleich von unterschiedlichen Bibliotheken und Frameworks herauskristalisiert und wird ebenfalls in [24] erläutert. Der zentrale Ansatzpunkt für solch ein Framework ist dabei die anwendungsunabhängige API, welche zwischen Datenmodell und Oberächenoperationen liegt. Basierend auf dem Datenmodell, setzt an dieser Schicht der DOM Adapter oder Framework Adapter an. Beide sind Bestandteil einer Konikterkennung (Concurrency control Adapter) und eines Koniktbehandlungsalgorithmus (Operational Transformation Engine). Der Algorithmus für die Koniktauösung kann dabei vom Entwickler selber geändert oder neu implementiert werden, dennoch wird der Standardalgorithmus der Operational Transformation (OT) Algorithmus sein. Dieser wurde bereits in 2.4 erläutert und ist bereits ein De-facto-Standard. Dies zeigt sich in der groÿen Anzahl an Anwendungen, die diesen bereits verwenden, beispielsweise SAP-Gravity, Google Docs, Etherpad und Apache Wave. Der Workspace Awareness Adapter setzt auf den bestehenden Adaptern auf und nutzt deren Operationsverlauf sowie Anbindung an die Modellstruktur. Somit wird dieser Adapter über die Modellsynchonisierung informiert und kann Oberächen für kollaborative Zwecke anbieten. Alle Konikte die behoben wurden, müssen mit dem Anwendungsmodell synchronisiert sowie über das Internet an weitere Teilnehmer kommuniziert werden. Alle Operationen werden nach der Transformation über das Internet an einen zentralen Server kommuniziert und von diesem an alle weiteren Teilnehmer verteilt. In bisherigen Arbeiten war die Adaption der Kommunikationtechniken irrelevant, da Web Anwendungen generell über das Internet verwendet werden. Mit dem Einsatzgebiet auf mobilen Endgeräten, ist die Anzahl an möglichen Kommunikationwegen gestiegen. Neben dem Internet, haben mobile Endgeräte auch die Möglichkeit von Bluetooth oder NFC 2. Ob solch eine Kommunikationtechnik auch wirklich zum Einsatz kommt sei erst einmal dahin gestellt, dennoch muss im Hinblick auf die Herausforderungen an mobile Endgeräte auch die Kommunikation näher betrachtet werden. Im Abschnitt 5.2 wird darauf näher eingegangen. Die anwendungsunabhängige Schnittstelle ist eine zentrale Schicht im GCI. In dieser werden alle Adapter vereint und fungiert somit als Mediator zwischen Anwendung und kollaborativen Komponenten. Es gibt drei wesentliche Funktionen die diese Schicht gewährleisten muss. Es müssen Events die eine Änderungen am Modell angeben umleitbar, Operationen wiederholbar und Workspace Awareness Widgets integrierbar bzw. aktualisierbar sein. Das Umleiten der Events dient zur Koniktkontrolle, denn diese löst eine Synchronisation des kollaborativen Modells aus und informiert somit weitere Teilnehmer einer Sitzung. Zusätzlich wird die Anzeige der Workspace Awareness Widgets aktualisiert. Das Wiederholen von Operationen dient der Synchronisation des Modells und zur Feststellung des aktuellen Zustands im OT Graphen. Die Zuständigkeit liegt dabei beim Koniktkontrolladapter. Die letzte Anforderung, die Integration von Workspace Awareness Widgets, dient zur Vervollständigung eines generischen kollaborativen Frameworks, ist aber die am schwersten umzusetzende Eigenschaft. Dies liegt in der unbekannten 2 Near Field Communication 30 Kapitel 5 Konzept

40 Modellstruktur sowie die nötige Vorraussetzung der passenden OT Funktionen. Insofern ist eine Schnittstelle für die spätere Implementierung von nöten, aber ein generisches Beispiel kann nur mit Einschränkungen umsetzbar sein. Die Funktionen dieser Anforderung sind die Integration von Workspace Awareness Widgets sowie die Aktualisierung dieser durch Modelländerungen seihen es lokale oder entfernte Events. Solch ein Widget kann zum Beispiel eine Radar View sein, um den Arbeitsbereich der anderen Teilnehmer zu sehen oder eine Teilnehmerliste für derzeitig anwesende Nutzer. Die Anwendungsfunktionalität hat somit einen direkten Einuss auf die Anzahl an Widgets DOM Adapter Der DOM Adapter schlieÿt die Lücke zwischen Konikterkennung und Datenmodell. Es müssen alle nötigen Funktionalitäten unterstützt werden, um ein konsistentes Datenmodell zu bilden. Das Anwendungsfeld des DOM Adapter ist der DOM von Web Anwendungen. Das Document Object Model ist ein ozieller Standard [25] und deniert Strukturen sowie Methoden um Datenmodelle zu erstellen und zu bearbeiten. Das Konzept des DOM Adapter ist das Verfolgen von Manipulationen am DOM Modell und unter zur Hilfenahme der OT Engine diese zu weiteren Kollaborateuren zu verschicken. Der Adapter nutzt dabei die DOM API, um Notikationen vom DOM Modell während einer Änderung zu empfangen. Somit können Information wie das Hinzufügen oder Entfernen von Knoten am Modell empfangen werden und daraufhin eine Synchronisation mit remote Teilnehmern ausgelöst werden. Dasselbe gilt für Attributänderungen an einzelnen Knoten. Da alle Weboperationen auf Methoden der DOM API aufbauen, kann jede Anwendungsfunktion vom DOM Adapter verfolgt werden. Zwei Funktionen müssen vom DOM Adapter erfüllt werden, um das eben beschriebene Konzept umsetzen zu können: Die Erweiterung des DOM Notikationssystems um das Registrieren von Event Listenern, wodurch Änderungen am Modell verfolgt werden können. DOM Events, betreend dessen Änderung, müssen in eine OT Operation konvertiert werden können. Die konvertierte OT Operation wird von der OT Engine serialisiert und an weitere Teilnehmer versendet. Vor der erneuten Ausführung der OT Operation auf das fremde Modell, werden nebenläuge Operationen von der OT Engine transformiert, um Konikten vorzubeugen. Im Vergleich zu Web Anwendungen ndet der DOM bei mobilen Anwendungen keine Verwendung. Dies erklärt sich aus den unterschiedlichen Einsatzgebieten. Mobile Anwendungen werden nicht für den Internetbereich entwickelt und unterstützen somit auch keinen DOM oder das HTML Markup. Stattdessen werden die Daten unabhängig von deren Darstellung von einem Server angefordert. Für diesen Zweck können spezielle APIs zum Einsatz kommen, wodurch extra Datentypen und Filterkriterien zum Server übertragen werden können. Die verbreitetsten Datentypen sind XML und JSON. Daraus lässt sich erkennen, dass mobile Anwendungen die Modellinformationen einer web Anwendung verwenden, aber unabhängig von deren Struktur oder Technologie sein können. Die eben genannten Unterschiede zwischen dem Modell einer web und mobil Anwendung machen eine Verwendung des DOM Adapter für die mobile Version der GCI unnötig. Wie sich in dem folgenden Abschnitt zeigen wird, gibt es eine weitere Variante der Modelladaption, welche sich den Gegebenheiten und Herausforderungen der mobilen Entwicklung als vorteilhafter erweisen. Fortan wird der DOM Adapter für die mobile Anpassung der GCI als keine eigenständige Komponente betrachtet. Stattdessen besteht die Möglichkeit eine Implementierung des Framework Adapter unter Verwendung des DOM und dessen API zu erstellen. Dadurch kann der DOM Adapter weiterhin im GCI enthalten sein, aber als eine konkrete Ausprägung des Framework Adapter. Diese Adaption des DOM und der damit verbundenen API stellt einen gröÿeren Entwicklungsaufwand dar und sollte den DOM Standard dabei nicht unberücksichtigt lassen. 5.1 Kernkomponenten 31

41 5.1.2 Framework Adapter Ein weiterer Adapter der GCI dessen Funktionalität die Zusammenarbeit von Datenmodell und Koniktbehandlung unterstützt ist der Framework Adapter. Dieser Adapter stellt eine Alternative zum DOM Adapter dar. Der Unterschied liegt in der Wahl eines kollaborativen Frameworks zur Konikterkennung und -behandlung. Neben dem DOM können Web Anwendungen auch eigene Modellstruktur auf Basis von JavaScript Objekten verwenden. Solche Modelle nden sich in den Frameworks Ace Editor 3 oder Eclipse Orion 4. Da JavaScript ebenfalls eine mögliche Programmiersprache für mobile Anwendungen ist, bleibt der Framework Adapter weiterhin eine wichtige Komponente im GCI. Jedoch ist die Umsetzung von mobilen Anwendungen mit JavaScript weniger verbreitet, da eine Implementierung mit der nativen Sprache des Betriebssystems weitere Funktionen ermöglicht. Am Beispiel von Android ist die native Programmiersprache Java. Das Konzept des Framework Adapter liegt in der Adaption eines Anwendungsmodells sowie Methoden um dieses zu manipulieren. Wie bereits im vorherigen Abschnitt erläutert wurde, sind mobile Anwendungen nicht auf die Darstellung durch den DOM angewiesen, sondern auf dessen Modellinhalt. Bei einer Web Anwendung mit einem kollaborativen JavaScript Framework ist der DOM eine Repräsentationsform, während JavaScript Objekte das Datenmodell abbilden. Dieses Konzept lässt sich ebenfalls bei mobilen Anwendungen verwenden mit dem Unterschied, dass JavaScript nicht mehr die einzige Programmiersprache ist. Stattdessen können Sprachen wie Java oder Objective-C verwendet werden. In der Software-Entwicklung nennt sich die Trennung von Darstellung und Inhalt Model-View-Controller (MVC) Entwurfsmuster. Dabei werden Datenmodell und Datenanzeige von einem Controller verknüpft und sind somit unabhängig voneinander. Mit einer Änderung der Daten erfolgt die Aktualisierung der Darstellung und umgekehrt. Das MVC Design Pattern erhöht die Verwendbarkeit der GCI, da Logik und Oberäche einer Anwendung separat gehalten werden und somit ein Komponentenaustausch ermöglicht wird. Bevor das MVC Pattern zum Einsatz kommen kann, müssen drei Bedingungen von der Anwendung erfüllt werden: Eine anwendungsunabhängige API wird zur Umsetzung einer generischen Nebenläugkeitskontrolle benötigt. Dabei wird diese neutrale API zur Modellmanipulation verwendet. Das Datenmodell muss einen Notikationsmechanismus unterstützen können. Unter der Verwendung eines Listeners, welcher vorher am Modell registriert werden kann, können Änderungen am Modell verfolgt und weiter propagiert werden. Änderungen beziehen sich dabei auf die Erweiterung bzw. Reduktion der Modellhierarchie sowie die Werte von Modellattributen. Um das gesamte Datenmodell von einem Zugangspunkt zur erreichen, muss es traversierbar sein. Das bedeutet, von einem Wurzelknoten des Modells, müssen alle Folgeknoten erreichbar sein. Auf diese Weise können Events übertragen oder Inhalte abgefragt werden. Die eben aufgeführten Bedingungen ermöglichen eine Etablierung der GCI in eine bestehende Anwendung. Die nötigen Hilfsmethoden und Objekte müssen dabei vom Framework Adapter unterstützt werden. So gehören die Adaption und Erweiterung des Datenmodells zur Funktion des Framework Adapter. Ebenso die Integration einer OT Engine um Konikte zu erkennen und zu behandeln. In diesem Zusammenhang arbeitet der Framework Adapter analog zum DOM Adapter. Ergebnisse von Anwendungsoperationen werden im Datenmodell materialisiert und dadurch eine Synchronisation mit entfernten Teilnehmern ausgelöst. Für mobile Anwendungen ist der Framework Adapter eine essenzielle Komponente. Im Vergleich zu Web Anwendungen, welche den DOM nativ verwenden und interpretieren können, müssen mobile Anwendungen, welche schnittstellen- und objektorientiert sind, bestehende Strukturen eigenständig anpassen und konvertieren. 3 Ace Editor Website 4 Eclipse Orion Website 32 Kapitel 5 Konzept

42 5.1.3 Workspace Awareness Adapter Neben dem bereits genannten DOM Adapter und Framework Adapter gibt es noch den Workspace Awareness Adapter. Anders als die beiden vorher genannten Adapter, ist dieser Adapter von entscheidender Bedeutung für die Kollaboration mit anderen Teilnehmern einer Sitzung. Über die von diesem Adapter angebotenen Funktionalitäten, können Widgets in die Anwendung integriert werden und geben somit die Sicht auf das Verhalten und die Operationen von anderen Teilnehmern preis. Workspace Awareness steht dabei für die Aufmerksamkeit gegenüber eines Arbeitsplatzes den sich mehrere Personen gemeinsam teilen. Solch ein Arbeitsplatz kann eine Leihnwand oder ein Textdokument sein. Ein Widget soll dann seine Aufmerksamkeit auf das Verhalten aller Teilnehmer richten und somit deren aktuelle Position oder Handlung für die weiteren Nutzer anzeigen. Am Beispiel eines Textdokumentes könnte ein solches Widget die Radar View sein. Mit dessen Hilfe kann die Position von allen Teilnehmern im Textdokument ermittelt und angezeigt werden. Der Workspace Awareness Adapter fungiert dabei als Container für solche kollaborativen Widgets und überwacht deren Lebenszyklus (Initialisierung, Start, Stop, Events). Vier Kernkomponenten werden von diesem Adapter benötigt um die genannten Funktionen umsetzen zu können. Eine Eventkomponente bietet eine einheitliche Schnittstelle zum Eventsystem an. Diese Schnittstelle wird vom DOM oder Framework Adapter angeboten. Diese Komponente muss dabei ein homogenes Set an Awareness Events anbieten. Dieses Set entsteht dabei durch Abstraktion von einer darunter liegenden Eventquelle. Eine Widgetkomponente empfängt und verabeitet die von der Eventkomponente versendeten Awareness Events. Solch eine Widgetkomponente kann die bereits genannte Radar View oder Teilnehmerliste sein. Ein Widget registriert sich bei der Eventkomponente für die Awareness Events, die es auch verabeiten kann. Eine Netzwerkkomponente ist für die Verteilung von Awareness Events an weitere Sitzungsteilnehmer verantwortlich. Damit diese Komponente wiederverwendbar bleibt, sollte diese unabhängig von Netzwerktechnologien sein und eine abstrahierte Menge von Methoden anbieten (initsession, verteileevent). Eine Teilnehmerkomponente ergänzt die Anzeige- und Modelländerungen mit den Teilnehmerhandlungen. Jegliche Nutzeraktionen, egal ob lokale oder entfernte, werden von dieser Komponente überwacht und verarbeitet. Die eben genannten vier Komponenten sollen vom Workspace Awareness Adapter verbunden und über ein abstraktes Interface verwendet werden. 5.2 KOMMUNIKATIONSADAPTER Der Kommunikationsadapter wurde bereits in Abschnitt 5.1 angesprochen und als neue Komponente im GCI indentiziert. Diese Komponente soll ein einheitliches Interface für Kommunikationszwecke anbieten. Dadurch ist es möglich die Kommunikationstechnologie auszutauschen und nicht nur auf ein Internetprotokoll, sondern auch auf andere Protokollarten zurück zugreifen. Mobile Endgeräte unterstützen heute verschiedene Netzwerktechnologien (zellular, WLAN, Bluetooth). Eine exible Anbindung an verschiedene Einsatzszenarien kann somit realisiert werden. Der Entwickler muss lediglich das gewünschte Kommunikationsprotokoll im Kommunikationsadapter implementieren. Für kollaborative Anwendungen hat sich jedoch das WebSocket Protokoll mit seiner asynchronen Nachrichtenübertragung als eektives Protokoll erwiesen. Andere Transportprotokolle mit Mobilitätsunterstützung, z.b. MR-UDP 5, teilweise auch XMPP 6, seien in diesem Zusammenhang genannt, werden aber nicht weiter vertieft. Für weitere Details über WebSockets sei auf Abschnitt 2.2 verwiesen. Die folgenden Eigenschaften sollen mit dem Kommunikationsadapter erreicht werden. 5 MR-UDP Website 6 XMPP Website 5.2 Kommunikationsadapter 33

43 Es wird ein einheitliches Interface für die Kommunikation mit einem entfernten Teilnehmer speziziert und angeboten. Dadurch bleibt die klare Aufgabentrennung zwischen den einzelnen Komponenten der GCI erhalten. Das Austauschen der gesamten Komponente ist somit weiterhin möglich. Die Technologie welche die Kommunikation ermöglicht, soll schnell anpassbar sein ohne das Interface zu verändern. Dies stützt den Gedanken eines erweiterbaren und generischen Frameworks. Die Context-Awareness in Bezug auf die Kommunikation soll ebenfalls von diesem Adapter berücksichtig werden. Das bedeutet bei Änderungen der Verbindungsqualität oder Unterbrechung der Internetverbindung sollen dem entsprechende Maÿnahmen ergrien werden. Die Context-Awareness der gesamten Anwendung wurde bisher noch nicht weiter vertieft. Der Workspace Awareness Adapter aus Abschnitt Adapter übernimmt lediglich kontextsensitive Aufgaben im Zusammenhang mit einer Kollaboration und der daran teilnehmenden Nutzer. Die kontextabhängigen Informationen der gesamten Anwendung stellen aber ebenfalls eine Herausforderung an mobile Anwendungen dar. So zum Beispiel die Aufmerksamkeit gegenüber einer bestehenden Internetverbindung. Um das Verhalten der Anwendung so dynamische wie möglich zu gestalten, wird der Mobile Strategy Adapter, als weitere neue Komponente im GCI vorgestellt. Dieser soll Strategien für spezielle kontextabhängige Aufgaben bereit halten. Für weitere Informationen sei auf Abschnitt 5.3 verwiesen. Die Context-Awareness gegenüber der Kommunikation, am Beispiel einer Internetverbindung, ist Teil des Kommunikationsadapter. Um dies zu realisieren, erfolgt ein Monitoring der aktuellen Netzwerkverbindung um über Änderungen informiert zu werden. Bei groÿen Schwankungen der Datenrate, Verbindungsunterbrechung oder Wechsel der IP-Adresse sollen entsprechende Funktionen eine Ausnahmebehandlung durchführen und den laufenden Betrieb der Anwendung nicht unterbechen bzw. nur gering einschränken. Der Ansatzpunkt im GCI für den Kommunikationsadapter ist direkt in der anwendungsunabhängigen API Schicht. Diese enthält die kollaborativen Komponenten, welche für die Modellkonsistenz sowie Awareness Widgets verantwortlich sind. Beide genannten Komponenten verarbeiten lokale sowie entfernte Nutzereingaben und sind damit in den Kommunikationsprozess integriert. Der Kommunikationsadapter verbindet den Workspace Awareness Adapter, sowie die Konikerkennungs- und Konikbehebungskomponente, mit den entfernten Sitzungsteilnehmern. Alle Nachrichten werden von diesem Adapter versendet bzw. empfangene Nachrichten an andere Komponenten weitergeleitet. Die Schnittstelle erfordert somit keine sonderlich breit Spezikation. Es werden Methoden wie connect(), disconnect() und send() sowie Rückrufmethoden wie onreceive() zur Verfügung gestellt. Weitere komplexe Methoden lassen sich auf diese vier reduzieren. 5.3 MOBILE STRATEGY ADAPTER Der Mobile Strategy Adapter gehört, wie auch der Kommunikationsadapter, nicht zur beschriebenen GCI aus [24]. Dieser Adapter soll für die speziellen Herausforderungen, welche an mobile Anwendungen gestellt werden, eine Ergänzung darstellen. Auf die Herausforderungen wurden bereits im Abschnitt 1.1 eingegangen. Die Funktionen dieses Adapter liegen in der Device-Awareness. Das bedeutet, Änderungen, welche Einuss auf den Anwendungskontext haben, werden von diesem Adapter überwacht und an registrierte Komponenten der betreenden Anwendung weitergeleitet. Dadurch kann die Anwendung auf wichtige Veränderungen, wie den Verlust der Internetverbindung, niedrigen Akkuzustand oder variierende Displaygröÿen, besser eingehen. Zwei Eigenschaften werden von diesem Adapter zur Verbesserung der Anwendung realisiert. Die Performance von mobilen Anwendungen ist von zentraler Bedeutung. Mehr noch als bei Web Anwendungen, unterstehen mobile Anwendungen ständigen Schwankungen ihrer Verbindungsqualität zum Internet. Dies ist der unterschiedlichen Netzabdeckung und der Bewegungsgeschwindigkeit des Nutzers geschuldet. Umso wichtiger ist eine dynamische Anpassung der Datenmenge um ezient auf die Eingaben des Nutzers reagieren zu können. Bei einer geringen Bandbreite, wie zum Beispiel im GSM 7 Netz, erfordert es eine lange 7 Global System for Mobile Communications 34 Kapitel 5 Konzept

44 Wartezeit vom Nutzer, bis die selbe Menge an Daten im Vergleich zum WLAN Netz empfangen wurde. Solche Netzschwankungen sollte der Mobile Strategy Adapter berücksichtigen und die Datenmenge reduzieren um die Wartezeit des Nutzers zu verringern. Somit bleiben Oberächen responsiv und aktuell. Um die geringere Datenmenge pro Request zu kompensieren, werden mehr Requests versendet. Da in dieser Arbeit aber von Echtzeitkommunikation gesprochen wird, ist die Anzahl von Requests im Vergleich zu langen Wartezeit nicht relevant. Die angestrebte Konsistenz des Datenmodells kann bei einer geringen Datenrate bzw. bei einer Verbindungsunterbrechung nicht mehr gewährleistet werden. Umso gröÿer ist der Verlust, wenn Operationen von einem Sitzungsteilnehmer nicht mehr nachvollzogen werden können und das bearbeitete Objekt damit inkonsistent wird. Deshalb soll dieser Adapter eine Strategie, für solch einen eben genannten Fall, bereitstellen. Eine einfache Lösung wäre die Speicherung von nicht versandten Operationen, beispielsweise in einer Datenbank. Am Beispiel von Apache Wave werden JSON Nachrichten zwischen Client und Server ausgetauscht. JSON ist ein kompakter Texttyp und kann ohne weitere Bearbeitung in einer Datenbank gespeichert werden. Bei einer erneuten Verbindung mit dem Internet, werden die gespeicherten Operationen an den zentralen Server versendet um eine Synchronisation des Modells zu erreichen. Die Verwendung einer Datenbank wäre nur ein Beispiel um Operationen zu speichern. Der zentrale Apache Wave Server erstellt mehrere Textdateien worin Daten persistent gespeichert werden. Da der Mobile Strategy Adapter unterschiedliche Strategien für mehrere Komponenten der GCI bereitstellt, muss dieser weitläuger in die bestehende GCI integriert werden. Zum einen nimmt der Adapter Einuss auf die zu versendenden Request um die Datenrate dynamisch zu variieren, zum anderen speichert dieser Operationen, wenn keine Internetverbindung vorhanden ist. Um die Erweiterbarkeit dieses Adapter nicht zu blockieren, bietet sich die Integration direkt neben dem WAA und CTE an. Die CTE konrolliert die Modellsynchronisation und sendet lokale Operationen zu entfernten Teilnehmern. Der WAA hat keinen direkten Einuss auf die genannten Ziele dieses Adapter, jedoch hat der WAA das Potential für ein dynamisch anpassbares Verhalten, da Anzeigekomponenten und Funktionalität in diesem vereint werden. Das Problem an dieser Stelle ist, dass der Mobile Strategy Adapter nicht über die gesamte Anwendung hinweg verteilt werden kann, da sonst die Vorteile der GCI Architektur de-komponiert werden würden. Somit kann nur auf der anwendungsunabhängigen API Schicht agieren werden. Eine dynamische Erweiterung der Oberäche durch die Kontextänderung der Displaygröÿe würde aber Eingri in höher liegende Schichten nehmen und kann deshalb nicht in Betracht gezogen werden. Eine alternative Möglichkeit, wäre über den Workspace Awareness Adapter eine dynamisch Erweiterung durch Awareness Widgets in Betracht zu ziehen. Dabei deniert der Entwickler verschiedene Variationspunkte im Layout und der Mobile Strategy Adapter füllt diese mit passenden Widget mit der Abhängigkeit zur aktuellen Displaygröÿe. Dadurch wird die Unterstützung für Tabletgeräte weiter begünstigt. 5.4 INTEGRATION EINER ANWENDUNGSUNABHÄNGIGEN API In diesem Abschnitt wird die bereits genannte anwendungsunabhängige API näher beschrieben und deren Zusammenhang zu den vorgestellten Adaptern der GCI erläutert. Das Konzept einer Anwendungsschicht, welche eine Nebenläugkeitskontrolle mit der Funktionalität einer Anwendung auf unabhängige Art und Weise miteinander verbindet, stammt aus [24]. Diese API bietet im Vergleich zur Anwendung eine Auswahl an Low-Level-Methoden an. Dies hat zur Folge, dass alle Funktionen bzw. Operationen auf höheren Anwendungsebenen zu Methoden dieser API de-komponiert werden können oder anders ausgedrückt, mehrere Low-Level-Methoden werden zu anwendungsspezischen Operationen zusammengefügt. Des Weiteren werden nicht nur Methoden, sondern auch Modellinformationen von dieser API bereitgestellt. Zugleich können Methoden das Modell auf der atomaren Ebene direkt manipulieren. Neben den eben genannten grundlegenden Funktionen dieser API müssen drei Dienste angeboten werden um die Möglichkeit einer GCI zu gewährleisten. Die OT Engine ermöglicht die Transformation von mehreren OT Operationen. Damit einhergehen Änderungen der Reihenfolge sowie Verluste von Operationen. Um dennoch den Zustandsgraphen der OT nachvollziehen zu können, müssen Operationen aufgezeichnet werden können und bei bedarf wiederholbar sein. Diese Funktion wird von der anwendungsunabhängigen API unterstützt und bei der Koniktbehandlung verwendet. 5.4 Integration einer anwendungsunabhängigen API 35

45 Abbildung 5.2: Erweiterte Darstellung der Generic Collaborative Infrastructure bei mobilen Anwendungen Das Verfolgen von Änderungen am Modell dient zum einen der Modellsynchronisation unter Verwendung der OT Engine und zum anderen der Aktualisierung von Workspace Awareness Widgets durch Notikationen. Das sogenannte Tracking von Operationen bzw. Änderungen am Modell wird ebenfalls von dieser API unterstützt. Die bereits genannten Workspace Widgets sollen ebenfalls dem generischen und dynamischen Konzept der GCI folgen. Somit liegt die Integration sowie Reduktion von Widgets bei der unabhängigen API, da, wie auch bei der Kollaboration diese Funktion von der übrigen Anwendung unabhängig sein soll. Das Management von Widgets ist somit ein weiterer Dienst dieser API. In [24] wurden ebenfalls zwei weitläug verbreitete Ansätze für die Umsetzung dieser anwendungsunabhängigen API vorgestellt. Der erste Ansatz folgt einem DOM basierten Datenmodell, welches sich in dem bereits vorgestelltem DOM Adapter widerspiegelt. Der zweite Ansatz nutzt ein JavaScript basiertes Modell und wurde ebenfalls in der Form des Framework Adapter präsentiert. Beide Adapter nehmen eine zentrale Rolle in der unabhängigen API ein. Ergänzend dazu kommen der Workspace Awareness Adapter und die OT Engine zum Einsatz. Der neue Kommunikationsadapter und Mobile Strategy Adapter fügen sich ebenfalls in die unabhängige API mit ein und werden von deren Komponenten verwendet. 5.5 ZUSAMMENFASSUNG In diesem Kapitel wurde das Konzept der GCI aus [24] erklärt und mit den Anforderungen von mobilen Anwendungen verglichen. Dabei wurden bestehende Komponenten entfernt sowie neue ergänzt. In Abbildung 5.2 sind die Erweiterungen der GCI mit Blick auf mobile Anwendungen noch einmal dargestellt. Die Unterteilung einer Anwendung in unterschiedliche Schichten mit verschiedenen Zuständigkeiten erhöht die Lesbarkeit sowie das Zusammenspiel der einzelnen Anwendungsteile. Am Beispiel eines Texteditors konnten die Editor UI, die Editor API, die applicationagnostic API und ein Data Model identiziert werden. Eine Alternative Beschreibung der unterteilten Schichten wäre: Oberäche, Funktionalität der Oberäche, Anwendungserweiterungen und Anwendungsdaten. Die Wiederverwendung sowie Variabilität sind ebenfalls ein Vorteil dieser Unterteilung. Der DOM-Adapter dient zur Anpassung des DOM von Web Anwendungen und soll die Lücke zwischen Datenmodell und Koniktbehandlung, in einer kollaborativen Anwendung, schlieÿen. 36 Kapitel 5 Konzept

46 Wie bereits genannt, soll das Ziel des DOM Adapter die Adaption des DOM sein. Da mobile Anwendungen die speziellen Datentypen von WebServices oder Frameworks verwenden und, anders als bei Web Anwendungen, den DOM selber nicht direkt interpretieren können, wurde der DOM-Adapter im Bereich mobiler Anwendungen aus der GCI entfernt. Alternativ zum DOM-Adapter wurde der Framework Adapter für nonkonforme Datenmodelle beschrieben. Dieser soll, ebenso wie der DOM-Adapter, Modellstrukturen an die Verwendung von kollaborativen Anwendungen anpassen. Dabei wurden die Funktionen der Notikation, Traversion und Beziehung zwischen GCI und bestehender Anwendung identiziert. Eine Umsetzung des Framework Adapter mittels des Model-View-Controller Pattern, ermöglicht die strukturierte Trennung zwischen Oberäche, Datenmodell und Kontrollkomponente. Die Modelle, welche vom Framework Adapter verarbeitet werden, können von JavaScript oder JSON repräsentiert werden. Der Framework Adapter soll gezielt bestehende Modellstrukuren aus anderen Frameworks und Bibliotheken anpassen und somit in die GCI integrierbar gestalten. Dieser Adapter wird über die anwendungsunabhängige API in eine bestehende mobile Single-User Anwendung hinzugefügt und ermöglicht die Verwendung der kollaborativen Multi-User Komponenten der GCI. Um die Konikte zwischen Anwendungsoperationen zu erkennen und zu beheben, müssen Operationen für die Anwendung wiederholbar sein. Aus diesem Grund werden alle Operationen auf das Datenmodell von einem Change Recoder (CR) verfolgt und gespeichert. Dadurch können Operationen in ihrer Ausführung neu koordiniert und das Datenmodell konsistent gehalten werden. Neben der Anpassung der eigentlichen Modellstruktur müssen auch die Auswirkungen der Operationen auf das Modell neu beschrieben werden. Mittels eines Operation Mapper (OM) wird eine Abbildung zwischen den ursprünglichen Framework Operationen und den anwendungsspezischen Operationen gebildet. Für die Änderungen am Modell ist der Model Manipulator (MM) verantwortlich. Dieser kann Strukturen und Attribute der neuen Modellstruktur bearbeiten. Veranlasst wird dies durch die Anwendungsoperationen. Mit dem bereits bekannten Workspace Awareness Adapter (WAA) können kontextsensitive Widgets in eine bestehende Anwendung integriert werden. Deren Aufgabe ist das Verfolgen und Darstellen von Handlungen und Operationen der entfernten Sitzungsteilnehmer. Mithilfe einer Teilnehmerliste oder Radar View, können die aktuellen Teilnehmer einer Kollaboration erfasst und deren aktuelle Position im Arbeitsbereich identiziert werden. Es werden vier Komponenten zu Umsetzung dieser Funktionalität mit einbezogen. Eine Eventkomponente ermöglicht das Empfangen von Awareness Events, die von Anwendungsoperationen abstrahiert werden und Änderungen in Anwendung anzeigen. Eine Widgetkomponente ist dann in der Lage, die Awareness Events zu verarbeiten. Dafür registriert es sich vorher für die entsprechenden Events an der Eventkomponente. Ein weiterer Teil ist eine Netzwerkkomponente, welche die lokalen Awareness Events an entfernte Teilnehmer versendet oder selber welche empfängt. Auf diese Weise werden nicht nur die lokalen Widgets, sondern auch die entfernten synchron gehalten. Als vierter und letzter Bestandteil sei die Teilnehmerkomponente genannt. Diese verbindet die lokalen und entfernten Awareness Operationen mit der bestehenden Anwendungsoberäche und dessen Datenmodell. Der bereits genannt CR, dient zum koordinieren von Operationen um Konikte beheben zu können. Die Koniktbehebung wurde ebenfalls in einer separaten Komponente gekapselt. Die Operational Transformation Engine (OTE) löst Konikte zwischen Operationen, mittels eines speziellen Algorithmus auf. Dieser kann ebenfalls von einem anderen Framework in die GCI integriert oder eigenständig implementiert werden. Als Beispiel sei der Operational Transformation Algorithmus, welche bereits in vielen Anwendungen und Frameworks zum Einsatz kommt und mittlerweile ein De-facto-Standard ist, genannt. Die bereits mehrfach erwähnte Anpassung des Datenmodells wird in dem Operational Transformation Model (OTM) umgesetzt und kann direkt von der OTE oder dem Framework Adapter verwendet werden. Um die neuen Herausforderungen der mobilen Anwendungen im Vergleich zu Web Anwendungen besser bestehen zu können, wurde der Kommunikationsadapter als neue Komponente im GCI benannt. Dieser Adapter soll die zur Kollaboration verwendete Kommunikationstechnologie kapseln und mittels eines einheitlichen Interface variabel gestalten. Auf diese Weise kann von einer Netzwerkkommunikation zu einer Bluetooth Übertragung, ohne einen groÿen Eingri in die GCI vorzunehmen, gewechselt werden. Zusätzlich kann der Kommunikationsadapter mittels eines Netzwerk Monitor die Verbindungsschwankungen bzw. eine Verbindungsunterbrechung wahrnehmen und entsprechende Ausnahmebehandlungen ausführen. Durch die beiden Anwendungsmodi (Single-User, Multi-User) verändert sich die Funktionalität der gesamten Anwendung. Durch Mobilität und Geräteunabhängigkeit können ebenfalls Funktionalitäten eingeschränkt oder erweitert werden. Um diese Funktionalität bereitzustellen 5.5 Zusammenfassung 37

47 und neues Verhalten in bestimmten Situationen besser zu unterstützen, wurde der Mobile Strategy Adapter als neue Komponente im GCI identiziert. Wie der Kommunikationsadapter, in Hinblick auf die Kontextsensitivität bei einer Internetverbindung, soll dieser Adapter dynamisch das Verhalten der Anwendung bei Kontextänderungen anpassen. Sei es die Änderung der Displaygröÿe durch das drehen des Smartphones oder die Speicherung von Anwendungsoperationen während einer getrennten Internetverbindung. Für kontextabhängige Funktionalitäten stellt der Mobile Strategy Adapter eine passende Strategie bereit. 38 Kapitel 5 Konzept

48 6 IMPLEMENTIERUNG Im nun folgenden Kapitel wird die Umsetzung des aus Kapitel 5 erläuterten Konzeptes beschrieben und mit den Anforderungen aus Kapitel 3 verglichen. Damit die beschriebenen Implementierungen nicht zu abstrakt ausfallen, wird am Beispiel des Apache Wave Frameworks ein mobiler Client für kollaborative Nachrichtenfunktionen umgesetzt. Mit dieser Anwendung können sich mehrere Nutzer in einer Konversation Nachrichten schreiben sowie auf diese Antworten. Als Besonderheit sei die Aktualisierung der Oberäche in Echtzeit sowie das gemeinsame Bearbeiten einer Nachricht genannt. Dazu wird der OT Algorithmus von Apache Wave zur Koniktkontrolle verwendet und deren Wave Datenmodell adaptiert. Apache Wave wurde als Web Anwendung konzipiert und läuft somit in jedem Internet Browser. In der mobilen Variante soll es auf einer breiten Plattform in nativer Sprache programmiert werden. Für die Umsetzung von Apache Wave, wird das Google Web Toolkit (GWT) verwendet, womit Java Code in JavaScript Code sowie HTML Dokumente transformiert wird. Als mobile Anwendungsplattform wird das von der Firma Google entwickelte Android OS verwendet. Für die Implementierung der Anwendung wird die Sprache Java zum Einsatz kommen. Da Apache Wave als OpenSource Projekt frei verfügbar ist, werden bestimmte Komponenten und Algorithmen wiederverwendet. So zum Beispiel die OT-Engine zur Koniktausösung [26]. In den folgenden Abschnitten wird genauer auf den Framework Adapter, Workspace Awareness Adapter, Kommunikationsadapter, Mobile Strategy Adapter und die OT Komponenten eingegangen. Desweiteren wird die Architektur der Anwendung beschrieben und deren Schnittstelle zum GCI mit den eben genannten Bestandteilen. In der Abbildung 6.1 wird eine UML Übersicht der Android, Generic Collaboration Infrastructure und Apache Wave Komponenten gezeigt. 6.1 KOMMUNIKATIONSADAPTER Der Kommunikationsadapter dient als Schnittstelle zum zentralen Server eines kollaborativen Frameworks. Die zur Kommunikation eingesetzte Technologie soll dabei variable und frei veränderbar sein. Am Beispiel von Apache Wave wird eine Internetverbindung basierend auf dem WebSocket Protokoll durch den Kommunikationsadapter etabliert. Wie bereits genannt, sind die Möglichkeit der Kommunikation nicht nur auf eine Netzwerkkommunikation beschränkt. Somit könnte dieser Adapter auch eine Bluetoothverbindung unterstützten. Eben diese generische Anpassung der Kommunikation, ohne Einuss auf die gesamte Anwendung zu nehmen, ist der Vorteil dieser Komponente. Rückblickend auf Kapitel 3 sei die technische Anforderung REQ-TECH-1.2 (Adapter zur generischen Kommunikation) genannt. Eben dieses Muss-Kriterium kann mittels dieses Adapters ohne gröÿeren Aufwand realisiert werden. Um nun direkten Bezug zur Beispielanwendung dieser Arbeit zu nehmen, sei auf Abbildung 6.2 verwiesen, um eine mögliche Implementierung des Kommunikationsadapters aufzuzeigen. Um einen dynamischen Austausch von Komponenten zur Laufzeit zu ermöglichen, sollten sich die einzelnen Bestandteile der GCI auf Interfaces stützen. Damit sind die wesentlichen Methoden deniert und geben dennoch Spielraum für Erweiterungen. Das zentrale Interface ist der CommunicationAdapter welche vom DefaultCommunicationAdapter implementiert wird. Dieser 39

49 Abbildung 6.1: Übersicht der implementierten Generic Collaboration Infrastructure auf Android mit Apache Wave. Abbildung 6.2: UML Diagramm des Kommunikationsadapter als Bestandteil der GCI mit Umsetzung auf der Android Platform. 40 Kapitel 6 Implementierung

50 stellt Methoden wie connect(), disconnected(), isconnected(), send(string) sowie send(byte[]) zur Verfügung. Dies sollen die grundlegenden Methoden eines Kommunikationsadapters darstellen. Der DefaultCommunicationAdapter besitzt einen CommunicationConnector, welcher vom CommunicationAdapter erbt und somit über dasselbe Interface verfügt. Der DefaultCommunicationAdapter leitet alle Anfragen die über das CommunicationAdapter Interface gestellt werden direkt an das CommunicationConnector Interface weiter. Zusätzliche Abfragen oder Algorithmen können direkt im DefaultCommunicationAdapter implementiert werden, aber dazu später mehr. Der CommunicationConnector dient als Schnittstelle zum Kommunikationsprotokoll. So ist die Beispielimplementierung der WebSocketConnector, welcher die Kommunikation auf Basis des WebSocket Protokolls unterstützt. Der DefaultCommunicationAdapter, sowie der WebSocketConnector können bereits im mobile Framework des GCI enthalten sein. Der WebSocketConnector setzt sich aus zwei weiteren Objekten zusammen: dem WebSocketAidlService und dem WebSocketConnector.Callback Interface. Beide Objekte werden von speziellen Androidklassen repräsentiert bzw. implementiert. Der WebSocketAidlService ist ein Android Service welcher mittels AIDL (Android Interface Denition Language) angesprochen wird. Der Vorteil dieses Service ist der zusätzliche Anwendungsprozess. Eine Androidanwendung läuft in einem separaten Prozess mit einem User Interface (UI) Thread. Lang anhaltende Operationen wie Webanfragen können die UI der Anwendung blockieren und deren Benutzbarkeit verringern, wenn diese im UI Thread ausgeführt werden. Aus diesem Grund wird der Service verwendet, welcher die Last vom UI Thread nimmt und zusätzlich eine WebSocket Verbindung dauerhaft aufrechterhält. Die Entscheidung einen Service mittels AIDL zu verwenden entstand aus dem Bedarf eines zusätzlichen Prozess und des damit verbundenen gröÿeren Speichers. Weiterhin ermöglicht es anderen Anwendungen den selben Service zu nutzen, wodurch weitere Möglichkeiten für zukünftige Arbeiten erönet werden. Eine alternative Implementierung wäre an dieser Stelle ebenfalls möglich und könnte eine Performance-Steigerung bringen. Das Callback Interface wird von der Android Activity implementiert, welche fortan die WebSocket Ergebnisse empfängt. Die Synchronisation der Prozesse übernimmt bereits der WebSocketAidlService. Die Activity spielt dabei die Rolle der anwendungsunabhängigen API, welche alle GCI Komponenten miteinander verbindet und zudem eine essenzielle Komponente im Android OS darstellt. Alle UI Elemente können von sogenannten Android Fragments gekapselt werden und dynamisch zur Laufzeit angepasst werden. Dem Konzept zufolge besitzt der CommunicationAdapter einen Network Monitor. Dieser gibt Auskunft über den aktuellen Zustand einer Verbindung. Aufgrund der dynamischen Wahl der Kommunikationstechnik wird der Network Monitor nicht in einer Klasse oder einem Interface deniert. Am Beispiel einer Internetverbindung erbt die Klasse NetworkMonitor von der Androidklasse BroadcastReceiver. Über einen speziellen Filter wird der NetworkMonitor über alle Änderungen bezüglich der Internetverbindung informiert und kann diese Information dem CommunicationAdapter bereitstellen. In der Beispielanwendung integriert sich der NetworkMonitor in den DefaultCommunicationAdapter, welcher somit Netzwerkkommunikation und Netzwerkzustand kapselt. Mit den genannten Klassen und Interfaces ist es möglich, einen Kommunikationsadapter von Grund auf selber zu implementieren oder auf bereits vorhandene Standardkomponenten, wie dem WebSocketConnector, zurück zu greifen. Eine Kombination aus Standardkomponenten und eigenständig implementierten Komponenten ist ebenfalls möglich. Somit lassen sich best-practises wiederverwenden und die Stabilität der Anwendung verbessern. Die Anforderungen REQ-TECH-1.3 (Kommunikation mit WebSockets und Wave Protokollen), welches ein Muss-Kriterium für die Beispielanwendung ist, kann somit schnell und sauber realisiert werden. Auch REQ-TECH-1 (Integration in Android) und REQ-TECH-1.4 (Anbindung an Android mittels Adapter) haben sich durch den eben beschriebenen Kommunikationsadapter gezeigt. Die Integration ist ohne weitere Schwierigkeiten möglich, ebenso die Adaption von Android- und GCI Komponenten. In puncto Qualität seien REQ-QUAL-4 (Ezienz), REQ-QUAL-4.1 (Echtzeitkommunikation bei Kollaboration), REQ-QUAL-4.2 (Max. zwei Sekunden für entfernte Änderungen) und REQ-QUAL-4.3 (Max. 200 ms für lokales Feedback) genannt. Die genannten Anforderungen spiegeln die Ezienz einer Anwendung wieder. REQ-QUAL-4 wird durch die Verwendung von Prozessen und Thread, sowie Wiederverwendung von Komponenten gestützt. Bei REQ-QUAL-4.1 sei das WebSocket Protokoll genannt. Über die numerischen Anforderungen REQ-QUAL-4.2 und REQ-QUAL-4.3 kann in dieser Arbeit noch kein Bezug genommen werden. Mit zunehmender Komplexität des Datenmodells erhöht sich die Dauer der Koniktkontrollalgorithmen. Die Art der Programmierung trägt ihren Teil zum Ezienzgewinn oder Verlust bei. Eine genauere Analyse dieser Anforderungen sei somit auf spätere Arbeiten verschoben. Die funktionale Anforderung REQ-FUNC-2 (automatische Aktualisierung der Oberäche) wird mittels des WebSocket Protokolls ermöglicht. Durch die asynchrone Kommunikation sind keine Requests, Timer oder Pull-Mechanismen von Nöten um eine Aktualisierung der Oberäche und deren Inhalte auszulösen. 6.1 Kommunikationsadapter 41

51 Abbildung 6.3: UML Diagramm des Mobile Strategy Adapter und dessen Beispielimplementierung. 6.2 MOBILE STRATEGY ADAPTER Der Mobile Strategy Adapter ist, wie auch der Kommunikationsadapter, eine neue Komponente in der mobilen Version der GCI. Dieser soll die Awareness einer bestehenden mobilen Anwendung nicht nur auf die Kollaboration richten, sondern auf die des mobilen Gerätes an sich. Anders ausgedrückt soll der Kontext des Smartphones oder Tablets in das Verhalten der Anwendung mit einieÿen. Ein bereits oft genanntes Beispiel ist die Überprüfung einer etablierten Verbindung zu einem Netzwerk oder anderen Geräten. Gerade mobile Anwendungen, welche das Ziel einer Kollaboration zwischen mehreren Personen an unterschiedlichen Orten verfolgen, verwenden dazu eine Internetverbindung. Gerade mobile Applikationen verstehen sich auf das Zusammenspiel von online und oine Inhalten. Diese Funktion macht die meisten Anwendungen so erfolgreich und deshalb ist dieser Adapter eine neue Notwendigkeit in der GCI. Wie der Name bereits verrät, handelt es sich um Strategien für mobile Endgeräte und deren daraus folgende Anpassung. Wie bereits beim Kommunikationsadapter ndet sich auf Abbildung 6.3 ein UML 1 Diagramm über eine mögliche Implementierung des Mobile Strategy Adapters wieder. Um das Beispiel der Prüfung einer bestehenden Internetverbindung etwas praktischer zu gestalten und das Zusammenspiel der in dieser Arbeit neu eingeführten GCI Komponenten noch besser zu verdeutlichen, wird der CommunicationAdapter, genauer gesagt, der DefaultCommunicationAdapter, mit einer Mobile Strategy erweitert. Wie bereits beim Kommunikationsadapter genannt, stützt sich auch dieser Adapter auf Interfaces um eine klare Klassenkommunikation zu gewährleisten und dennoch in deren Funktionalität zu variieren. Das MobileContextAwareness Interface ist simpel gehalten. Mehr als einer getmobilecontext(), setmobilecontext(mobilecontextawareness) und hasmobilecontext() Methode sind nicht vorhanden. Es soll dem späteren Entwickler lediglich die Existenz einer bereits vorhandenen mobilen Strategie verraten und diese bei Bedarf in seine neue Implementierung mit einbeziehen lassen. Dadurch kann der DefaultCommunicationAdapter, welches das MobileContextAwareness Interface implementiert erweitert werden und dennoch auf dessen Strategien zurück gegrien werden. Die mobile Awareness soll dabei kein Zwang für einen Entwickler darstellen, sondern eine Erweiterung. Der Name gibt bereits Auskunft über das Strategy Entwurfsmuster der Gang of Four (GOF) Gruppe, welches bei diesem Adapter verwendet wird. Dieses Design Pattern kapselt Algorithmen in einem Objekt und macht dieses zur Laufzeit und in Abhängigkeit vom Kontext austauschbar. Die Bestandteile der Strategy sind dabei der MobileContext, welcher eine MobileStrategy hält und Aufrufe an diese weiter delegiert. Die MobileStrategy ist ein Interface und wird beispielsweise von der OineStrategy und OnlineStrategy implementiert. Der CommunicationContext erbt vom MobileContext und verwendet die beiden eben konkretisierten Strategien. Wie bereits genannt, implementiert der aus Abschnitt 6.1 denierte DefaultCommunicationAdapter das MobileContextAwareness Interface. Die konkrete Implementierung des MobileContext ist der CommunicationContext. Dieses verwendet in der Beispielanwendung den NetworkMonitor des DefaultCommunicationAdapter um zwischen der OnlineStrategy und der OineStrategy zu wechseln. Der DefaultCommunicationAdapter verwendet nun nicht mehr direkt den CommunicationConnector, sondern verwendet den CommunicationContext und dessen aktuelle Strategie, welche dem Kontext der verfügbaren Internetverbindung angepasst ist. In der OnlineStrategy wird wie vorher der CommunicationConnector und dessen implementiertes Übertragungsprotokoll verwendet. Bei 1 Unied Modeling Language 42 Kapitel 6 Implementierung

52 einem Verbindungsabbruch oder Verlust sendet das Android System einen Broadcast mit dieser Information an alle BroadcastReceiver. Der NetworkMonitor, welcher solch ein BroadcastReceiver ist, empfängt diesen Broadcast und notiziert alle Interessenten. Dabei wird ein weiteres Entwurfsmuster integriert: das Observer Pattern. Der NetworkMonitor übernimmt dabei die Rolle eines Observers, welcher bestimmte Änderungen im System verfolgt. An diesem können Subjekte registriert werden. Bei Änderungen im System informiert der Observer alle registrierten Subjekte. Ein Subjekt ist beispielsweise der CommunicationContext. Bei einem Verlust der Internetverbindung wird der CommunicationContext nun vom NetworkMonitor notiziert und wechselt die OnlineStrategy mit der OineStrategy aus. In dieser OineStrategy werden alle lokal erzeugten Operationen in einer Datenbank gespeichert. Bei einer erneuten Verbindung mit dem Internet werden remote Operationen vom Server an den Client gesendet. Diese werden mit den gespeicherten lokalen Operationen in der OT-Engine von Konikten befreit. Zum Schluss sendet die Anwendung alle lokalen und nicht in Konikt stehenden Operationen an den zentralen Server. Die noch nicht angesprochenen StrategyArgumente sollen das Problem eines generischen Interfaces überwinden. Die OineStrategy sowie OnlineStrategy benötigen eine Operation als Eingabeargument. Es wäre aber nicht sehr exibel, ein statisches Argument in das MobileStrategy Interface zu denieren. Aus diesem Grund wurde das StrategyArgument Interface deniert. Es stellt ein typisiertes Argument dar und kann in variabler Anzahl an eine konkrete Strategy übergeben werden. Listen, Integer, Objekte etc. sind dabei kein Hindernis. Als Beispiel wurden das StringStrategyArgument und ByteArrayStrategyArgument implementiert um die Methoden send(string) und send(byte[]) des CommunicationAdapter zu unterstützen. Mit dem eben beschriebenen Szenario wurde ein Single-User und Multi-User Mode für eine kollaborative Anwendung umgesetzt. Zusätzlich kann die Anwendung nicht nur online, sondern auch oine verwendet werden. Dies sollen lediglich Beispiele illustrieren und eine herangehensweise der mobilen GCI Variante verdeutlichen. Viele Anforderungen an mobile Anwendungen können mit dem Mobile Strategy Adapter umgesetzt werden. Die funktionale Anforderung REQ-FUNC-2.4 (Unterstützung von Single-User und Multi-User Modes) wurde bereits genannt. REQ-FUNC-2.5 (Oine Speicherung von Operationen) und REQ-TECH-2.5 (Speicherung von Änderungen ohne Internetverbindung) konnten mittels der OineStrategy realisiert werden und kann ohne Aufwand ausgetauscht werden. Auf REQ-FUNC-2.3 (Dynamische Datenrate) sowie REQ-TECH-1.5 (Verwendung einer schwankenden Internetverbindung) wurden bisher nicht weiter eingegangen, kann aber ebenfalls mittels einer MobileStrategy und der Erweiterung des CommunicationContext erreicht werden. Die Nötigen Funktionen und Informationen können mit geringem Aufwand umgesetzt werden. Von den Qualitäten können REQ-QUAL-5.1 (Variable Datenübertragung und Verbindung), REQ-QUAL-1 (Funktionalität), REQ-QUAL-1.1 (die Anwendung soll richtig und konsistent arbeiten) und REQ-QUAL-1.2 (Sicherheit der Daten soll gewährleistet werden) mittels des Mobile Strategy Adapter abgedeckt werden. 6.3 OT-ENGINE UND OT-MODEL Die wichtigen Komponenten im GCI sind die OT-Engine sowie das dabei verwendete OT-Model. Während einer Kollaboration mit mehreren Teilnehmern ist es nicht ungewöhnlich, in einen koniktbehafteten Zustand zu gelangen. Für die Auösung dieser Konikte wird die OT-Engine mit dessen OT-Model verwendet. Dabei ist das Ziel dieser Engine einen konsistenten Modellzustand für alle Sitzungsteilnehmer zu erreichen. Beide Komponenten sind auf Client und Serverseite zu nden, um jederzeit das Modell konsistent zu halten. Bei der Beschreibung der GCI wurde auf den Modellunterschied zwischen den bestehenden Bibliotheken und Frameworks eingegangen und dabei zwischen einem DOM Adapter und Framework Adapter unterschieden. Des Weiteren war die Verwendung des DOM Adapter bei mobilen Anwendungen eher nebensächlich, weswegen sich für den Framework Adapter entschieden wurde. Das OT-Model wird von diesem Framework Adapter bereitgestellt und musste Events in einer Baumstruktur traversieren können. Zusätzlich musste die Möglichkeit für eine Eventnotikation angeboten werden, bei der Objekte sich bei einem Model für Änderungen registrieren können. In Abbildung 6.4 wird in einem UML Diagramm die Klassenhierarchie eines OT-Model abgebildet. Als zentraler Ansatzpunkt für die Adaption eines Framework Modells ist das CollaborationModel. Diese Klasse ist abstrakt und stellt bereits alle nötigen Methoden zur Verfügung um eine Baumstruktur zu erzeugen. Des Weiteren können CollaborationListener an einem Modell registriert werden, um über Änderungen informiert zu werden.über die accept() Methode kann ein CollaborationVisitor über die gesamte Baumstruktur geschickt werden, um 6.3 OT-Engine und OT-Model 43

53 Abbildung 6.4: Klassenhierarchie eines möglichen OT-Model. Informationen zu sammeln oder Änderungen zu ermöglichen. Dabei wird das Visitor Entwurfsmuster, welches oft mit dem Composite Design Pattern kombiniert wird, verwendet. In einer Abgewandelten Form ist dies auch in Abbildung 6.4 der Fall. Dass Composite Pattern ermöglicht die Erstellung einer Baumstruktur indem eine Klasse als Blatt und eine weitere als Knoten implementiert werden. Beide erben von einer gemeinsamen Oberklasse und kommunizieren dabei über dessen Interface. Die bereits genannte Klasse CollaborationModel ermöglicht das selbe Prinzip mit dem Unterschied, das noch keine konkreten Klassen als Blatt oder Knoten fungieren. Somit ist ein endloser Baum möglich, da kein Blatt das Ende angibt. Wichtig ist dabei die Typisierung über die Variable project. Diese Typisierung soll als selbst Referenz in der nächsten Klasse die von CollaborationModel erbt verwendet werden. Dabei ergeben sich folgende Vor- und Nachteile. Der spätere Entwickler kann schnell, und ohne Aufwand eine Baumstruktur realisieren, indem er Blätter und Knoten deniert. Alle Methoden um Events zu schicken oder die Baumstruktur abzulaufen sind bereits vorhanden. Dabei ist zu beachten, dass vorher eine Klasse als Zwischenschicht implementiert werden sollte und von dieser dann Blätter und Knoten erben. Die neue Schicht soll dann für projektabhängige Implementierungen verwendet werden. Der Nachteil daran ist die weitere Vererbung über das CollaborationModel womit die Typisierung über die speziellen Projektmodelle verloren geht. Am Beispiel von Abbildung 6.4 wurde das Wave Modell in seiner einfachsten Form umgesetzt. Die zwischen Schicht stellt dabei die Klasse CWave dar. In ihr ist die Methode getcontent() implementiert um auf einmal den gesamten Inhalt des Baumes abzufragen. Von CWave erben die Klassen CBlip, welche als Blatt fungiert und den Inhalt enthält, sowie CConversation, welche ein Knoten darstellt und die Ordnung der Blips vorgibt. CBlip und CConversation verfügen somit über die Methode getcontent() und können ohne vorherige Typprüfungen der CWave Klasse diesen zurückgeben. Weitere Methoden die im Wave Kontext benötigt werden brauchen dem zufolge nur in der Klasse CWave implementiert werden. Das Ziel des CollaborationModel soll die Frameworkunabhängkeit sein und dennoch alle Eigenschaften und Funktionen eines OT-Model anbieten. Dadurch kann der spätere Entwicklungsaufwand reduziert werden. Der bereits genannte Nachteil würde am Beispiel bei einer weiteren Unterklasse von CollaborationModel entstehen und somit auf einer Ebene mit der Klasse CWave liegen. Eine umständliche Typumwandlung wäre dann von Nöten, wenn das Interface von CollaborationModel verwendet wird und weiterhin alle Unterklassen mit einbezogen werden. Der eben genannte Nachteil wird aber von dem generischen und schnell erweiterbaren CollaborationModel relativiert. Die richtige Verwendung und Implementierung eines Framework liegt letzten Endes beim Entwickler selber. Aus [24] gingen zwei Ansätze zur Interaktion mit dem OT-Model hervor. Beim verteilten Ansatz gibt es mehrere Datenmodelle und somit mehrere Wurzelknoten, von denen aus Daten erreicht werden können. Bei einem kohärenten Ansatz gibt es nur einen Wurzelknoten und dadurch ein gemeinsames Datenmodell. Das eben beschriebene Datenmodell mit dem CollaborationModel als Wurzelknoten entspricht dem zufolge dem kohärenten Ansatz. In [24] wurde bei einem kohärenten Datenmodell ein Wrapper Objekt für die Implementierung vorgestellt, um die API für das Datenmodell zu kapseln und dadurch ein bestehendes Datenmodell mit kollaborativen 44 Kapitel 6 Implementierung

54 Abbildung 6.5: JSON zu Modell Konverter Funktionen zu erweitern. Dieses Konzept lässt sich ebenfalls auf das beschriebene CollaborationModel anwenden. Die OT-Engine soll aus einem bestehenden Framework adaptiert und dadurch wieder verwendet werden. In der Beispielanwendung wird dabei der Operational Transformation Algorithmus verwendet. Zur Umsetzung wurden bereits bestehende Komponenten aus der Apache Wave Plattform extrahiert und für eine Nutzung adaptiert. Die Operational Transformation wurde bereits im Detail in Abschnitt 2.4 erläutert und in mehreren Abschnitten zu anderer Literatur referenziert. Die Umsetzung soll deshalb nicht weiter vertieft werden. Das Interface der OT-Engine bedarf keiner detaillierten Spezikation, da lediglich zwei Operationen in den OT Algorithmus als Argumente übergeben werden und zwei koniktfreie Operationen als Ergebnis zurück gegeben werden. Die Anbindung an das OT-Model und das Starten der Synchronisation durch lokale Änderungen werden vom Framework Adapter übernommen, da dieser das Bindeglied von mehreren Komponenten darstellt. Als Abschluss dieses Abschnittes werden die Anforderungen, welche an die OT-Engine sowie deren OT-Model gestellt wurden noch einmal erläutert. Die funktionalen Anforderungen REQ-FUNC-2.2 (Nebenläugkeitskontrolle) werden durch das OT-Model und seiner Events sowie Notikationsfunktionen unterstützt. Die Konikte, welche bei Nebenläugkeit entstehen können, werden dabei von der OT-Engine aufgelöst. REQ-FUNC-2.6 (Datensynchronisierung) wird mit dem Zusammenspiel von OT-Model, OT-Engine und Kommunikationsadapter realisiert. Alle lokalen Operationen werden auf das OT-Model angewendet und nach Koniktauösung vom Kommunikationsadapter an weitere Sitzungsteilnehmer versendet. Die technische Anforderung REQ-TECH-1.1 (Adapter zur Kollaboration mittels Apache Wave) kann mit den in diesem Abschnitt genannten Klassen umgesetzt werden und in die GCI integriert werden. Als Abschluss sei REQ-QUAL-1.1 (die Anwendung soll richtig und konsistent arbeiten) genannt. Dieses Muss-Kriterium kann mit den hier vorgestellten Komponenten erfüllt werden. 6.4 FRAMEWORK ADAPTER Der Framework Adapter ist eine der wichtigsten Bestandteile der GCI aus [24]. Im Vergleich zum DOM Adapter ist der Framework Adapter zur Erweiterung einer Anwendung um kollaborative Funktionen entwickelt worden. Dieser Adapter stellt das Bindeglied zwischen bestehender Anwendung und neuem Framework dar. Die anderen GCI Adapter sowie deren einzelne Bestandteile werden im Framework Adapter vereint. Die Erschlieÿung der kollaborativen Funktionen durch die anwendungsunabhängige API Schicht wird von diesem Adapter beeinusst. Das Datenmodell sowie deren Operationen werden durch den Framework Adapter von einem bestehenden Framework adaptiert und wieder verwendet. Dies gilt ebenfalls für die OT Engine um Konikte auösen zu können. Der Change Recorder, Model Manipulator und Operation Mapper aus Abschnitt 5.5 sind Bestandteile um die eben genannten Ziele dieses Adapters zu erreichen. Der Operation Mapper dient zur Umwandlung der Framework Daten in ein anwendungsverständliches Modell. Operationen werden am Beispiel von Apache Wave im JSON 6.4 Framework Adapter 45

55 Format übertragen und in ein Operation-Model überführt. Dieses Operation-Model wird von einer OT-Engine transformiert und danach auf ein OT-Model angewendet. Die OT-Engine und das OT-Model wurden bereits im vorherigen Abschnitt 6.3 genannt. Der Operation Mapper hat weiterhin das Potenzial der Wiederverwendung, den JSON-Model-Konverter sind bereits mehrfach verfügbar. Die Java Bibliothek GSON 2 von der Firma Google ist solch eine Bibliothek um Json in Java Objekte zu serialisieren und umgekehrt. Auch bei Android stehen einige Klassen zur Verfügung um Json zu parsen. Diese scheinen im Vergleich zu GSON nicht so elegant, wurden aber dennoch in der Beispielanwendung verwendet. Die Klassen JSONObject und JSONArray verfolgen dabei das lazy-load Prinzip. D.h. eine Json Nachricht wird nach Inhalten durchsucht, und zwar dann, wenn diese angefordert werden. Im Vergleich dazu wird bei GSON eine komplette Nachricht in ein Objekt konvertiert, um damit arbeiten zu können. Der dabei benötigte Rechenaufwand ist somit gröÿer. Der Operation Mapper ist im Anwendungsbeispiel die Klasse OperationParser. Der Name wurde deshalb gewählt, da der OperationParser einen Json String entgegen nimmt und in ein abstraktes JSONObject konvertiert. Danach übergibt der OperationParser dieses Objekt einem OperationProcessor Interface, welches zuvor für einen bestimmten Operationstyp am OperationParser registriert wurde. Der OperationParser entfernt die Typinformationen, welche der Operation hinzugefügt wurde, während der OperationProcessor die Operation typisiert und verarbeitet. Dadurch werden nur ausgewählt Operationen behandelt und bereits nach dem Empfang am Client geltert. Der Event- und Operativansatz bei Wave, prägte ebenfalls diese Designentscheidung. Die Json Nachrichten enthalten mehr Operation Beschreibungen als Modelinformationen. Die Modellstruktur setzt sich aus den Objekten Wavelet, Conversation, Thread und Blip zusammen. Operationen hingegen in WaveletOperation oder DocumentOperation mit weiteren Components, Versionen etc. Die Operationen und deren Struktur nehmen einen groÿen Teil in der Anwendung ein, wohin gegen das OT-Model sehr klein gehalten ist. Der Model Manipulator trägt zum Anwenden der Operationen auf das OT-Model bei. Diese Komponente kann in einer separaten Klasse oder in dem eben genannten OperationProcessor realisiert werden. Dieser Teil der Anwendung ist Framework abhängig und muss individuell angepasst werden. In Abbildung 6.5 ist eine Übersicht der eben genannten Klasse zu nden. Der OperationParser erhält vom CommunicationAdapter die Json Nachrichten als String Objekt. Über die Methode registerprocessor(), lässt sich die konkrete Klasse WaveletUpdateOperationProcessor registrieren, welche das OperationProcessor Interface implementiert und für Wavelet Updates verantwortlich ist. Neben der WaveletUpdateOperation gibt es noch weitere Operationen die jeweils von einem eigenen OperationProcessor verarbeitet werden. Dabei muss die Methode getoperationtype() eine Konstante für den Namen der Operation zurückgeben, welche wiederum in der Json Nachricht enthalten ist. Der OperationParser entnimmt der Json Nachricht die Typinformation und such einen entsprechenden OperationProcessor. Bei einer Typübereinstimmung wird ein JSONObject dem Processor übergeben. Dieser konvertiert das JSONObject in ein Operation Modell, das darauf hin auf ein OT-Model angewendet wird. Die Rolle des Model Manipulator wird dabei vom OperationProcessor übernommen. Die OT-Engine wird am Beispiel von Wave, auf das Operation Modell angewendet. Eine klare Trennung der Zuständigkeit, welche Komponente im GCI auf das OT-Model zugreift und es manipuliert, ist in der Beispielanwendung nicht komplett gegeben. Der Change Recorder ist ebenfalls im Framework Adapter enthalten und arbeitet eng mit der OT-Engine zusammen. Am Beispiel von Apache Wave werden lokale Operationen mit remote Operationen durch OT transformiert und im Paket verschickt, da Operationen bei Wave zusätzlich komponiert werden können. Die OT-Engine auf Serverseite kann diese dann dekomponieren und einzeln transformieren. Alle Operationen werden bei Wave mit einem Acknowledge quittiert um dabei den OT Graphen synchron zu verfolgen. Dadurch ist der Change Recoder in der Lage, die noch oenen Operationen zwischenzuspeichern und nach erfolgreicher Modellanwendung wieder zu entfernen. 6.5 WORKSPACE AWARENESS ADAPTER Eine ebenfalls bekannte Komponente der GCI aus [24] ist der Workspace Awareness Adapter. Dieser wurde bereits in Abschnitt Adapter in seiner Funktionalität beschrieben und soll in diesem Abschnitt vonseiten der Implementierung angeschnitten werden. Der Bereich der Workspace Awareness ist weiterhin ein aufwendiges und komplexes Thema, denn eine generische Auswahl von Operationen bezüglich deren Priorität in der Anwendung bzw. deren Einuss auf den Arbeitsbereich, kann nicht ohne Kenntnisse über die eigentliche Anwendung getroen werden, um daraus Awareness Events abzuleiten. Das Ziel des Workspace Awareness Adapter ist die Abstraktion und Reduktion von bekannten Operationen eines kollaborativen Frameworks. 2 code.google.com/p/google-gson/ 46 Kapitel 6 Implementierung

56 Abbildung 6.6: Aufbau eines Workspace Awareness Adapter mit dessen Komponenten. Das dabei entstehende Set von Operationen wurde bereits als Sammlung von Awareness Events bezeichnet und diese sind von deren Priorität nicht vergleichbar mit Operationen auf Modellebene. Am Beispiel von Apache Wave gibt es eine Dierenzierung der Operationen. Es wird in Dokument-, Wavelet- und NoOp-Operationen unterschieden. Eine Dokumentoperation enthält dabei Informationen bezüglich einer Modellmanipulation wie zum Beispiel das Einfügen von Buchstaben in ein Textdokument. Eine Waveletoperation bezieht sich auf den Container des Dokumentenmodells. So umfasst ein Wavelet neben dem kollaborativen Dokument auch eine Liste von Teilnehmern. Die NoOp-Operation ist das Ergebniss einer OT Transformation bei dem sich zwei Operationen annoliert bzw. gegenseitig aufgehoben haben. Der Inhalt solch einer Operation ist daraufhin leer und zieht keine Modelländerung nach sich. Für einen Workspace Awareness Event bietet sich die Waveletoperation an, denn diese hat keinen konkreten Einuss auf die wesentliche Dokumentenkollaboration und liefert zusätzliche Informationen für andere Teilnehmer. Das Hinzufügen oder Entfernen von Editorteilnehmern ist keine Information die mit dem Bearbeiten des Editortextes zusammengehört, aber dennoch einen Nährwert in der Kollaboration bringt. Der Workspace Awareness Adapter benötigt Zugri auf die Funktionalitäten des Framework Adapter und dessen Model Manipulator sowie eine Schnittstelle um ebenfalls, bereits OT transformierte, Operationen zu erhalten. Zusätzlich muss eine Anbindung an die Funktionalitäten der Anwendung ermöglicht werden können, damit ein Workspace Awareness Widget ebenfalls Operationen auslösen kann. Dafür kämen der Framework Adapter oder die anwendungsunabhängige API in Betracht. Nachdem nun die Schnittstellen zwischen den verschiedenen Adaptern deniert wurden, liegt der Fokus nun auf den einzelnen Bestandteilen des Workspace Awareness Adapter. Die eben genannten Workspace Awareness Widgets zeigen kontextsensitive Informationen, betreend einer Kollaboration an. Ein Widget kann zusätzliche eine oder mehrere Interaktionen unterstützen. Solch ein Widget ist beispielsweise eine Teilnehmerliste. Diese enthält Informationen über die Sitzungsteilnehmer und damit weiterer Bearbeiter des kollaborativen Modells. Das Apache Wave Framework, versendet mit dem Beitreten einer Sitzung nicht nur das Modell, sondern auch eine List der bereits anwesenden Teilnehmer. Damit keine Missverständnisse auftreten, sei gesagt, dass diese Liste statischer Natur ist und nicht die Teilnehmer anzeigt, die in Echtzeit anwesend sind, sondern lediglich das Recht besitzen, der kollaborativen Sitzung beizutreten. Die Nutzerinteraktion des Teilnehmerlisten-Widgets kann dabei das Hinzufügen oder Entfernen von Teilnehmern sein. Das Hinzufügen eines Teilnehmer kommt dabei einer Einladung gleich. Ein Awareness Widget besteht aus einer Ansicht (View) und verarbeitet einen Awareness Event Typ. Der Workspace Awareness Adapter überwacht die Anwendungsoperationen und abstrahiert diese zu einem Awareness Event bzw. ignoriert die nicht abstrahierbaren. Dabei kann der Awareness Event die original Operation kapseln oder Informationen für die Weiterverarbeitung extrahieren. Im Anschluss daran wird aus einem Register ein bereits registriertes Awareness Widget, welches den erstellten Awareness Event unterstützt, gesucht und diesem der Event übergeben. Das Widget verarbeitet eigenständig den eingehenden Event und aktualisiert seine View. Für die Interaktionen eines Widget muss ein Zugri auf die Funktionalitäten der Anwendung möglich sein und somit eine Referenz zum Framework Adapter oder der anwendungsunabhängigen API bestehen. Ein Punkt wurde bisher nicht geklärt, denn noch können die Awareness Widgets nicht in der Editor UI angezeigt werden, da keine passenden Steckplätze (Slots) für das Widget bekannt sind. Um die saubere Trennung zwischen Single-User und Multi-User Komponenten weiter zu stützen, ist die Bereitstellung der UI Slots durch die anwendungsunabhängige API die beste Lösung für dieses Problem. Für eine dynamische Erweiterung der Awareness Widget kann der Mobile Strategy Adapter verwendet werden. Das bereits vorgestellte Konzept aus 5.3 sowie dessen mögliche 6.5 Workspace Awareness Adapter 47

57 Implementierung aus 6.2 lassen sich ohne weitere Schwierigkeiten in diesen Adapter integrieren. Der MobileContext setzt sich mit der Gröÿe des mobilen Gerätes und der damit verbundenen Anzahl an möglichen Anzeigekomponenten auseinander. Dabei variiert die Anzahl an UI Slots um somit mehr oder weniger Awareness Widgets in die Anwendung zu integrieren. Eine SmartphoneStrategy sowie TabletStrategy verarbeiten die Integration oder Exklusion sowie den Lebenszyklus eines Awareness Widget um unnötigen Rechenaufwand für die Anwendung zu vermeiden. Die dynamische Integration bzw. Exklusion von Awareness Widgets entspricht der funktionalen Anforderung REQ-FUNC-2.7 (Gröÿenanpassbare Oberäche) sowie der technischen Anforderung REQ-TECH-2.3 (Rücksicht der unterschiedlichen Displaygröÿe). Beide Anforderungen erhöhen die Benutzbarkeit einer mobilen Anwendung und Schaft klare Strukturen sowie Funktionalität. Es trägt ebenfalls zu Qualität einer Anwendung bei und wurde mit den Qualitätsanforderungen REQ-QUAL-3 (Benutzbarkeit) und REQ-QUAL-3.1 (Funktionen im Rahmen des möglichen Platzes) erfasst. Eine Vertiefung der Thematik Workspace Awareness ist kein Bestandteil dieser Arbeit. Es besteht aber durchaus die Möglichkeit dies in weiteren Arbeiten fortzuführen. Die Arbeiten [27] und [28] von Carl Gutwin und Saul Greenberg seien an dieser Stelle noch genannt. In diesen wird der Einuss von Workspace Awareness auf die Benutzbarkeit von kollaborativen Anwendungen beschrieben sowie ein Framework zu Erstellung von Workspace Awareness vorgestellt. Als Abschluss zeigt die Abbildung 6.6 die genannten Komponenten des Workspace Awareness Adapter als ein UML Diagramm. 6.6 UMSETZUNG AUS SICHT DES ENTWICKLERS Nach den bisher genannten Konzepten und Implementierungen soll dieser Abschnitt die Nutzung des entstandenen kollaborativen Frameworks aus Sicht des Entwicklers näher betrachten. Es soll das Verständnis der Zusammenhänge und nötigen Schritte der Erweiterung verdeutlichen. Das Ziel des kollaborativen Frameworks ist die generische Erweiterung einer Single-User zu einer Multi-User Anwendung. Dabei soll der Entwickler in die Lage versetzt werden, seine Anwendung eigenständig mit kollaborativen Funktionen zu erweitern. Dabei kommt eine Infrastruktur aus Adaptern zum Einsatz, welche spezielle Funktionalitäten und Eigenschaften kapseln und dabei keinen direkten Einuss auf bestehende Anwendungsteile nehmen. Stattdessen werden die bestehenden Single-User Anwendung um eine anwendungsunabhängige API erweitert, worüber die kollaborativen Komponenten integriert werden. Diese anwendungsunabhängige API wird als separate Schicht zwischen Datenmodell und Anwendungsfunktionalitäten hinzugefügt. Das Ziel dieser API ist es, die Änderungen am Datenmodell zu erfassen und somit an weitere Sitzungsteilnehmer zu verteilen. Die API muss dabei über das selber Interface wie vor der Integration verfügen, um die Funktionalität nicht zu verringern und weiterhin mit der Anwendung zu kommunizieren. Die Anwendung muss in der Lage sein, die nötigen Daten abzufragen und Änderungen auf das Modell anzuwenden. Eine Integration von weiteren Anzeigekomponenten sollte ebenfalls über diese API realisierbar sein, wodurch eine Schnittstelle zur UI Schicht vorausgesetzt wird. Dadurch besteht die Möglichkeit des Hinzufügens von Awareness Widgets um die Zusammenarbeit von mehreren Nutzern zu fördern. Nachdem eine unabhängige Anwendungsschicht erstellt wurde und dadurch Modelländerungen mitverfolgt werden können, muss das eben genannte Modell für kollaborative Zwecke erweitert werden. Dafür wurde die Klasse CollaborationModel vorgestellt, womit ein Hierarchie gebildet werden kann und Events über diese Struktur traversiert werden können. Das Parsen von Modellinhalten ist durch das Visitor Pattern ebenfalls möglich. Die Verwendung des CollaborationModel als wrapper, um das ursprüngliche Datenmodell zu kapseln, ist dabei eine mögliche Vorgehensweise in der Implementierung. Durch das Hinzufügen eines CollaborationListener am Modell können Änderungen verfolgt und Anzeigekomponenten aktualisiert werden. Der nächste Schritt ist die Wahl und Anpassung eines kollaborativen Frameworks. Die Funktionalität des Frameworks und dessen ursprüngliche Intension der Verwendung sollte dabei berücksichtig werden. Im Rahmen dieser Arbeit wurde das Apache Wave Framework gewählt mit dessen Operational Transformation Algorithmus, Konikte zwischen Modelloperationen aufgelöst werden können. Wave unterstützt dabei das schreiben und bearbeiten von Textnachrichten und sollte ursprünglich eine Erweiterung der darstellen. Die gemeinsame Bearbeitung von Nachrichten oder längeren Texten ist ebenfalls möglich. Die Beispielanwendung dieser Arbeit verfügt über die Funktion, Textnachrichten zu anderen Nutzern zu verschicken und dabei ganze Nachrichtenverläufe zu erstellen. Das gemeinsame Editieren von Nachrichten ist ebenfalls Ziel dieser Anwendung. Nachdem ein Framework für die Umsetzung der kollaborativen Funktionen 48 Kapitel 6 Implementierung

58 gewählt wurde, wird der Framework Adapter implementiert. Dieser adaptiert die Funktionen des gewählten Frameworks an die Gegebenheiten der bestehenden Anwendung. Dabei wird ein Model Manipulator für die Bearbeitung des bereits erstellten CollaborationModels implementiert. Neben dem Model Manipulator wird ein Operation Mapper benötigt. Dieser bildet die Operationen des Frameworks auf das neue CollaborationModel ab, um somit entfernte Änderungen auf das lokale Modell anwenden zu können. Da Operationen bei der Koniktbehebung rückgängig gemacht oder deren Reihenfolge geändert werden kann, wird ein Change Recorder für das Wiederholen und Nachvollziehen von Operationen eingesetzt. Im Anschluss an den Framework Adapter wird die OT Engine sowie deren Kopplung an das OT Model implementiert. Die OT Engine wird dem ausgewählten und bereits adaptieren Framework entnommen. Das adaptierte Datenmodell wird vom CollaborationModel repräsentiert und dabei vom lokalen Nutzer, sowie mehreren remote Nutzern bearbeitet. Eine Synchronisierung des Datenmodell ist somit die Folge. Bisher wurden Datenmodell, Framework und OT Engine adaptiert, implementiert und miteinander verbunden. Das Versenden und empfangen von Operationen wird vom Kommunikationsadapter übernommen. Ein Kommunikationsadapter, basierend auf dem WebSocket Protokoll, kann dem kollaborativen Framework dieser Arbeit entnommen oder neu implementiert werden. Die Zusammenhänge der einzelnen Komponenten dieses Adapters und die Möglichkeiten dessen Erweiterung wurden bereits in Abschnitt 6.1 erläutert. Alle bisher genannten Komponenten vereinen nun die Fähigkeiten einer Multi-User Anwendung. Der Workspace Awareness Adapter erweitert die Nutzbarkeit von kollaborativen Funktionen und trägt zur Verbesserung des Verständnisses, gegenüber dem Handeln der andere Sitzungsteilnehmer bei. Der erste Schritt zur Workspace Awareness ist die Identizierung von verwendbaren Operationen, wie zum Beispiel Teilnehmer betreende. Danach werden ein oder mehrere Awareness Widgets umgesetzt um Informationen, die aus einer Operation entnommen werden können, anzuzeigen. Der Workspace Awareness Adapter soll die Anwendungsoperationen ltern und mögliche Awareness Events daraus ableiten und an passende Awareness Widgets verteilen. Die von einem Awareness Widget unterstützen Interaktionen müssen vom Adapter in Form von Operationen aufgenommen und an die anderen Komponenten der kollaborativen Infrastruktur verteilt werden. Zum Schluss soll der Mobile Strategy Adapter eine Erweiterung der gesamten Infrastruktur ermöglichen. Dabei ist dies kein Musskriterium einer Anwendung, es fördert jedoch das Verhalten der Anwendung in Bezug zu kontextsensitiven Informationsverarbeitung. So können Oinefunktionen bei einem Verlust der Internetverbindung umgesetzt oder unterschiedliche Displaygröÿen verarbeitet werden. Die folgenden 6 Punkte sollen einen Wegweiser für den späteren Anwender des in dieser Arbeit entstandenen Frameworks darstellen. Gleichzeitig ist es eine kurze Zusammenfassung der nötigen Schritte, welche in diesem Abschnitt genannt wurden, um eine Anwendung mit kollaborativen Funktionen zu erweitern. 1. Einzug einer anwendungsunabhängige API zwischen Datenmodell und Anwendungsfunktionalität. 2. Erweiterung des Datenmodell mit Hilfe des CollaborationModel. 3. Implementierung des Framework Adapter und alle dabei zusammenhängende Komponenten, samt OT Engine. 4. Anbindung eines Kommunikationsadapter für die Kommunikation mit entfernten Teilnehmern. 5. Identizierung von Awareness Events und der damit korrespondierenden Widgets, welche mittels eines Workspace Awareness Adapters kombiniert werden. 6. Verbesserung der Anwendung gegenüber kontextsensitiver Informationen durch einen Mobile Strategy Adapter. 6.7 ZUSAMMENFASSUNG In diesem Kapitel wurden die bereits aus Kapitel 5 vorgestellten Adapter mit Blick auf deren Implementierung beschrieben. Zu jeder Komponente der GCI wurden weitere Bestandteile mit deren Funktionen und Eigenschaften aufgeschlüsselt. Auf Basis des Android Betriebssystems und dem Apache Wave kollaborations Framework entstand eine Beispielanwendung sowie der Entwurf eines generischen kollaborativen Frameworks mit dem Schwerpunkt der mobilen Entwicklung. Zu den bereits existierenden Adaptern aus der Arbeit [24] von Matthias Heinrich entstanden der 6.7 Zusammenfassung 49

59 Kommunikationsadapter und der Mobile Strategy Adapter. Die neu entwickelten Adapter sowie der Framework Adapter und Workspace Awareness Adapter wurden an die speziellen Herausforderungen und Gegebenheiten der mobilen Plattform angepasst. Dabei zeigten verschiedene UML Diagramme eine mögliche Implementierung mittels Klassen und Interfaces, welche dem neu programmierten Framework entnommen werden können. Zum aktuellen Zeitpunkt dieser Arbeit stützt sich das generische und kollaborative Framework für mobile Endgeräte auf Variabilität und Erweiterbarkeit. Der spätere Entwickler und somit Nutzer dieses Frameworks soll in die Lage versetzt werden, ohne Hindernisse die bestehende Infrastruktur aus Adapter zu erweitern und auch während der Laufzeit exibel zu gestalten. Es wurde mehrfach Bezug auf die aus Kapitel 3 genannten funktionalen, nicht-funktionalen und qualitativen Anforderungen genommen. Die Zusammenhänge zwischen den neuen und vorhandenen Adaptern wurden erklärt und am Beispiel vorgestellt. Mit einem Wechsel des Blickwinkels entstand eine Anleitung für die Nutzung des generischen, kollaborativen Framework und der dadurch einhergehenden Erweiterung einer bestehenden Single-User Anwendung zu einer Multi-User Anwendung. 50 Kapitel 6 Implementierung

60 7 EVALUATION In den vorangegangenen Kapiteln wurde zur Generic Collaboration Infrastructure das Konzept und die Implementierung für den Einsatz auf mobilen Endgeräten dargelegt. Dabei entstand eine mobile Anwendung mit dem Konzept der GCI und der Adaption der Apache Wave Plattform. Die kollaborative Anwendung konnte auf einem Android Smartphone getestet werden.in diesem Kapitel soll die Umsetzung mit dem Adapterprinzip sowie das Verhalten der Anwendung in Bezug auf Zeitverhalten und Adaption evaluiert werden. Zunächst wird in Abschnitt 7.1 die Eingliederung der GCI in eine bestehende Android Anwendung bewertet. Danach wird in Abschnitt 7.2 die Mittel und Vorbereitungen der praktischen Umsetzung beschrieben. Zum Abschluss werden in 7.3 die Durchführung und Testergebnisse besprochen. 7.1 INTEGRATION DER GENERIC COLLABORATION INFRASTRUCTURE IN ANDROID Im Laufe dieser Arbeit wurden Komponenten der GCI sowie deren Voraussetzungen an eine bestehende Anwendung beschrieben. Während der Implementierungsphase zeigte sich ein erhöhter Zeitbedarf für die Vorbereitungen des Kommunikationsadapters. Dieser Adapter Schaft eine zentrale Schnittstelle zum Internet und muss somit für jede Klasse im Projekt verfügbar sein, die Daten von entfernten Diensten benötigt. Bei der Entwicklung mit Android sind View und Controller eng miteinander verbunden und kapseln damit Logik und Darstellung in einer Komponente. Eine richtige Umsetzung des MVC Pattern wird damit erschwert. Eine Lösung für dieses Problem kommt mit der anwendungsunabhängigen API. Diese ist für die anwendungsspezischen Funktionen verfügbar und kann eine Referenz zum Kommunikationsadapter bereitstellen. Alternative oder mehrere Kommunikationsadapter sind dabei ebenfalls möglich. In der Beispielanwendung existiert ein Adapter für die WebSocket-Kommunikation um direkt mit dem Apache Wave Server zu kommunizieren sowie einen HTTP Adapter um von einem WebService Bilder der Nutzer zu downloaden. Wie die jeweiligen Adapter funktionieren, ist für die höher liegenden Schichten irrelevant. Lediglich das Interface muss die Funktionalität unterstützen. Für die anwendungsunabhängige API hat sich die Activity Klasse am besten für die Erweiterung herausgestellt. Eine Activity repräsentiert einen Screen auf dem mobilen Gerät. Solch eine Activity kann mehrere Fragments besitzen, welche wiederum View und Controller in sich vereinen. Somit werden Editor und weitere Anzeigekomponenten mittels Fragments realisiert, während die Acitivity als Manager zwischen diesen fungiert. Das Datenmodell wird ebenfalls von der Activity an die Fragments übergeben. Die anwendungsunabhängige API kann nun von der Activity repräsentiert, und damit von jedem Fragment verwendet werden. Abbildung 7.1 zeigt die Architektur der Beispielanwendung. Dabei haben sich die Umsetzungen von Log-in, Nutzerregistrierung, Prol und Editor in einem Fragment als am eektivsten ergeben. Die Views setzen sich aus den plattformabhängigen Widgets, wie Listen, Buttons und 51

61 Abbildung 7.1: Konkrete Umsetzung der Anwendungsschichten am Beispiel von Android. Texten zusammen. Abhängig vom Anwendungszustand, tauscht eine Activity die Fragments aus und stellt die Schnittstelle zur Adapterinfrastruktur dar. Die vorangegangenen Anpassungen an der Anwendung bildeten die Voraussetzungen für die Integration der GCI Adapter. Durch die Kapitel 5 sowie 6 werden ausreichend Informationen zum Aufbau und Zusammenspiel der einzelnen Adapter gegeben. Die konkrete Programmierung des Kommunikationsadapters sowie des Mobile Strategy Adapters konnte ohne weitere Probleme realisiert werden. Der Workspace Awareness Adapter hatte bei der Umsetzung eine geringe Priorität und wurde deshalb nicht weiter verfolgt. Der meiste Aufwand entstand bei der Adaption des Frameworks für die kollaborativen Funktionen. Das Datenmodell sowie die OT Engine mussten implementiert und verknüpft werden. Komponenten wie Operation Mapper, Model Manipulator und Change Recorder wurden ebenfalls umgesetzt. Es stellte sich heraus, dass sich in kleinere Anwendungen ein übersichtliches kollaboratives Framework schnell integriert lässt. Mit gröÿeren Anwendungen steigt die Komplexität und die Zeit des refaktorierens um die nötigen Voraussetzungen für die Adapterstruktur umzusetzen. Mit steigender Funktionalität des Frameworks steigt auch dessen Komplexität und Aufbau. Die Einarbeitungszeit sowie Adaption an eine bestehende Anwendung wird dadurch ebenfalls gesteigert. Das Ziel dieser Arbeit ist die Umsetzung eines generischen und kollaborativen Frameworks für mobile Endgeräte. Der generische Aspekt dieses Frameworks kann dabei nur auf einer niedrigen Anwendungsebene liegen. Spezielle Funktionen, wie in Abbildung 3.1 zu sehen sind, können nicht Teil dieses Frameworks, sondern des zu adaptierenden sein. Das zu adaptierende Framework ist am Beispiel dieser Arbeit Apache Wave, dessen Funktionen in Abbildung 3.1 dargestellt sind. Trotz der mittlerweile groÿen Anzahl an Adaptern und deren Bestandteile ist das Konzept der GCI schlüssig und gut verständlich. Durch die Trennung der Funktionen und klarer Interface Denitionen kann das Konzept weiterhin verbessert und erweitert werden. 7.2 TESTUMGEBUNG Während der Anwendungstests wurde ein Nexus 4 Smartphone (Android 4.4.2), ein Motorola Xoom Tablet (Android 4.2) und der Android Emulator (Android 2.2) auf einem Acer TravelMate 5720 verwendet. Auf den Geräten wurde jeweils die Client-Anwendung mit dem beschriebenen 52 Kapitel 7 Evaluation

62 GCI Konzept installiert. Als Framework Server wurde der Apache Wave Demo Server 1 verwendet. Alternativ kann sich dieser als Github Projekt 2 geklont und danach lokal installiert werden. Zusätzlich wurde der Web Client bei den Tests mit einbezogen, da nicht alle Funktionalität aus Zeitgründen im mobilen Client implementiert werden konnten. Alle Geräte kommunizierten über eine WLAN-Verbindung mit dem Apache Wave Server. Für die Nutzung im mobilen Sektor wurde eine entscheidende Einschränkung festgestellt. Mit dem Provider Vodafone war es nicht möglich eine WebSocket Verbindung zwischen Smartphone und Wave Server zu etablieren. Das Problem sind dabei die Proxy-Server zwischen Client und Server. Das WebSocket Protokoll wurde so designt, dass frühzeitige Fehlererkennung möglich ist. Die Proxy-Server können die Protokoll-Upgrade-Anfrage nicht verarbeiten und brechen daraufhin den Verbindungsaufbau ab. Somit können keine Verbindungen auf Basis von WebSockets hergestellt werden. Inwieweit dieses Problem bei den Providern verbreitet ist, kann nicht festgestellt werden, aber es schränkt die aktuelle Nutzung für mobile Nutzer ein. 7.3 DURCHFÜHRUNG UND AUSWERTUNG Der Workow der Anwendung wird in Abbildung 7.2 dargestellt. Der Nutzer meldet sich zu Beginn einer Sitzung am System an bzw. registriert sich. Nach erfolgreicher Authentizierung am Server werden alle Sitzungen, denen beigetreten werden kann, aufgelistet. Dabei wird unterteilt in bereits beigetretene Sitzungen, alle die am Server existieren und Sitzungen, die einem Suchkriterium entsprechen. Dadurch kann die Anwendung nach bestimmten Sitzungen ltern. Nachdem eine Sitzung ausgewählt und dieser beigetreten wurde, wird das Datenmodell vom Server übertragen. Ab diesem Punkt der Anwendung beginnt der Synchronisationsprozess des Modells. Entfernte Operationen werden übertragen und am lokalen Modell wiederholt. Zu Testzwecken wurde die Übertragungszeit von Operationen gemessen. Abbildung 7.3 zeigt die Netzwerkauslastung bei einer Kollaboration zwischen web und mobilem Client. Die Anwendung empfängt dabei entfernte Operationen in nahezu Echtzeit. Dabei ist zu erkennen, dass die empfangenen Pakete in ihrer Gröÿe variieren, was sich aus der Komposition von Operationen ableiten lässt. Die Operationen selber werden von der mobilen Anwendung mit einem Acknowledge quittiert, was die geringen Ausstöÿe im TX Bereich erklärt. Zu bemerken ist auÿerdem die höchste Messspitze im RX Bereich, wobei 30 Kilobyte/s übertragen wurden. Im Vergleich dazu wurden maximal 3 Kilobyte/s gesendet. Bei ca. 40 Zeichen in schneller Folge wurden 0,5 KB empfangen und das über eine Zeit von ca. 30 Sekunden. Gesendet wurden 0,06 KB über denselben Zeitverlauf. Dadurch ergibt sich eine Übertragung von beinahe 1 MB die Minute bei schnellem Schreiben. Da die Geschwindigkeit von mobilen Internetverbindungen an eine Datenvolumengrenze gebunden ist, kann die Nutzung von kollaborativen Anwendungen auf einem mobilen Endgerät nur begrenzt einsetzbar sein. Ein Wechsel auf WLAN wäre dabei die beste Alternative, wenn vorhanden. Um die Komplexität des adaptierten kollaborativen Apache Wave Frameworks besser zu verdeutlichen wurde eine Metrik vom Originalprojekt erstellt und dem Projekt dieser Arbeit gegenübergestellt. Das komplette Apache Wave Projekt, bestehend aus Server, Web-Client und Protokollnachrichten umfasst rund Zeilen Code. Im Vergleich dazu wurden während dieser Arbeit rund Zeilen Code geschrieben. Dabei wurden einige Klassen aus dem Wave Projekt extrahiert und wiederverwendet, so zum Beispiel die OT Engine und Wave Modelle. Weitere Metriken nden sich unter Abbildung 7.4. Eine besonders zeitintensive Phase war die Implementierung. Das Apache Wave Projekt wurde vor über drei Jahren von der Firma Google übergeben und seitdem nicht aktiv weiterentwickelt. Eine Dokumentation für den Code ist nicht vorhanden bzw. in Form von Kommentaren im Code zu nden. Stattdessen existieren Paper zum Konzept sowie zu Algorithmen. Zusätzlich nden sich im Internet noch Videos zu Vorträgen bei der Google I/O, als das Projekt noch von Google betreut wurde. Eine Internetgemeinschaft hält das Projekt weiter am Leben. Die Korrespondenzen per vermitteln den Eindruck einer aktiven Community, dennoch ist deren Fortschritt gering und nicht am mobilen Sektor orientiert. Für eine detailliertere Evaluation muss auf noch folgende Arbeiten verwiesen werden. Das Ziel ist ebenfalls die aktive Auswertung des generischen und kollaborativen Frameworks mit Entwicklern, um von deren Nutzung weitere Verbesserungen und Eindrücke zu erhalten. 1 Demo Website: waveinabox.net 2 github.com/apache/incubator-wave 7.3 Durchführung und Auswertung 53

63 (a) Login und Registrierung (b) Wavelets mit Filterfunktion (c) Wavelet Dokumente mit Teilnehmerliste Abbildung 7.2: Workow der Anwendung mit Login, Inbox und Editor Ansicht. Abbildung 7.3: Netzwerkstatistik einer WebSocket-Verbindung zwischen Wave Server und mobilem Client. RX steht dabei für Received Packages und TX für Transmitted Packages. 54 Kapitel 7 Evaluation

64 (a) Apache Wave Projekt (b) Mobile GCI/Wave Projekt Abbildung 7.4: Lines of Code im Vergleich In Kapitel 6 wurden bereits die Anforderungen an die Anwendung und das Framework am konkreten Beispiel benannt. Es wurde gezeigt, dass nicht nur die Integration des GCI Konzeptes in eine bestehende Anwendung, sondern auch in verschiedene mobile Betriebssysteme umsetzbar ist. Das Adapter Pattern eignete sich am besten für die Adaption von Komponenten und Frameworks. Mittels Mobile Strategy Adapter konnten kontextsensitive Informationen wie zum Beispiel Verbindungsqualität oder Displaygröÿe einen Einuss auf das Verhalten der Anwendung bewirken. Die persistente Datenspeicherung auf dem mobilen Gerät wurde ebenfalls erläutert und stellt dabei einen Cachingmechanismus dar. Die unterschiedlichen Eingabemöglichkeiten wurden nicht weiter betrachtet, da dies mehr im Bereich User-Interaction und Usability liegt und nicht Schwerpunkt dieser Arbeit ist. Eine detaillierte Betrachtung der anwendungsspezischen Ressourcen wurde ebenfalls auÿer Acht gelassen. Die Netzwerklast sowie Rechenleistung für OT Transformationen spielen dabei aber eine gröÿere Rolle. Ein Groÿteil der qualitativen Anforderungen konnte mit dem Konzept umgesetzt werden. 7.3 Durchführung und Auswertung 55