Entwurf und Implementierung einer dynamischen Funktionalitätsanpassung von myhealthassistant. Bachelorarbeit Dassi Ponka Informatik

Transkript

1 Entwurf und Implementierung einer dynamischen Funktionalitätsanpassung von myhealthassistant Bachelorarbeit Dassi Ponka Informatik

2 Abbildungsverzeichnis 1 myhealthhub-interaktionsmodell Android Software-Stack Buildprozess OSGi-Architektur manifest-file Lebenszyklus eines Bundles System-Übersicht Felix in Android Client-Server-Interaktion in REST Umwandlungsfluss ein Bundles Klassen für die Integration von OSGi in Android Struktur des ECGtoHR-Transformationsprojekts Struktur des Remote-Repository-Projekts Installation einer Transformation

3 Dassi Ponka Matrikelnummer: Studiengang: Informatik Bachelorarbeit Thema: Entwurf und Implementierung einer dynamischen Funktionalitätsanpassung von myhealthassistant Eingereicht: 15. Mai 2013 Betreuer: Christian Seeger Prof. Alejandro Buchmann Fachgebiet Databases and Distributed Systems / Informatik Technische Universität Darmstadt Hochschulstraße Darmstadt

4 Ehrenwörtliche Erklärung Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Darmstadt, den Unterschrift 3

5 Inhaltsverzeichnis Abbildungsverzeichnis 1 1 Einleitung Motivation Aufgabenstellung Zielsetzung und Aufbau der Arbeit Verwandte Arbeit Eclipse Die Netscape-Plugin-Programmierschnittstelle Grundlagen Android Android-Laufzeitumgebung Dalvik Virtual Maschine Buildprozess Ressourcen Android Komponenten Activities Services Broadcast-Receiver Android-Context Komponentenkommunikation Intent OSGi-Grundlagen OSGi-Architektur OSGi-Bundle Manifest-Datei Lebenszyklus eines Bundles Deklarative Services REST Web Service Grundprinzipien I

6 4 Konzeption Konzeption Integration des OSGi-Frameworks in Android Interaktion zwischen OSGi-Bundles und Android Remote-Repository Kommunikation mit dem Remote-Repository Implementierung Verwendete Tools Software Development Kit Android Debug Bridge (adb) dx-tool Apache Maven pom.xml Integration von Apache Felix in Android Erstellung einer Transformation Verwaltung von Transformators Umsetzung des Remote-Repositorys Struktur des Projekts Konfiguration des Webservers Remote-Repository REST-konform Entwickelt REST mit Jersey Speicherung von Transformationen Kommunikation mit dem Remote-Repository Installation einer Transformation Ablauf Fazit und Aussicht Fazit Aussicht Abkürzungsverzeichnis 42 Literaturverzeichnis III Inhaltsverzeichnis II

7 1 Einleitung 1.1 Motivation Die Technische Universität Darmstadt vor allem das Fachgebiet Database and Distributed Systems (DVS) befasst sich mit Sensornetzwerken und Anwendungen für Assistenzsystem zur Unterstützung im täglichen Leben. Eine dieser Anwendung ist myhealthhub, eine Middleware für Sensornetze, die auf dem Betriebssystem Android basiert. Um die Qualität und vor allem die Akzeptanz von myhealthhub zu erhöhen, ist es von Vorteil, seine Funktionalitäten und Benutzbarkeit besser und flexibel zu gestalten. Aus diesen Gründen wird in der Middelware ein Plugin 1 -System eingeführt, so dass das System sich in Zukunft (im Gegenteil eines monolithischen Systems) dynamisch anpassen kann. Ein monolithisches System lässt sich meistens nicht an die individuellen Bedürfnisse und Wünschen des Benutzers in der Hinsicht anpassen, dass bestimme Funktionalitäten und Module des Gesamtsystems nicht ausgewechselt oder ersetzt werden können. Zudem kann ihre Verfügbarkeit nur schwer gewährleistet werden. In solchen Systemen können Systemteile nur schwer herausgelöst oder ersetzt werden. Mit wachsender Größe werden die so realisierten Anwendungen immer komplexer und nur schwer beherrschbar. Für bestimmte Anwendungen ist eine sehr hohe Verfügbarkeit in dem Sinne erforderlich, dass sie nicht gestoppt werden können. Wichtig ist dies speziell für lebenskritische Anwendungen - so genannte safety-of-life applications wie myhealthhub. Deshalb Operationen wie die Bereitstellung neuer Versionen, Patches oder Erweiterungen während der Laufzeit stattfinden müssen. Eine Unterbrechung dieser Systeme würde hohe Kosten und Verlust der Benutzerfreundlichkeit nach sich ziehen und kann sogar lebensbedrohlich sein. Flexible Anwendungen, die in der Lage sind, ihr Verhalten zur Laufzeit an ein sich immer veränderndes Umfeld anzupassen, gewinnen mehr und mehr an Bedeutung. Der Bedarf an solchen Anwendungen ist vor allem dadurch begründet, dass mobile Anwendungen zunehmend benutzt werden und die Nutzer vor allem an Anwendungen interessiert sind, die sich dem aktuellen Kontext anpassen können. In diesem Fall ist die Integration eines Pluginsystems in die Software eine Lösung der sich ergebenden Probleme. Damit ist es 1 Ein Plugin ist eine Software Komponente, die sich über eine definierte Schnittstelle in ein Programm einklinken kann, um dessen Funktionalität zu erweitern. 1

8 möglich das System während seiner Entwicklung auf bestimmte Grundfunktionalitäten zu reduzieren und nach individuellen Bedürfnissen des Benutzers anpassen zu lassen, indem vorgefertigte Funktionalitäten nach Bedarf und auf einfachste Weise zum Softwaresystem hinzugefügt oder daraus entfernt werden 1.2 Aufgabenstellung Dynamische Anapassung - die Fähigkeit Komponenten zur Laufzeit zu ändern oder neue in ein System einzubringen - ist ein äußerst komplexe Angelegenheit und zugleich ein wesentliches Mittel, um evolutionäre Veränderung in einem langlebenden System zu bewerkstelligen. Die Probleme liegen bei dem Zusammenspiel vieler unabhängigen Faktoren wie Kosten, Zeit, Anwendungszustand und System-Ressourcen. Die Begrenzte Ressourcen in Embedded Systems, insbesondere Speichergröße und Rechnerleistung impliziert auch den Bedarf nach einem leichtgewichtigen Erweiterungsmechanismus, das das System nicht belasten soll. Die am Fachgebiet Database and Distributed System (DVS) entwickelte Kommunikationsmiddleware für Sensornetze wird eingesetzt, um die von Sensoren gesendeten Daten zu bearbeiten. Die Kommunikation von Sensoren zur Middleware erfolgt durch eine Bluetooth-Verbindung. Die Mehrheit der Sensoren, die im Moment eingesetzt werden, sind nicht rekonfigurierbar. Die aktuellen Sensoren sind so entwickelt, dass sie nur Daten mit bestimmten Inhalt und in einer bestimmten Form senden können. Deswegen besteht keine Möglichkeit den Sensoren mitzuteilen, was sie senden sollen. Die Abbildung 1a zeit die aktuelle funktionsweise der Middleware. In diesem Kommunikations- und Interaktionsmodell kann ein Benutzer die gewünschte Information nur dann bekommen, wenn myhealthhub im Zeitpunkt der Abfrage die entsprechenden Daten von einer angeschlossenen Sensor bekommt. Um den Einsatzbereich und die Akzeptanz der Middleware zu erhöhen, sollte die Abhängigkeit von Sensoren verringern werden, damit das System in der Lage sein wird, nur mit den nötigen Sensoren auszukommen. Das Abbild 1b zeigt das gewünschte Verhalten des Systems. Eine Softwarelösung in Form von dynamischen Modulen sollte den Einsatz von Sensoren kompensieren. Damit ist es nicht nur möglich die Kosten und Zeit zur Herstellung von Sensoren zu sparen, möglich ist es auch damit das System funktionsfähig im Betrieb zu halten, falls ein im Einsatz stehender Sensor plötzlich ausfallen würde. 1.2 Aufgabenstellung 2

9 (a) Aktueller Zustant (b) Zu erreichen Abbildung 1: myhealthhub-interaktionsmodell 1.3 Zielsetzung und Aufbau der Arbeit Das grundlegende Ziel einer dynamischen Anpassung von Softwaresystemen besteht darin, einem System zu helfen, sich selbständig (ohne zusätzliche Benutzereingriffe) und dynamisch zu erweitern. Neue Funktionalitäten werden nicht sofort auf dem Softwaresystem installieren, sondern in einem Remote-Repository bereitgestellt. Die Funktionalitäten werden dann erst nach einer Abfrage dem System zur Verfügung gestellt. Eine Erweiterung sollte also einen Bestandteil des Systems werden, erst wenn sie vorher heruntergeladen und installiert wurde. In dieser Arbeit wird eine Softwarelösung entwickelt, die dem System helfen sollte, seine Abhängigkeit von Sensoren auf die notwendige Anzahl zu verringern und so seinen Einsatzgebiet und Akzeptanz zu steigen. Dafür wird eine mögliche Kombination von OSGi und REST (auch RESTful Webservices) als Grundlage für die Entwicklung eines dynamischen Anpassungsmechanismus für myhealthhub vorgestellt. In Kapitel 2 werden relevanten verwandten Arbeiten vorgestellt. Darauf folgt ein kurzer Überblick über die Android-Programmierung und die für die Realisierung dieser Arbeit relevante OSGi-Aspekte. Anschließend wird auf die Grundkonzepte von REST(auch RESTful Webservices) eingegangen. Die konzeptionelle Vorstellung dieser Arbeit erfolgt in Kapitel 4 gefolgt von der technischen Umsetzung in Kapitel 5. Abschließend werden in der Zusammenfassung (Kapitel 6) alle relevanten Ergebnisse der Arbeit zusammengefasst. 1.3 Zielsetzung und Aufbau der Arbeit 3

10 2 Verwandte Arbeit Das Problem der dynamischen Anpassung von Softwaresystemen ist nicht neu. Es ist fast so alt wie das Software-Engineering selbst. Es wurde aber vor allem mit der Entwicklung und Expansion von verteilten Systemen deutlich. Kramer und Magee gründete den Bereich der dynamischen Rekonfiguration 2 mit ihrer Arbeit aus dem Jahr In [15] beschreiben sie wie ein System zur Laufzeit sicher geändert werden kann. Der Grundstein für ihren Ansatz war das so genannte quiescence -Konzept (das Ruhe-Konzept). Sie beschreiben ein System, in dem ein Programmierer die gewünschten Änderungen auf deklarative Weise angeben kann. Später wurden mehrere Forschungsarbeiten auf dem Gebiet betrieben. Es ist - insbesondere in den letzten Jahren - ein aktives Forschungsgebiet geworden. Aber nur sehr wenige Arbeiten konzentrieren sich auf eingebettete Systeme. Ein einfaches Verfahren zur Implementierung eines Pluginsystems in einer Objektorientierten Umgebung ist die Verwendung des Strategy Design Pattern[10]. Diese Lösung ermöglicht es, ein Algorithmus oder eine Strategie zur Laufzeit zu ändern. Das erfordert aber, dass die Anwendung vom Anfang an für zukünftige Anpassungen entworfen wurde und dass alle möglichen Strategien zur Kompilierungszeit des Systems bekannt sind. Daher ist so ein Verfahren für unvorhergesehene Aktualisierungen und vor allem für Systeme mit begrenzten Ressourcen nicht geeignet. Ein sehr flexible Lösung kann auf der Metaebene gefunden werden. Durch Reifikation objektorientierter Konzepten (Klassen, Methodenaufrufe, usw.) kann ein Metamodell über die Anwendung erstellt werden. Auf diese Weise ist es möglich, Änderungen an der Anwendung zu machen, indem das Metamodell geändert wird. Ein großer Vorteil dieses Ansatzes ist, dass eine saubere Trennung zwischen der Anwendung und den Code für die Rekonfiguration möglicht ist. Der Rest dieses Abschnitts beschreibt zwei wesentliche Ansätze, die die dynamische Anpassung von Softwaren unterstützen: Eclipse und die Netscape-Plugin- Programmierschnittstelle. 2 ein technischer Vorgang, bei dem ein Softwaresystem dynamisch angepasst wird 4

11 2.1 Eclipse Eclipse ist als eine leistungsstarke integrierte Entwicklungsumgebung 3 ( Integrated Development Enviroment (IDE)) unter Java-Entwicklern bekannt, ist jedoch nicht auf die Programmiersprache Java beschränk. Beim Übergang von Eclipse Version 2.1 zur Version 3.0 haben sich die Entwickler entschieden, ihre eigene Implementierung eines Plugin-Systems durch eine auf dem Framework der OSGi (Open Service Gateway Initiative) aufbauende Implementierung namens Equinox zu ersetzen. Der bisherige proprietäre Implementation wurde durch Equinox ersetzt und abgesehen von einem kleinen Kernsystem zur Integration von Plugins wird jegliche weitere Funktionalität, insbesondere die Java-Entwicklungswerkzeuge vollständig in Plugins ausgegliedert. Dadurch wird sie leicht erweiterbar und unterstützt das Erstellen und Nutzen von neuen Softwarewerkzeugen. Bei Eclipse-Plugins handelt es sich um statische Komponenten, die lediglich beim Start des Systems gesucht und registriert werden. Plugins werden in Eclipse als Java Klassen realisiert, welche von einer entsprechenden den Basis Klasse abgeleitet werden. Zusätzlich hat jedes Plugin ein XML basiertes Manifest, welches das Plugin und seine Verbindungen zu anderen Plugins beschreibt. Plugins können sich gegenseitig um Funktionalität erweitern. Diese Verbindungen stellen ein Mechanismus dar, mittels dessen Bundles untereinander kommunizieren können. Sie werden als Extension Points genannt. Ein Plugin kann mehrere solche Verbindungen bereitstellen. Ein oder mehrere Plugins können diese Schnittstelle nutzen und nehmen dabei die Rolle des Extenders ein. Das Pluginsystem, das von Eclipse geboten wird ist flexibel und mächtig, da Plugins über Extension Points verschachtelt werden können. Es hat aber den Nachteil, lediglich statische Komponenten zu unterstützen. Derzeit entsteht ein Modell für dynamische Plugins. Das Projekt befindet sich im Moment noch in der Entwicklung. 2.2 Die Netscape-Plugin-Programmierschnittstelle Netscape Plugin Application Programming Interface (NPAPI) ist eine Cross-Plattform- Plugin-Architektur, die von vielen Web-Browsern verwendet wird. Mit dem NPAPI kann der Umgang mit unbekannten Ressource-Typen zu externen Plugins delegiert werden. 3 Als Entwicklungsumgebung wird eine Anwendung bezeichnet, mit der es möglich ist, Software in einer oder mehreren Programmiersprachen zu entwickeln 2.1 Eclipse 5

12 Netscape-Plugins werden als plattformspezifische dynamische Bibliotheken ausgeliefert. Einmal installiert, können diese Plugins nahtlos in Webseiten integrieren werden. Beliebte Browsern wie Chrome, Firefox, Opera Safari sowie älteren Versionen von Internet Explorer unterstützt diese Art von Plugins. Um durch den Browser geladen werden, muss ein NPAPI-Plugin eine bestimmte Gruppe von Funktionen erklären. Diese Funktionen werden vom Browser aufgerufen, um die Plugin-Funktionen aufzuzählen oder das Plugin über neuen Bedingungen, wie der Abschluss einer URL-Anforderung oder Änderungen des Fensters, zu informieren. Damit kann der Plugin-Lebenszyklus vom Webbrowser kontrolliert werden. Das Plugin wird bei Bedarf vom Browser aktiviert, je zu präsentierendem Datenobjekt eine Instanz des Plugins erzeugt und auch wieder vernichtet, sobald kein Bedarf mehr besteht. Auf der anderen Seite stellt der Browser eine Reihe von Funktionen dem Plugin zur Verfügung. Damit entsteht eine Bidirektionale Interaktion zwischen Plugins und dem Browser. Für die korrekte Installation eines Plugins auf dem System des Anwenders ist in der Regel der Plugin-Hersteller zuständig, so dass diese außerhalb der Kontrolle des Webbrowsers erfolgt[9]. 2.2 Die Netscape-Plugin-Programmierschnittstelle 6

13 3 Grundlagen In diesem Kapitel soll ein Überblick über die technischen Grundlagen gegeben werden, auf denen diese Arbeit aufbaut. Auch wenn all die Möglichkeiten der in dieser Arbeit verwendeteten Technologien nicht eingehend behandelt werden können, soll auch ein möglichst umfassender Überblick über sie geliefert werden. Auf diese Weise können die Konzepte hinter der einzelnen Technologie am besten verstanden und auch die Möglichkeiten, die sich daraus ergeben erkannt werden. Das Augenmerk liegt dabei hauptsächlich auf die Möglichkeit, sie am besten zusammenarbeiten zu lassen. Zunächst soll Android betrachtet werden, da es in dieser Arbeit indirekt darum geht, ein Pluginsystem in Android zu integrieren. Danach soll auf OSGi eingegangen werden. Da ein Plugin (in dieser Arbeit als Transformation genannt) erst nach Bedarf heruntergeladen werden soll und ein RESTful Web Service dafür eingesetzt wird, soll auch kurz die Architektur von REST-basierten Webservices beschrieben werden. 3.1 Android Android ist zugleich ein Betriebssystem und eine Software-Plattform für mobile Endgeräte wie Smartphones, Mobiltelefone und Netbooks. Es wurde von Google und der Open Handset Alliance[7] entwickelt, wobei ein großer Teil der Software frei und quelloffen ist. Die Open Handset Alliance (OHA) ist eine in 2007 von Google initiiertes Bündnis von über 60 namhaften internationalen Mobilfunkanbietern, Softwarefirmen, Mobiltelefon-Hersteller, Halbleiterfirmen und Netzbetreiber, das die Vision einer offenen, mobilen Plattform realisieren soll[4]. Durch die Möglichkeit für Gerätehersteller Android kostenlos zu nutzen, wird es gerne eingesetzt. Um ein besseres Verständnis über die Funktionsweise von Android zu erlangen, ist es wichtig mehr über seine Laufzeitumgebung zu erfahren. Es soll auch die Komponententypen und deren Interaktionen untersucht werden. Nicht zu vernachlässigen ist der Buildprozess einer Android-Anwendung. Da der Umgang mit Ressourcen eine bedeutende Rolle in allen Anwendungen spielt, soll auch betrachtet werden, wie Android sie verwalten. 7

14 3.1.1 Android-Laufzeitumgebung Android basiert auf einem Linux Kernel. Für mobile Bedürfnisse wurde der Linux Kernel um weitere Module 4 wie Kernel-Debugger, Binder, Logger, eine verbesserte Energieverwaltung und einen Low Memory Killer erweitert. Treiber, die für ein solches System unwichtig sind, wurden entfernt. Andere Treiber etwa für spezielle Tastaturen oder eingebaute Kameras, hinzugefügt. Android ist ein kompletter Software-Stack 5, der ein Linux-Kernel, eine Middleware und ein paar nützliche Anwendungen umfasst. Die Abbildung 2 zeigt seinen Software-Stack. Die oberste Schicht umfasst Portable User-Anwendungen, die in Java programmiert wur- Abbildung 2: Android Software-Stack den. Diese stützen sich auf die nächste Schicht, die eine Vielzahl von Java-APIs exportiert und eine Reihe von Dienstleistungen bietet, um die Entwicklung von Anwendungen zu er- 4 Ein Modul ist eine abgeschlossene funktionale Einheit einer Software, deren Funktionalitäten über eine definierte Schnittstelle zugegriffen werden 5 Ein Software-Stack ist eine besondere Softwaredefinition, mit der Sie Softwaregruppen identifizieren können, die Sie gleichzeitig und in einer bestimmten Reihenfolge auf Zielsystemen installieren möchten. 3.1 Android 8

15 leichtern. Es sind z.b die Content-Manager, Ressourcen-Manager, View-Dienste usw. Die nächste Schicht besteht aus C/C++ System-Bibliotheken und die Android Runtime. Die System-Bibliotheken beinhaltet: System C library (libc) Media library SQLite (database engine) SGL (to support 2-D graphics) Kern der Laufzeitumgebung bildet die Dalvik Virtual Maschine 6 (Dalvik VM) zusammen mit ihren Kernbibliotheken Dalvik Virtual Maschine Jede Android-Anwendung läuft in einem eigenen Linux-Prozess. Jeder Prozess auf Android hat eine eigene Instanz der Dalvik VM, die zusammen mit dem Prozess erstellt und zerstört, wenn der Prozesse terminiert. Dalvik Virtual Maschine fungiert als Interpreter 7 für Java-Code. Im Gegensatz zur Java VM (JVM), die auf einen Kellerautomaten basiert, arbeitet die Dalvik VM als Registermaschine[16]. Dadurch können Berechnungen stark beschleunigt werden. Eine auf Register basierte virtuelle Maschine holt ihre Bytecodes und Operanden aus Registern. Dies hat zur Folge, dass herkömmlicher Java-Bytecode ins Dex-Format (Dalvik Executable) überführt werden müssen, damit sie auf der Dalvik VM zur Ausführung gebracht werden können[17]. Der Speicherverbrauch wurde etwa dadurch verringert, dass Redundanzen im Bytecode entfernt wurden. Vor allem ist das Modell der Registermaschine in Bezug auf den begrenzten Ressourcen (Speicherplatz, Rechenleistung) für mobile Geräte wesentlich besser geeignet Buildprozess Im ersten Schritt des Buildprozesses einer Android-Anwendung werden die Java- Code von einem Java-Compiler in Java-Bytecode kompiliert. Für jede Java-Klasse entsteht eine Class-Datei. Diese werden, zusammen mit Ressourcendateien wie die AndroidManifest.xml-Datei, XML-Dateien und möglichen Drittanbieter-Bibliotheken, 6 Eine virtuelle Maschine (VM) ist eine hohe Abstraktion auf das native Betriebssystem, dass eine physikalische Maschine emuliert. 7 Der Interpreter ist eine Software-Bibliothek, die Eingaben und Quelltext entgegen nimmt und zur Laufzeit interpretiert. 3.1 Android 9

16 von dx (ein Programm im Android Development Kit) in Dalvik-Bytecode überführt. Die entstandenen Dalvik-Bytecode werden in einer einzigen Dex-Datei gebündelt. Zuletzt wird die Dex-Datei und alle weiteren Dateien, die von der Anwendung genutzt werden sollen, in einer.apk-datei zusammengefasst. Die Datei kann später von einem Android-Geräte entpackt werden. Abbildung 3 veranschaulicht den Buildprozess einer Android-Anwendung. Abbildung 3: Buildprozess Ressourcen Jedes Android-Projekt hat einen /res/-ordner mit weiteren Unterverzeichnissen. Wichtig für diese Arbeit war das Unterverzeichnis /res/raw. Dort können binäre Daten abgelegt werden. Diese Daten sind durch die Ressourcen-Klasse (R-Klasse) erreichbar. Hierzu wird für jede Ressource eine eindeutige Kennung erstellt. Dadurch kann eine Ressource leicht zur Laufzeit angesprochen werden Android Komponenten Android definiert ein einfaches Komponentenmodell. Jede Komponente verfügt über einen Lebenszyklus, welcher definiert, wie die Komponente erzeugt und zerstört wird. Im folgenden sollen die Android-Komponenten und Klassen vorgestellt werden, die für diese Arbeit wichtig wurden Activities Eine Activity stellt die Benutzeroberfläche einer Anwendung dar. Sie kümmern sich um die Darstellung von Daten und nehmen Anwendereingaben entgegen. Wenn zwischen den Screens gewechselt werden soll, wird eine neue Activity aufgerufen und die vorherige pausiert. Sie sind deshalb nicht geeignet, persistenten Daten zu halten. 3.1 Android 10

17 Services Services erledigen Hintergrundprozesse und können sowohl im Prozess der aufrufenden Komponente als auch in einem eigenen Prozess gestartet werden. Bei dem Service, welcher im gleichen Prozess wie die Anwendung läuft, spricht man von einem Local Service. Der im eigenen Prozess laufenden Service nennt man Remote Service. Mithilfe eines Services können Programmlogiken ausgelagert werden. Sie sind gut geeignet für die Bereitstellung von langfristigen Diensten. Eine Service-Komponente kann als wichtig deklariert wird. Dadurch wird sie erst gestoppt, wenn dem System den Speicherplatz ausgeht Broadcast-Receiver Broadcast-Receiver wurden gemäß den Publisher/Subscriber implementiert. Apps(die als Publisher, Herausgeber, bezeichnet werden) können einen Broadcast senden, um einfach Informationen zu übermitteln, ohne zu wissen wer und ob überhaupt jemand sie empfängt. Die Receiver(die als Subscriber, Empfänger bezeichnet werden), die diese Nachrichten haben wolllen, registrieren sich über Filter für bestimmte Events. Wenn die Nachricht einem Filter entspricht, wird der Subscriber aktiviert und über die Meldung benachrichtigt[13] Android-Context Die Klasse android.content.context bildet die Schnittstelle für eine Android-Anwendung zur Laufzeitumgebung. Über die Methoden der Klasse lassen sich alle Komponenten und Dienste der Plattform (Android) ansprechen. Damit die vorgestellten Komponenten miteinander interagieren können, bietet Android interessante Mittel zur Kommunikation Komponentenkommunikation Die Anwendungen und System-Dienste in Android verhalten sich wie in einem verteilten System. Jede Android Applikation läuft in eigener virtuellen Maschine. Möchte man auf Ressourcen, die außerhalb der Sandbox 8 liegen, zugreifen, müssen dafür explizit Berechtigungen vergeben werden. Der offizielle Weg unter Android eine Kommunikation zwischen Anwendungen herzustellen, sind Intents, RPC-Aufrufe mittels Binder und AIDL Android 11

18 Intent Intents sind eine Möglichkeit der Kommunikation zwischen Komponenten oder Prozessen in Android. Android nutzt Intents für Inter- und Intra-Anwendung-Kommunikation. Ein Intent stellt eine Nachricht in Form einer Datenstruktur dar. Die Struktur enthält optional einen Empfänger und eine abstrakte Beschreibung einer Operation, die Action genannt wird. Die Intents lassen sich in zwei Kategorien unterteilen explizite Intents: Hier wird der Empfänger direkt angegeben. Dies erfolgt über den vollständigen Name der Komponente. implizite Intents: Hier wird kein direkter Empfänger dieser Nachricht genannt und können daher von jeder Anwendung empfangen werden. Die Erweiterungseinheiten (auch als Transformation genannt) in myhealthhub sind dynamische Software-Module, die als OSGi-Bundle implementiert werden. Der kommende Abschnitt dient als Einführung in die OSGi Service Plattform und definiert zugleich den Grund, warum OSGi eingesetzt werden soll. 3.2 OSGi-Grundlagen OSGi steht für Open Service Gateway Initiative und ist ein Konsortium, welches sich der Entwicklung und Standardisierung einer Java-Laufzeitumgebung für Dienste widmet. OSGi ist ein leichtgewichtiges Framework, dessen Schwerpunkt auf der Entwicklung von dynamischen Systemen liegt. Um die Portabilität auf unterschiedliche Hardware zu gewährleisten, setzt OSGi auf Java. Softwaresysteme, die auf OSGi aufbauen, können zur Laufzeit sowohl lokal als auch entfernt aktualisiert werden ohne, dass das darunterliegende System gestoppt wird. Die Gründe für den Einsatz von OSGi liegen darin, dass die Java Standard Edition nur eingeschränkte Möglichkeiten zur Modularisierung bietet. Als Mittel zur Modularisierung in Java dienen Klassen, Pakete und die JAR-Dateien. Klassen sind in den meisten Fälle zu kleine Einheiten, um als Modul verwenden zu können. Java-Pakete hingegen können keine Kapselung gewährleisten, da sie jederzeit erweitert werden. Ihre Aufgabe ist es, Namensräume zu definieren. Standardmäßig sind JAR-Dateien die Auslieferungsmethode von Software für die Java-Plattform. Sie bieten zwar schon die Möglichkeit, ausführbaren Code und gegebenenfalls weitere Ressourcen zu bündeln, haben aber folgenden Nachteile: Sie bieten Keine Unterstützung für Versionierung 3.2 OSGi-Grundlagen 12

19 Abhängigkeiten zu anderen JAR-Dateien sind implizit Sie bieten Keine Unterstützung für JAR-Dateien als Einheit der Kapselung JAR-Dateien werden lediglich als Einheit der Auslieferung benutzt. Deswegen gibt es in Java keine Laufzeitentsprechung, durch die eine JAR-Datei repräsentiert wird. Was aber für die diese Arbeit von größer Bedeutung ist. Denn die Transformators sollen als Module bereitgestellt werden[18]. Die OSGi Service Platform ist ein sehr mächtiges Framework, dessen Architektur klar strukturiert ist OSGi-Architektur Die Architektur der OSGi-Plattform ist schichtweise organisiert. Jede Schicht ist verantwortlich für eine Reihe von spezifischen Aufgaben, die im Zusammenhang mit der Integration eines Bundels in die Plattform steht. Diese Schichten werden wie folgt erläutert: Abbildung 4: OSGi-Architektur Betriebssystem/Hardware: Auf der untersten Ebene befinden sich die Hardware und ein entsprechendes Betriebssystem. Die Hardware und das Betriebssystem können von verschiedenen Herstellern kommen. Für das Betriebssystem muss eine Java Laufzeitumgebung existierten, die die OSGi Spezifikation mindestens in der Version 1.0 erfüllt. Execution Environment: Eine Ebene höher liegt das Execution Environment. Dieser besteht aus einer Java Laufzeitumgebung. Dabei werden verschiedene Editionen, wie zum Beispiel Java SE 9, CDC 10, und MIDP 11 unterstützt OSGi-Grundlagen 13

20 Module Layer: definiert ein Modularisierungsmodell fur Java. Dieser Schicht erlaubt es, Modularisierungsprinzipien in Java auf größere Einheiten als Klassen anzuwenden. Diese Einheiten werden in OSGi als Bundles bezeichnet und als Java Archive (JAR) repräsentiert. Life Cycle Layer: Das Life Cycle Layer bietet die API für die Verwaltung des Lebenszyklus von Bundles. Dort wird definiert, wie Bundles installiert, aktualisiert, deinstalliert, gestartet und gestoppt werden können. Service Layer: Die Serviceschicht erweitert die bisher vorgestellten Schichten um eine Service Registry, welche eine serviceorientierte Entwicklung innerhalb von OSGi ermöglicht. Es definiert ein Kommunikationsmodell fur die Kooperation von OSGi-Modulen Security Layer: ist ein optional. Der Security Layer stellt auf Basis von Java 2 Security spezifische Sicherheitsbelange zur Verfügung. Es kann z.b. festgelegt werden, ob ein Bundle berechtigt wird, bestimmte Services zu verwenden oder das API anderer Bundles zu nutzen. Ein wichtiges Konzept in OSGi ist die Sichtbarkeit von Klassen. Jedem Bundle wird ein Classloader zugewiesen. Mit dem Classloader werden alle Klassen und Ressourcen des Bundles geladen. Dadurch können verschiedene Versionen eines Bundle in derselben Java Virtual Machine benutzt werden. Mit diesem Mechanismus ist es auch möglich, verschiedene Instanzen einer Klasse zu unterscheiden. OSGi spezifiziert ein dynamisches Modulsystem fur Java. In der OSGi Service Platform werden Bundles als Einheit für Modularisierung verwendet OSGi-Bundle Ein Bundle in der OSGi Service Plattform ist die Modularisierungseinheit. Grundsätzlich sind Bundels regulären JAR-Dateien mit class-dateien und anderen Ressourcen wie Bilder, benötigten APIs und einer Manifest-Datei. Ein Bundle kann auch weitere JAR- Dateien beinhalten, die so seinen Classpath erweitern. Die Funktionalität eines Bundles werden in Form eines oder mehrerer dynamischen OSGi Services 12 verfügbar gemacht. Diese Services werden an einer zentralen Registratur (Service Registry genannt) unter einem oder mehreren Interface- oder Klassennamen angemeldet und können so von anderen Bundles gefunden und verwendet werden. In der OSGi-Architektur ist ein Service 12 Ein OSGi Service ist ein einfaches Plain Old Java Object (POJO). 3.2 OSGi-Grundlagen 14

21 ein Standard-Java-Objekt, das mit einem oder mehreren Interface-Typen und weiteren Eigenschaften (die verwendet werden können, um den Dienst zu finden) registriert ist. Die Entitäten, die sich in einem Bundle befinden, sind nicht implizit von außen sichtbar. Sie müssen explizit exportiert werden, damit sie von anderen Bundles benutzt werden können. Jedes Bundle muss eine Manifest-Datei beinhalten Manifest-Datei Abbildung 5: manifest-file Die Metadaten eines Bundles stehen in der Manifest-Datei und die Datei muss in einem Ordner names META-INF liegen. In der Manifest-Datei steht unter anderem welche Abhängigkeiten das Bundle besitzt bzw. welche anderen Java-Pakete es benötigt. Dort steht auch welche Pakete das Bundle selbst definiert und exportiert. Jedes Bundle besitzt einen obligatorischen symbolischen Namen, der mittels Bundle-SymbolicName (Ein Manifest-Header) spezifiziert wird. In der Menge der Manifest-Header sind folgende Angaben wichtig: Bundle-SymbolicName: Eindeutiger Name innerhalb des OSGi Frameworks. Obligatorisch. Bundle-Version: Dient zusammen mit dem symbolischen Namen als eindeutige ID. Default Bundle-Classpath: Listet alle Verzeichnisse und eingebettete JARs auf, die den lokal Klassenpfad des Bundles bilden wird. Default. Import-Package: Listet die Abhängigkeiten in Form von Package-Namen auf Export-Package: Listet die öffentliche Schnittstelle in Form von Package-Namen auf 3.2 OSGi-Grundlagen 15

22 Jedes Bundle innerhalb eines OSGi Frameworks kann während seiner Laufzeit in verschiedene Zustände wechseln. Der nächste Abschnitt beschreibt die verschiedene Zustände, die ein Bundle durchlaufen kann Lebenszyklus eines Bundles Ein Bundle kann sechs Zustände annehmen. Bei der Installation wird dem Bundle eine eindeutige ID vom Typ Long zugewiesen und wird in den Zustand INSTALLED versetzt. Das Bundle wird dann in dem lokalen Cache des OSGi-Framwork abgelegt. Bevor das Abbildung 6: Lebenszyklus eines Bundles Bundle gestartet werden kann, versucht das Framework alle Abhängigkeiten zu anderen Bundles aufzulösen. Das Bundle wird dann in den Zustand RESOLVED automatisch versetzt, wenn alle deklarierte Abhängigkeiten aufgelöst werden können. Falls mehrere passende Abhängigkeiten vorliegen, werden die mit der höchsten Version verwenden. Nur Bundles im Zustand RESOLVED können bereits verwendet werden. Wenn ein Bundle einen Activator spezifiziert, wird das Framework beim Start versuchen, dies zu starten, indem dessen start()-methode aufgerufen wird. Beim Starten wird das Bundle zunächst in den Zustand STARTING versetzt. Wenn ein Activator spezifiziert ist und die start()-methode nach einem Aufruf erfolgreich zurückkehrt, wird das Bundle auf ACTIVE gesetzt. Aus performancegründen kann der Aufruf der start()-methode solange verzögern, dass das Bundle solange im Zustand STARTING verbleibt, bis zum ersten Mal eine Klasse aus 3.2 OSGi-Grundlagen 16

23 dem Bundle geladen wird. Beim Stoppen geht das Bundle in Zustand STOPPING über. Wenn ein Activator spezifiziert ist, wird dessen stop()-methode aufgerufen und wenn diese erfolgreich zurückkehrt, wird das Bundle auf RESOLVED gesetzt. Bei der Desinstallation geht es zunächst in den Zustand UNINSTALLED über. Wenn das Bundle keine Packages exportiert, die auch verwendet wurden, wird es sofort aus dem Cache des OSGi Frameworks gelöscht. Andernfalls bleiben die Package-Exports bis zu einem Neustart des Frameworks erhalten. Dies Verhalten garantiert, dass durch das Deinstallieren eines Bundles nicht alle abhängigen Bundles automatisch funktionsunfähig werden. Abstrakt gesehen, ist die OSGi-Spezifikation in zwei logische Hälfte geteilt: Das OSGi- Framework und das OSGi Service Model. Das OSGi-Framework bildet den Kern der OSGi Service Platform. Es ermöglicht die Bereistellung von erweiterbaren und herunterladbare Modulen (bundles). Das Framework ist verantwortlich für die Verwaltung von Bundles auf einer dynamischen und skalierbaren Art und Weise. Es steuert den Lebenszyklus von Bundles; dies beinhaltet insbesondere das Hinzufügen, Entfernen, Starten und Stoppen zur Laufzeit von Bundles. Die OSGi Laufzeit und installierten Bundels befinden sich in einer einzigen JVM. Die Ausführung mehrerer Anwendungen in der gleichen JVM hat einige Vorteile: Sie steigert die Leistung, minimiert den Speicherbedarf und ermöglicht eine effiziente Kommunikation zwischen Anwendungen Deklarative Services Declarative Services bietet ein Programmiermodell, welches den Umgang mit dynamischen Services vereinfacht. Das Zentrale Konzept in der Deklarative-Service-Spezifikation ist das Konzept der Serive Components. Ein Service Component besteht aus einer implementierenden Klasse, der Komponentenklasse, und einer Komponentenbeschreibung in Form eines XML-Dokumentes: Eine Komponentenklasse: ist eine einfache Java-Klasse, die optional Callback- Methoden definieren kann, mit denen bei der Aktivierung und bei der Deaktivierung einer Komponente beliebige Aktionen ausgeführt werden können. Die Komponentenbeschreibung beschreibt eine Komponente mit ihren Abhängigkeiten zu anderen Services in Form eines XML-Dokumentes. Zusätzlich kann angegeben werden, ob eine Komponente selber Services über die Service Registry bereitstellt. 3.2 OSGi-Grundlagen 17

24 Die Erzeugung von Komponenteninstanzen und die Verwaltung deren Lebenszyklus erfolgt durch die Service Component Runtime(SCR). Komponentenbeschreibungen können über sog. Component Properties parametrisiert werden. Component Properties können direkt in der Komponentenbeschreibung angegeben werden. Alternativ können sie aber auch über Component Factories zur Laufzeit gesetzt werden[14]. Mit Deklarativen Services ist es möglich, den Speicherbedarf einer Anwendung zu senken, da Bundles erst dann gesartet werden, wenn diese benötigt werden. Die OSGi Service Platform ist eine reine Spezifikation. Mittlerweile gibt es verschiedene Implementierungen davon. Für diese Arbeit wird Apache Felix [12] der Apache Software Foundation benutzt, weil es eine bessere Unterstützung für Android-Geräte anbieten. Die Bundle werden getrennt entwickelt und in einem Remote-HTTP-Repository gespeichert. Die Bundle werden erst nach einer erfolgreichen Abfrage bereitgestellt. Hierzu wird ein Remote-Repository als REST Web Service entwickelt. 3.3 REST Web Service Representational State Transfer (REST) ist kein definierter standard, sondern ein von Roy Thomas Fielding in seiner Dissertation[11] beschriebener Architekturstil für vertailte Anwendungen, der im Bereich der Webservices 13 zunehmend an Bedeutung gewinnt. REST basiert auf den prinzipien des World Wide Web. Innerhalb einer Anwendung bietet ein Server adressiertbare Ressourcen. Clients und Server kommunitieren durch die Sendung von Anfragen und Antworten in der Form von Repräsentationen von Ressourcen. REST ist ressourcenzentriert. Mit jeder Abfragen wird eine Ressource entweder erstellt, aktualisiert, gelöscht oder seine Repräsentation abgefragt. Eine Ressource ist die Kernabstraktion einer Information in REST. Jede Information oder Datensatz kann eine Ressource sein Grundprinzipien Eine REST-Konforme Anwendung soll nach folgenden Prinzipien entworfen werden: Client-Server: Der Client-Server-Architekturstil ist der Architekturstil, der eine REST-konforme Anwendung aufweisen soll. Dadurch wird das sogenannte Separation of Concerns-Prinzip[8], welches die Trennung von Zuständigkeiten vorschreibt, 13 Ein Webservice ist ein Dienst, der über ein Netzwerk erreichbar ist und über zugängliche Schnittstellen zu seinen Funktinalitäten verfügt. 3.3 REST Web Service 18

25 verwendet. Dadurch reduziert sich die Komplexität des Servers, da die dabei Komponenten einfach gehalten werden können. Zustandlosigkeit: Die Client-Server-Kommunikation ist zustandslos. Das heißt, dass eine Anfrage alle benötigten Informationen enthalten muss, die zu seiner Bearbeitung nötig sind. Dabei werden Sitzungen ausschließlich clientseitig verwaltet. Ein Vorteil der Zustandslosigkeit ist, dass der Server sich nicht die Session- Informationen vieler Clients merken muss. Cachefähigkeit: Um die Netzwerklast zu minimieren, kann ein Cache eingesetzt werden. Einheitliche Schnittstelle: Ein wesentliches Aspekt, in dem sich REST-Systeme von anderen netzwerkbasierten Architekturstilen unterscheidet, ist die einheitliche Schnittstelle zwischen den Komponenten. Die Schnittstelle muss eine Teilmenge folgender Standardmethoden bereitstellt: GET fragt eine Repräsentation einer Ressource ab. POST erstellt eine neue Ressource. PUT ändert eine Ressource, wenn ihre URI bekannt ist. Falls sie noch nicht existiert, wird eine neue Ressource erstellt. DELETE löscht eine gegebene Ressource. HEAD fragt Metadaten zu einer Ressource ab. OPTIONS gibt die Methoden und Eigenschaften zurück, die unterstützt werden. Um die Forderung nach einer Einheitlichen Schnittstelle zu halten, stützt sich REST auf folgende Elemente: Eindeutig identifizierbare Ressourcen: Ein grundlegendes Konzept von REST ist, dass eine Ressource eine eindeutige Kennung (URI) haben muss. Sie wird verwendet, um diese Ressource abzurufen. Der Bezeichner muss eindeutig sein und ausreichende Informationen tragen, damit die Ressource lokalisiert werden kann. Verschiedene Repräsentationen der Ressourcen: Repräsentationen sind Darstellungen einer Ressource in einem definierten Format. Jede Ressource kann mehrere Repräsentationen haben. Das Ausmachen des Formats, welches vom Server geliefert wird, erfolgt durch eine Anfrage des Clients. 3.3 REST Web Service 19

26 4 Konzeption In diesem Kapitel wird auf Basis der Erkenntnisse der vorhergehenden Kapitel die Konzeptionelle Umsetzung der Zielanwendung präsentiert. Hierfür wurde auf eine Client-Server Architektur zurückgegriffen. Die Kommunikation zwischen Client und Server erfolgt auf Basis des REST-Architekturstils. Mit Hilfe von Erkenntnissen aus den Grundlagen werden Entwurfsentscheidungen erläutert und begründet. 4.1 Konzeption Das hier implementierte Anpassungsmechanismus lässt sich in drei Bestandteile untergliedern, die jeweils einzeln behandelt werden. Integration des OSGi-Frameworks in Android Entwurf des Remote-Repositorys Kommunikation mit dem Remote-Repository Abbildung 7: System-Übersicht Die Abbildung 7 zeigt das gesamte System. Hier wird durch die einzelnen abgetrennten Komponenten deutlich gemacht, wo eine bestimmte Funktionalität umgesetzt wurde. Auf der untersten Ebene befindet sich myhealthhub. Es ist das System, dass angepasst wird. 20

27 Der Pfeil deutet darauf hin, dass das Herunterladen, Starten und Stoppen einer Transformation von myhealthhub eingeleitet wird. Die Schicht auf die, der Pfeil gerichtet ist, beinhaltet Dienste, die zur Ausführung der gewünschten Funktionalitäten notwendig sind. Apache Felix dient hier als Container für die Transformationen. Die Transformationen werden als OSGi-Bundles ausgeliefert. Ihre Funktionalitäten werden in Form von OSGi-Services dem System zur Verfügung gestellt. Die Transformationsverwaltungsschicht kümmert sich um die Kommunikation mit dem Remote-Repository und die Installation einer neuen Transformation. Sie führt auch Buch über die im System befindlichen Transformationen. Das konkrete Starten und Stoppen einer Transformation wird an Apache Felix delegiert. Implementierte Transformationen werden auf einem Remote-Repository abgelegt und nach erfolgreicher Abfrage geliefert. Das HTTP-Protokoll wird hierfür verwenden. Im nächsten Teil wenden wir uns der Integration des OSGi-Frameworks in Android zu Integration des OSGi-Frameworks in Android Das OSGi-Framework ist ein Modul-System und Service-Plattform für die Programmiersprache Java. Mit OSGi können Anwendungen oder Komponenten entfernt installiert, gestartet, gestoppt, aktualisiert und deinstalliert werden, ohne dass ein Neustart des Systems erforderlich ist. Obwohl die Dalvik VM - im Gegensatz zur Java VM - auf einer Register-Architektur basiert und keinen Java-Bytecode verarbeitet, sondern Android-eigenen DEX-Bytecode ausführt, können nahtlos vorhandenen Java-Code und Bibliotheken in Android integriert werden. Sie müssen lediglich in Dalvik-Bytecode umgewandelt werden. Da das OSGi- Framework selbst und die Bundles einfach nur JAR-Dateien (mit einigen zusätzlichen Manifest-Header) sind, können sie auch in Android verwendet werden. Es klappt aber nicht immer. Das Problem liegt daran, es bei früheren Versionen von Android keine offizielle Methode zum dynamischen Nachladen von Klassen gibt. Apache Felix bietet eine für die Entwickler transparente Lösung. Das Framework ist nämlich seit Version ohne Einschränkungen auf Android lauffähig. Apache Felix wurde auch ausgewählt, weil es mehr tragbar ist und besser geeignet für Embedded-Hardware-Geräten. Das komplette Framework kann in Form eines JAR-Archives als Bibliothek in eine Android-Anwendung eingefügt werden. Dadurch lässt sich eine Instanz der Klasse Framework von Felix konfigurieren, erzeugen und starten. 4.1 Konzeption 21

28 Nachdem die konzeptionelle Integration des OSGi-Frameworks in Android behandelt wurde, ist es wichtig, sich auch mit der konzeptionellen Interaktion zwischen OSGi-Bundles und Android zu beschäftigen Interaktion zwischen OSGi-Bundles und Android Wie in Abbildung 8 gezeigt wird, werden die Plugins (hier Transformationen genannt) von Apache Felix verwaltet. Damit die Plugins mit Android interagieren können, wird die Klasse Context von Android über die OSGi-Komponente Service-Registry als OSGi- Service veröffentlicht. Dadurch kann sie von allen Transformationen bezogen werden, um Intents zu empfangen (durch die Registrierung beim ersten Start eines BroadcastReceivers) und versenden. Um die Integration von Transformationen in myhealthhub einfach zu Abbildung 8: Felix in Android gewährleisten, wurde der deklarative Einsatz von OSGi-Services ausgewählt. Damit kann ein Bundle mit den jeweiligen implementierten Diensten und Abhängigkeiten automatisch von dem OSGi-Framwork verwalten werden Remote-Repository Die Aufgaben des Remote-Repositories liegen darin, die Transformationen aufzunehmen und sie nach Abfrage zu liefern. Hierfür stellt das Remote-Repository Ressourcen zur Verfügung. Da es als eines RESTful Web Services konzipiert wurde, ist der Einsatz eines servlet-containers 14. unerlässlich. Betrieben wird der Server mithilfe von Jetty 15. Jetty 14 Ein Server, der die Servlet-Spezifikation implementiert Konzeption 22

29 lässt sich im Vergleich zu enderen Servlet-Containern leicht einbetten. Damit eine Transformation heruntergeladen wird, muss mit dem Server (Remote- Repository) kommuniziert werden. Im nächstem Abschnitt soll die konzeptionelle Realisierung der Kommunikation mit dem Server - auch als Remote-Repository genannt - behandelt Kommunikation mit dem Remote-Repository Die Basisvoraussetzung zur Entwicklung verteilter Anwendungen auf Mobilen Geräten sind schon heute erfüllt: Die heutigen Smartphones sind mit Technologien ausgestattet, die sie - unter anderem durch eine hohe Konnektivität und ausgezeichnete Geschwindigkeit - leistungsfähig machen. Die Kommunikation mit dem Remote-Repository erfolgt nach REST-Prinzipien auf Basis von HTTP. In einer REST-konform entworfenen Anwendung tauschen Clients und Server Darstellungen von Ressourcen 16 aus, indem eine standardisierte Schnittstelle und ein Protokoll verwendet werden. REST zwingt nicht den Einsatz eines spezifischen Protokoll als Applikationsprotokoll. Der Grund, warum HTTP ausgewählt wurde, liegt darin, dass das HTTP-Protokoll als Applikationsprotokoll in REST-basierten Anwendungen besser geeignet ist. HTTP ist einfacher zu handhaben und unterstützt unter anderem z.b die Manipulation von Ressourcen, die über URIs identifiziert werden. Außerdem ist HTTP Abbildung 9: Client-Server-Interaktion in REST ein ausgereiftes und weit verbreitetes Protokoll. Die Android-Plattform wird mit der HttpComponents-Bibliothek von Jakarta Commons ausgeliefert. Die Bibliothek erleichtert den Umgang mit dem HTTP-Protokoll. Die Daten werden dabei im JSON-Format übertragen. JSON ist ein leichtgewichtiges und einfach zu bedienendes Datenaustauschformat mit welchem sämtliche Daten zwischen Client und Server ausgetauscht werden können. Die Daten werden hierbei als Schlüssel-Wert Paar übermittelt. Android verfügt auch über ein eingebaute Unterstützung für JSON. 16 Eine Ressource in diesem Fall ist alles, was wichtig genug ist, um referenziert zu werden. 4.1 Konzeption 23

30 Aus diesen Gründen hat sich das Format als eine überzeugende Alternative zu XML im Rahmen dieser Arbeit bewährt. Nachdem die Konzepte, auf denen diese Arbeit aufbaut, vorgestellt wurden, soll jetzt mit der Implementierung weitergemacht werden. 4.1 Konzeption 24

31 5 Implementierung In den folgenden Abschnitten wird die Implementierung des Erweiterungsmechanismus möglichst detailliert dargestellt. Im ersten Schritt werden die Tools, die für die Umsetzung benötigt wurden, kurz vorgestellt. Anschließend wird die Implementierung der Zielanwendung betrachtet. 5.1 Verwendete Tools Das Anpassungsmechanismus wurde mit Eclipse (Version 3.7) unter Verwendung des Android Software Development Kits (Android SDK) (Version 2.3.3) und Android Development Tool (ADT) entwickelt. ADT ist ein Android-Plugin für Eclipse. Als Build-Management-Tool wurde Apache Maven eingesetzt. Apache Maven lässt sich auch direkt aus Eclipse heraus bedienen. Dafür wurde das Plugin m2e (Aus Eclipse MarketPlace) installiert Software Development Kit Das Android Software Development Kit (SDK) ist eine Sammlung von Programmen zur Entwicklung von Android-Anwendungen. Damit bietet Google eine Reihe von Werkzeugen an, welche die Softwareentwicklung für Android vereinfachen kann. In diesem Abschnitt soll ein paar von diesen Tools, die nützlich für diese Arbeit waren, kurz vorgestellt werden Android Debug Bridge (adb) Die Android Debug Bridge ist eines der wichtigsten Werkzeuge für die Entwicklung von Android-Anwendungen. Damit lassen sich die inneren Abläufe eines Android-Gerätes direkt von der Konsole ablesen. Damit ist es auch möglich eine Android-Anwendung auf einem spezifischen Gerät bzw. Emulator zu installieren. Das Werkzeug erwies sich während der Implementierung als sehr nützlich. Damit konnten Probleme schnell erkannt und behoben werden dx-tool Android Anwendungen sind größtenteils in Java geschrieben. Damit ein OSGi-Bundle in Android ausgeführt wird, es ist notwendig, sicherzustellen, dass das Bundle die Datei 25

32 classes.dex enthält. Das wird durch das dx-tool erreicht. Das dx-tool konvertiert die By- Abbildung 10: Umwandlungsfluss ein Bundles tecodes von Java (.class) in Android-Bytecode (.dex). Die Abbildung 10 veranschaulicht den Umwandlungsfluss eines Bundles. Nachdem die Java-Bytecode in einem JAR-Archiv gebündelt wurden, wird das dx-tool darauf angewendet, um aus den compilierten Java-Klassen die Datei classes.dex zu erzeugen. Der Befehl dazu lautet: dx dex keep-classes output=output.jar input.jar. output.jar und input.jar sollten gleich sein. Wenn die Option keep-classes nicht angegeben wird, werden alle class-dateien in input.jar mit einer Datei namens classes.dex ersetzt. Somit gehen alle Class-Dateien verloren. Damit das JAR-Archiv aber weiterhin für Java-Anwendungen verwendet wird, muss die Option keep-classes verwendet werden Apache Maven Bei der Entwicklung einer Anwendung ist es wichtig, dass sich die Entwickler auf das notwendige konzentrieren, damit sie produktiv am Projekt arbeiten können. Dabei soll es nicht dazu kommen, dass sie von unnötigen Aufgaben wie die Konfigurationen von Bibliotheken abgelenkt werden. Mit Maven lassen sich solche Probleme durch verschiedene Automatisierungen lösen. Maven ist ein deklaratives Projektverwaltungswerkzeug, welches dem Entwickler beim Erstellungsprozess (Kompilierung, Testen und Verteilung) einer Anwendung hilfreich sein kann. Es dient zur Umsetzung der Buildautomatisierung für Java-Projekte. Die Philosophie hinter Maven heißt Konvention über Konfiguration. Das bedeutet, die Strukturen von Projekten müssen nicht definiert, sondern vorgegeben werden. Maven bietet mehrere Vorteile, die das Leben eines Entwicklers erleichtert kann. Dazu zählen zum Beispiel: Verwaltung von Abhängigkeiten. Kompilieren des Projektes. automatische Ausführen von JUnit Tests. Erzeugung der gewünschten Archivierung. 5.1 Verwendete Tools 26

33 Der Buildprozess in Maven wird in Phasen eingeteilt. Für diese Arbeiten waren die folgenden Phasen wichtig. Compile (kompiliert sämtliche Java-Klassen) Package (bildet das Archiv aus den kompilierten Klassen) Install (kopiert das Archiv ins lokale Repository für die Referenz in anderen Projekten) Das wichtigste Element eines Maven-Projekts ist die Projektbeschreibungsdatei pom.xm. Dort werden zentral die Eigenschaften des Projekts konfiguriert pom.xml Lediglich die pom.xml-datei wird von Maven bei seiner Ausführung interpretiert. Damit vertritt Maven einen deklarativen Ansatz, der sich von anderen verbreiteten Buildwerkzeugen unterscheidet. Drin sollten alle Informationen enthalten sein, welche für den gesamten Lebenszyklus des Projektes von Interesse sind. Dort werden Abhängigkeiten sowie Projektinformationen wie aktuelle Version, Archivierungstyp (JAR, war,... ) und viele mehr gespeichert. Der <dependencies />-Tag umfasst alle angegebenen Libraries, von denen das Projekt abhängt. Dabei kann auch mit angegeben werden, wie eine Abhängigkeit benutzt wird. Dadurch ist es möglich eine Bibliothek nur für eine bestimmte Phase zu benutzen. Um die Abhängigkeiten eines Projekts zu verwalten, verwendet Maven ein einziges lokales Verzeichnis, genannt Repository, in dem Bibliotheken zentral für alle Projekte abgelegt werden. Benötigte Bibliotheken werden selbstständig von einem Remote-Repository heruntergeladen und ins lokale Repository kopiert. Transitive Abhängigkeiten werden auch analysiert und aufgelöst., 1 <dependency> 2 <groupid>o r g. OSGi</groupId> 3 <a r t i f a c t I d >org. OSGi. compendium</ a r t i f a c t I d > 4 <version >4.0.0 </ version > 5 <scope>provided </scope> 6 </dependency> 7 <dependency> 8 <groupid>com. g o o g le. Android</groupId> 9 <a r t i f a c t I d >Android</ a r t i f a c t I d > 10 <version > [ , )</version > 11 <scope>provided </scope> 5.1 Verwendete Tools 27

34 12 </dependency> 13 <dependency> 14 <groupid>de. tudarmstadt. dvs. myhealthhub. e v e n t s </groupid> 15 <a r t i f a c t I d >myhealthhubevents</ a r t i f a c t I d > 16 <version >0.0.1 </ version > 17 <scope>provided </scope> 18 </dependency> 19 </dependencies > Listing 5.1: Definition von Abhängigkeiten Für die Transformators Das Listing 5.1 zeigt die deklarative Angabe von Abhängigkeiten, die bei der Entwicklung von Transformationen verwendet wurden. Die eindeutige Kennung einer Abhängigkeit wird via <artifactid></artifactid> bekanntgegeben. Via <scope></scope> wird den Gültigkeitssbereich einer Abhängigkeit angegeben. Abhängigkeiten verfügen über verschiedene Gültigkeitssbereiche (Scopes). Dazu gehören unter anderem: provided: Die Abhängigkeit wird bei der Entwicklung des Projekts nur in der Kompilierungsphase benutzt. Später wird sie vom jeweiligen Laufzeitcontainer bereitgestellt und nicht mit ins Archiv eingebunden test : Wird nur zum Testen des Projekts benötigt Es sind weitere Gültigkeitssbereiche vorhanden. Für diese Arbeit sind sie aber unwichtig. Die groupid ist eine Gruppierungsbezeichnung (ähnlich den Java-Package-Namen). Eine selbst erzeugte Bibliothek kann durch den Befehl mvn install:install-file -Dfile=<pathto-file> -DgroupId=<group-id> -DartifactId=<artifact-id> -Dversion=<version> - Dpackaging=<packaging> ins Repository kopiert werden., 1 <modelversion >4.0.0 </ modelversion> 2 <groupid>de. tudarmstadt. dvs. myhealthhub. t r a n s f o r m a t o r s 3 </groupid> 4 <a r t i f a c t I d >ECGtoHR</ a r t i f a c t I d > 5 <version >0.0.1 </ version > 6 <packaging>jar</packaging> Listing 5.2: Beschreibung eines Maven-Projekts Der Archivierungstyp wird - wie ins Listing 5.2 gezeigt wird - via <packaging></packaging> angegeben. Maven verfügt über Projektschablonen. Diese Schablonen (auch Archetypes genannt) sind Maven-Projektvorlagen, die den strukturellen Aufbau eines Projekts bestimmen. Bei der Erstellung eines Archetypes werden bestimmte Abhängigkeiten eingebunden und Einstellungen gesetzt. Wenn keine bestimmte Schablone beim Erstellen eines Projektes angegeben wurde, wird ein normales Java-Projekt erstellt. Dabei wird der Archivierungstyp auf 5.1 Verwendete Tools 28

35 Jar gesetzt. Apache Maven bietet weitere Möglichkeiten, die während die Entwicklung dieser Arbeit nicht verwenden wurden. Nachdem die Verwendete Tools kurz vorgestellt wurde, soll im nächsten Schritt mit der eigentlichen Umsetzung weitergemacht werden. Im folgenden Abschnitt soll die Implementierung der Integration von Apache Felix in Android beschrieben werden. 5.2 Integration von Apache Felix in Android Die praktische Integration von Apache Felix in Android und die Verwaltung von Transformationen wurden in der Transformationsverwaltungsschicht (Abbildung 7) realisiert. Für die Integration von Apache Felix in Android wurden die Klassen FelixConfig, FelixService und Unzip entwickelt. Apache Felix wird mit Hilfe einer Java-Properties-Datei Abbildung 11: Klassen für die Integration von OSGi in Android 1 configuriert. Dafür wird im Konstruktor der Klasse FelixConfig eine Instanz der Klasse java.util.properties erzeugt und alle notwendige Properties gesetzt. 2 c o n f i g P r o p e r t i e s. s etproperty ( 3 o r g. OSGi. framework. Constants.FRAMEWORK_STORAGE, 4 felixdeploymentdir. concat ( F i l e. s e p a r a t o r ) 5. concat ( Constants. felix_cache_dir ) ) ; 5.2 Integration von Apache Felix in Android 29